randy/draft-l3dl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

-00 pushed to chairs

Browse source
This commit is contained in:
Randy Bush 2019-04-23 10:27:32 -07:00
parent f76db47f21
commit 31a8589bb7
1 changed files with 51 additions and 223 deletions
Download patch file Download diff file Expand all files Collapse all files

274
draft-ietf-lsvr-l3dl.xml
View file

@ -90,19 +90,19 @@
target="I-D.ietf-lsvr-bgp-spf"/> provides massive scale-out without
centralization using a tried and tested scalable distributed control
plane, offering a scalable routing solution in Clos <xref
target="Clos0"/><xref target="Clos1"/> and similar environments. But
BGP-SPF and similar higher level device-spanning protocols,
target="Clos0"/><xref target="Clos1"/> and similar environments.
But BGP-SPF and similar higher level device-spanning protocols,
e.g. <xref target="I-D.malhotra-bess-evpn-lsoe"/>, need logical link
state and addressing data from the network to build the routing
topology. They also need prompt reaction to (logical) link
failure.</t>
topology. They also need prompt but prudent reaction to (logical)
link failure.</t>
<t>Layer 3 Discovery and Liveness (L3DL) provides brutally simple
mechanisms for devices to <list style="symbols">
<t>Discover unique identities of devices/ports/... on a logical
link,</t>
<t>Run Layer 2 keep-alive messages for session continuity,</t>
<t>Discover each other's unique IDs (ASN, RouterID, ...),</t>
<t>Discover each other's unique endpoint identification,</t>
<t>Discover mutually supported encapsulations, e.g. IP/MPLS,</t>
<t>Discover Layer 3 IP and/or MPLS addressing of interfaces of the
encapsulations,</t>
@ -186,12 +186,10 @@
<t>L3DL assumes a Clos type datacenter scale and topology, but can
accommodate richer topologies which contain potential cycles.</t>
<t>While L3DL is designed for the MDC, there are no inherent
reasons it could not run on a WAN; though, as it is simply a
discovery protocol, it is not clear that this would be useful.
The authentication and authorization needed to run safely on a
WAN need to be considered, and the appropriate level of security
options chosen.</t>
<t>While L3DL is designed for the MDC, there are no inherent reasons
it could not run on a WAN. The authentication and authorization
needed to run safely on a WAN need to be considered, and the
appropriate level of security options chosen.</t>
<t>L3DL assumes a new IEEE assigned EtherType (TBD).</t>
@ -212,8 +210,8 @@
<t>Layer 2 Liveness Checks may be started</t>
<t>Encapsulation data are exchanged and IP-Level Liveness Checks
enabled</t>
<t>A BGP-like protocol is assumed to use these data to discover
and build a topology database</t>
<t>A BGP-like upper layer protocol is assumed to use these data to
discover and build a topology database</t>
</list></t>
<figure>
@ -262,15 +260,13 @@
<t>The upper layer BGP family routing protocols cross all the
devices, though they are not part of these L3DL protocols.</t>
<t>To simplify this document, Layer 2 Ethernet framing is not
shown. L3DL is about layer 3.</t>
<t>To simplify this document, Layer 2 framing is not shown. L3DL is
about layer 3.</t>
</section>
<section anchor="ilpo" title="Inter-Link Protocol Overview">
<!-- <t><vspace blankLines="999"/></t> -->
<t>Two devices discover each other and their respective identities
by sending multicast HELLO PDUs (<xref target="hello"/>). To allow
discovery of new devices coming up on a multi-link topology, devices
@ -289,12 +285,14 @@
<t>The HELLO, <xref target="hello"/>, is a priming message. It is
a small L3DL PDU encapsulated in an Ethernet multicast frame with
the simple goal of discovering the identities of logical link
endpoint(s) reachable from an LLEI.</t>
endpoint(s) reachable from a Logical Link Endpoint, <xref
target="llei"/>.</t>
<t>The HELLO and OPEN, <xref target="open"/>, PDUs, which are used
to discover and exchange detailed LLEIs, and the ACK/ERROR PDU,
are mandatory; other PDUs are optional; though at least one
encapsulation MUST be agreed at some point.</t>
to discover and exchange detailed Logical Link Endpoint
Identifiers, LLEIs, and the ACK/ERROR PDU, are mandatory; other
PDUs are optional; though at least one encapsulation MUST be
agreed at some point.</t>
<t>The following is a ladder-style sketch of the L3DL protocol
exchanges:</t>
@ -375,6 +373,10 @@
<t>The L3DL Transport Layer encapsulates each Datagram using a
common transport header.</t>
<t>If a PDU does not fit in a single datagram, it is broken into
multiple datagrams and reassembled by the receiver a la <xref
target="RFC0791"/>.</t>
<!--
protocol "Version:8,L:1,Datagram Number:7,Datagram Length:16,Checksum:32"
-->
@ -398,7 +400,8 @@
<t hangText="L:">A bit that set to one if this Datagram is the
last Datagram of the PDU. For a PDU which fits in only one
Datagram, it is set to one.</t>
Datagram, it is set to one. Note that this is the inverse of the
marking technique used by <xref target="RFC0791"/>.</t>
<t hangText="Datagram Number:">0..127, a monotonically increasing
value, modulo 128, see <xref target="RFC1982"/> which starts at 0
@ -541,9 +544,6 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
the underlying Datagram checksums may be sufficient for integrity,
if not for authentication.</t>
<t>Sig Type 1, aimed at Trust On First Use (TOFU) is specified in
a companion document [ref later].</t>
<t>Other Sig Types may be defined in other documents.</t>
<t hangText="Signature Length:">The length of the Signature,
@ -605,9 +605,10 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>System Identifier, a la <xref target="RFC1629"/>, is an eight
octet identifier unique in the entire operational space. Routers
and switches usually have internal MAC Addresses which can be padded
and used if no System ID exists on the device. If no unique
identifier is burned into a device, the local L3DL configuration
SHOULD create and assign a unique one by configuration.</t>
with high order zeros and used if no System ID exists on the device.
If no unique identifier is burned into a device, the local L3DL
configuration SHOULD create and assign a unique one by
configuration.</t>
<t>ifIndex is the SNMP identifier of the (sub-)interface, see <xref
target="RFC1213"/>. This uniquely identifies the port.</t>
@ -616,6 +617,10 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
Ifindex is that of the logical sub-interface, so no further
disambiguation is needed.</t>
<t>L3DL PDUs learned over VLAN-ports may be interpreted by upper
layer-3 routing protocols as being learned on the corresponding
layer-3 SVI interface for the VLAN.</t>
</section>
<section anchor="hello" title="HELLO">
@ -637,8 +642,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<?rfc subcompact="no"?></list></t>
<t>All other L3DL PDUs are encapsulated in unicast Ethernet frames,
as the peer's destination MAC address is known after the HELLO
<t>All other L3DL PDUs are encapsulated in unicast frames, as the
peer's destination MAC address is known after the HELLO
exchange.</t>
<t>When an interface is turned up on a device, it SHOULD issue a
@ -662,18 +667,18 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
</figure>
<t>If more than one device responds, one adjacency is formed for
each unique (source link address) response. L3DL treats each
adjacency as a separate logical link.</t>
each unique source LLEI response. L3DL treats each adjacency as a
separate logical link.</t>
<t>When a HELLO is received from a source link address with which
there is no established L3DL adjacency, the receiver SHOULD respond
with an OPEN PDU. The two devices establish an L3DL adjacency by
exchanging OPEN PDUs.</t>
<t>When a HELLO is received from a source LLEI with which there is
no established L3DL adjacency, the receiver SHOULD respond with an
OPEN PDU. The two devices establish an L3DL adjacency by exchanging
OPEN PDUs.</t>
<t>The Payload Length is zero as there is no payload.</t>
<t>HELLO PDUs can not be signed as keying material has yet to be
exchanged. Hence the signature MUST always be null.</t>
exchanged. Hence the signature MUST always be the null type.</t>
</section>
@ -681,8 +686,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>Each device has learned the other's MAC Address from the HELLO
exchange, see <xref target="hello"/>. Therefore the OPEN and
subsequent PDUs are unicast, as opposed to the HELLO's multicast,
Ethernet frames.</t>
subsequent PDUs are unicast, as opposed to the HELLO's multicast
frame.</t>
<!--
protocol "Type = 1:8,Payload Length:16,Nonce:32,LLEI Length:8,My LLEI:64,AttrCount:8,Attribute List ...:24,Auth Type:8,Key Length:16,Key ...:40,Sig Type:8,Signature Length:16,Signature ...:40"
@ -715,8 +720,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
</figure>
<t>The Payload Length is the number of octets in all fields of the
PDU from the Nonce to the Key, excluding the Sig Type, the Signature
Length, and the Signature.</t>
PDU from the Nonce through the Key, not including the signature
fields.</t>
<t>The Nonce enables detection of a duplicate OPEN PDU. It SHOULD
be either a random number or the time of day. It is needed to
@ -846,8 +851,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
live at layer 2, the sender resends the PDU using exponential
back-off, see <xref target="RFC1122"/>. This cycle MAY be
repeated a configurable number of times (default three) before it
is considered a failure. The session is considered closed in case
of this ACK failure.</t>
is considered a failure. The session MAY BE considered closed in
case of this ACK failure.</t>
<t>If the link is broken at layer 2, retransmission MAY BE retried
when the link comes back up if data have not changed in the
@ -1235,188 +1240,11 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
</section>
<section anchor="ulps" title="Upper Layer Protocol PDUs">
<t>To facilitate peering and operation of Upper Layer Protocols at
IP layer 3 and above, e.g. BGP sessions, on a link, a neutral TLV
based package Upper Layer Protocol PDU is provided.</t>
<!--
protocol "Type = 8:8,Payload Length:16,ULP Type:8,AttrCount:8,Attribute List ...:24,Sig Type:8,Signature Length:16,Signature ...:8"
-->
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 | Payload Length | ULP Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AttrCount | Attribute List ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sig Type | Signature Length | Signature ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>ULP Type:
<list style="hanging">
<?rfc subcompact="yes"?>
<t hangText="0:">BGP</t>
<?rfc subcompact="no"?></list></t>
<section anchor="bgp" title="BGP ULP Attribute PDUs">
<t>The parameters needed for BGP peering on a link are exchanged
in sub-TLVs within an Upper Layer Protocol PDU. The following
describe the various sub-TLVs for BGP.</t>
<t>If there are multiple BGP sessions on a link, e.g. IPv4 and
IPv6, then multiple Upper Layer Protocol PDUs are exchanged.</t>
<t>As a link may have multiple encapsulations and multiple
addresses for an IP encapsulation, which address of which
encapsulation MUST be specified.</t>
<t>For each BGP peering on a link here MUST be one agreed
encapsulation and matching subnet, and the addresses used MUST be
in the corresponding IPv4/IPv6 Announcement PDUs.</t>
<!--
protocol "Attr Type = 1:8,Attr Len = 48:8,My ASN:32"
-->
<section anchor="asn" title="BGP ASN">
<t>The Autonomous System number MUST be specified. If the AS
Number is less than 32 bits, it is padded with high order
zeros.</t>
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr Type = 1 | Attr Len = 48 | My ASN ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section anchor="bgpv4" title="BGP IPv4 Address">
<!--
protocol "Attr Type = 2:8,Attr Len = 56:8,My IPv4 Peering Address:32,Prefix Len:8"
-->
<t>The BGP IPv Address sub-TLV announces the sender's IPv4 BGP
peering source address to be used by the receiver. At least one
of IPv4 or IPv6 BGP source addresses MUST be announced.</t>
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr Type = 2 | Attr Len = 56 | My IPv4 Peering Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Prefix Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section anchor="bgpv6" title="BGP IPv6 Address">
<t>The BGP IPv6 Address sub-TLV announces the sender's IPv6 BGP
peering source address to be used by the receiver. At least one
of IPv4 or IPv6 BGP source addresses MUST be announced.</t>
<!--
protocol "Attr Type = 3:8,Attr Len = 144:8,My IPv6 Peering Address:128,Prefix Len:8"
-->
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr Type = 3 | Attr Len = 144| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ +
| My IPv6 Peering Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section anchor="bgpmd5" title="BGP MD5 Authentication">
<!--
protocol "Attr Type = 4:8,Attr Len:8,Auth Len:8,MD5 Auth ...:40"
-->
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr Type = 4 | Attr Len | Auth Len | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ MD5 Auth ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section anchor="bgpflags" title="BGP Miscellaneous Flags">
<t>The BGP session OPENs have great capability negotiation
facilities. In case one or more extra attributes might be
needed, the BGP Miscellaneous Flags sub-TLV may be used. No
flags are currently defined.</t>
<!--
protocol "Attr Type = 5:8,Attr Len = 32:8,Misc Flags:16"
-->
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr Type = 5 | Attr Len = 32 | Misc Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>Misc Attrs:
<list hangIndent="11" style="hanging">
<?rfc subcompact="yes"?>
<t hangText="Bit 0 - GKW:">Ghu knows what.</t>
<?rfc subcompact="no"?></list></t>
</section>
</section>
</section>
<section anchor="l3liveness" title="Layers 2.5 and 3 Liveness">
<t>Layer 2 liveness may be continuously tested by KEEPALIVE PDUs,
see <xref target="keepalive"/>. As layer 2.5 or layer 3
connectivity could still break, liveness above layer 2 SHOULD be
connectivity could still break, liveness above layer 2 MAY be
frequently tested using BFD (<xref target="RFC5880"/>) or a similar
technique.</t>
@ -1609,8 +1437,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
5 IPv6 Announcement
6 MPLS IPv4 Announcement
7 MPLS IPv6 Announcement
8 Upper Layer Protocol
9-254 Reserved
8-254 Reserved
255 VENDOR
</artwork>
</figure>
@ -1734,6 +1561,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
</references>
<references title="Informative References">
<?rfc include="reference.RFC.0791"?>
<?rfc include="reference.RFC.1122"?>
<?rfc include="reference.I-D.malhotra-bess-evpn-lsoe"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-doi/reference.DOI.10.1145/2975159.xml?anchor=JUPITER"?>