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 target="I-D.ietf-lsvr-bgp-spf"/> provides massive scale-out without
centralization using a tried and tested scalable distributed control centralization using a tried and tested scalable distributed control
plane, offering a scalable routing solution in Clos <xref plane, offering a scalable routing solution in Clos <xref
target="Clos0"/><xref target="Clos1"/> and similar environments. But target="Clos0"/><xref target="Clos1"/> and similar environments.
BGP-SPF and similar higher level device-spanning protocols, But BGP-SPF and similar higher level device-spanning protocols,
e.g. <xref target="I-D.malhotra-bess-evpn-lsoe"/>, need logical link e.g. <xref target="I-D.malhotra-bess-evpn-lsoe"/>, need logical link
state and addressing data from the network to build the routing state and addressing data from the network to build the routing
topology. They also need prompt reaction to (logical) link topology. They also need prompt but prudent reaction to (logical)
failure.</t> link failure.</t>
<t>Layer 3 Discovery and Liveness (L3DL) provides brutally simple <t>Layer 3 Discovery and Liveness (L3DL) provides brutally simple
mechanisms for devices to <list style="symbols"> mechanisms for devices to <list style="symbols">
<t>Discover unique identities of devices/ports/... on a logical <t>Discover unique identities of devices/ports/... on a logical
link,</t> link,</t>
<t>Run Layer 2 keep-alive messages for session continuity,</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 mutually supported encapsulations, e.g. IP/MPLS,</t>
<t>Discover Layer 3 IP and/or MPLS addressing of interfaces of the <t>Discover Layer 3 IP and/or MPLS addressing of interfaces of the
encapsulations,</t> encapsulations,</t>
@ -186,12 +186,10 @@
<t>L3DL assumes a Clos type datacenter scale and topology, but can <t>L3DL assumes a Clos type datacenter scale and topology, but can
accommodate richer topologies which contain potential cycles.</t> accommodate richer topologies which contain potential cycles.</t>
<t>While L3DL is designed for the MDC, there are no inherent <t>While L3DL is designed for the MDC, there are no inherent reasons
reasons it could not run on a WAN; though, as it is simply a it could not run on a WAN. The authentication and authorization
discovery protocol, it is not clear that this would be useful. needed to run safely on a WAN need to be considered, and the
The authentication and authorization needed to run safely on a appropriate level of security options chosen.</t>
WAN need to be considered, and the appropriate level of security
options chosen.</t>
<t>L3DL assumes a new IEEE assigned EtherType (TBD).</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>Layer 2 Liveness Checks may be started</t>
<t>Encapsulation data are exchanged and IP-Level Liveness Checks <t>Encapsulation data are exchanged and IP-Level Liveness Checks
enabled</t> enabled</t>
<t>A BGP-like protocol is assumed to use these data to discover <t>A BGP-like upper layer protocol is assumed to use these data to
and build a topology database</t> discover and build a topology database</t>
</list></t> </list></t>
<figure> <figure>
@ -262,15 +260,13 @@
<t>The upper layer BGP family routing protocols cross all the <t>The upper layer BGP family routing protocols cross all the
devices, though they are not part of these L3DL protocols.</t> devices, though they are not part of these L3DL protocols.</t>
<t>To simplify this document, Layer 2 Ethernet framing is not <t>To simplify this document, Layer 2 framing is not shown. L3DL is
shown. L3DL is about layer 3.</t> about layer 3.</t>
</section> </section>
<section anchor="ilpo" title="Inter-Link Protocol Overview"> <section anchor="ilpo" title="Inter-Link Protocol Overview">
<!-- <t><vspace blankLines="999"/></t> -->
<t>Two devices discover each other and their respective identities <t>Two devices discover each other and their respective identities
by sending multicast HELLO PDUs (<xref target="hello"/>). To allow by sending multicast HELLO PDUs (<xref target="hello"/>). To allow
discovery of new devices coming up on a multi-link topology, devices 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 <t>The HELLO, <xref target="hello"/>, is a priming message. It is
a small L3DL PDU encapsulated in an Ethernet multicast frame with a small L3DL PDU encapsulated in an Ethernet multicast frame with
the simple goal of discovering the identities of logical link 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 <t>The HELLO and OPEN, <xref target="open"/>, PDUs, which are used
to discover and exchange detailed LLEIs, and the ACK/ERROR PDU, to discover and exchange detailed Logical Link Endpoint
are mandatory; other PDUs are optional; though at least one Identifiers, LLEIs, and the ACK/ERROR PDU, are mandatory; other
encapsulation MUST be agreed at some point.</t> 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 <t>The following is a ladder-style sketch of the L3DL protocol
exchanges:</t> exchanges:</t>
@ -375,6 +373,10 @@
<t>The L3DL Transport Layer encapsulates each Datagram using a <t>The L3DL Transport Layer encapsulates each Datagram using a
common transport header.</t> 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" 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 <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 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 <t hangText="Datagram Number:">0..127, a monotonically increasing
value, modulo 128, see <xref target="RFC1982"/> which starts at 0 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, the underlying Datagram checksums may be sufficient for integrity,
if not for authentication.</t> 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>Other Sig Types may be defined in other documents.</t>
<t hangText="Signature Length:">The length of the Signature, <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 <t>System Identifier, a la <xref target="RFC1629"/>, is an eight
octet identifier unique in the entire operational space. Routers octet identifier unique in the entire operational space. Routers
and switches usually have internal MAC Addresses which can be padded and switches usually have internal MAC Addresses which can be padded
and used if no System ID exists on the device. If no unique with high order zeros and used if no System ID exists on the device.
identifier is burned into a device, the local L3DL configuration If no unique identifier is burned into a device, the local L3DL
SHOULD create and assign a unique one by configuration.</t> configuration SHOULD create and assign a unique one by
configuration.</t>
<t>ifIndex is the SNMP identifier of the (sub-)interface, see <xref <t>ifIndex is the SNMP identifier of the (sub-)interface, see <xref
target="RFC1213"/>. This uniquely identifies the port.</t> 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 Ifindex is that of the logical sub-interface, so no further
disambiguation is needed.</t> 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>
<section anchor="hello" title="HELLO"> <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> <?rfc subcompact="no"?></list></t>
<t>All other L3DL PDUs are encapsulated in unicast Ethernet frames, <t>All other L3DL PDUs are encapsulated in unicast frames, as the
as the peer's destination MAC address is known after the HELLO peer's destination MAC address is known after the HELLO
exchange.</t> exchange.</t>
<t>When an interface is turned up on a device, it SHOULD issue a <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> </figure>
<t>If more than one device responds, one adjacency is formed for <t>If more than one device responds, one adjacency is formed for
each unique (source link address) response. L3DL treats each each unique source LLEI response. L3DL treats each adjacency as a
adjacency as a separate logical link.</t> separate logical link.</t>
<t>When a HELLO is received from a source link address with which <t>When a HELLO is received from a source LLEI with which there is
there is no established L3DL adjacency, the receiver SHOULD respond no established L3DL adjacency, the receiver SHOULD respond with an
with an OPEN PDU. The two devices establish an L3DL adjacency by OPEN PDU. The two devices establish an L3DL adjacency by exchanging
exchanging OPEN PDUs.</t> OPEN PDUs.</t>
<t>The Payload Length is zero as there is no payload.</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 <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> </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 <t>Each device has learned the other's MAC Address from the HELLO
exchange, see <xref target="hello"/>. Therefore the OPEN and exchange, see <xref target="hello"/>. Therefore the OPEN and
subsequent PDUs are unicast, as opposed to the HELLO's multicast, subsequent PDUs are unicast, as opposed to the HELLO's multicast
Ethernet frames.</t> 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" 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> </figure>
<t>The Payload Length is the number of octets in all fields of the <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 PDU from the Nonce through the Key, not including the signature
Length, and the Signature.</t> fields.</t>
<t>The Nonce enables detection of a duplicate OPEN PDU. It SHOULD <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 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 live at layer 2, the sender resends the PDU using exponential
back-off, see <xref target="RFC1122"/>. This cycle MAY be back-off, see <xref target="RFC1122"/>. This cycle MAY be
repeated a configurable number of times (default three) before it repeated a configurable number of times (default three) before it
is considered a failure. The session is considered closed in case is considered a failure. The session MAY BE considered closed in
of this ACK failure.</t> case of this ACK failure.</t>
<t>If the link is broken at layer 2, retransmission MAY BE retried <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 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>
<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"> <section anchor="l3liveness" title="Layers 2.5 and 3 Liveness">
<t>Layer 2 liveness may be continuously tested by KEEPALIVE PDUs, <t>Layer 2 liveness may be continuously tested by KEEPALIVE PDUs,
see <xref target="keepalive"/>. As layer 2.5 or layer 3 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 frequently tested using BFD (<xref target="RFC5880"/>) or a similar
technique.</t> technique.</t>
@ -1609,8 +1437,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
5 IPv6 Announcement 5 IPv6 Announcement
6 MPLS IPv4 Announcement 6 MPLS IPv4 Announcement
7 MPLS IPv6 Announcement 7 MPLS IPv6 Announcement
8 Upper Layer Protocol 8-254 Reserved
9-254 Reserved
255 VENDOR 255 VENDOR
</artwork> </artwork>
</figure> </figure>
@ -1734,6 +1561,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
</references> </references>
<references title="Informative References"> <references title="Informative References">
<?rfc include="reference.RFC.0791"?>
<?rfc include="reference.RFC.1122"?> <?rfc include="reference.RFC.1122"?>
<?rfc include="reference.I-D.malhotra-bess-evpn-lsoe"?> <?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"?> <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-doi/reference.DOI.10.1145/2975159.xml?anchor=JUPITER"?>