From e5af9a8923e25d3c9c831fe65a474f3a397a99d4 Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Wed, 9 Feb 2022 12:42:59 -0800 Subject: [PATCH] modified for l3nd --- draft-ymbk-idr-l3nd-ulpc.xml | 84 +++++++++++++++++------------------- 1 file changed, 40 insertions(+), 44 deletions(-) diff --git a/draft-ymbk-idr-l3nd-ulpc.xml b/draft-ymbk-idr-l3nd-ulpc.xml index b7adc90..db97a19 100644 --- a/draft-ymbk-idr-l3nd-ulpc.xml +++ b/draft-ymbk-idr-l3nd-ulpc.xml @@ -15,7 +15,7 @@ - L3DL Upper-Layer Protocol Configuration + L3ND Upper-Layer Protocol Configuration Arrcus & IIJ @@ -49,8 +49,8 @@ - This document uses the Layer-3 Liveness and Discovery protocol - to communicate the parameters needed to exchange inter-device Upper + This document uses the Layer-3 Neighbor Discovery protocol to + communicate the parameters needed to exchange inter-device Upper Layer Protocol Configuration for upper-layer protocols such as the BGP family. @@ -74,25 +74,24 @@
Massive Data Centers (MDCs) which use upper-layer protocols such - as BGP4, BGP-LS, BGP-SPF, etc. may use the Layer-3 Liveness and - Discovery Protocol, L3DP, to + as BGP4 and other routing protocols may use the Layer-3 Neighbor + Discovery Protocol, L3ND, to reveal the inter-device links of the topology. It is desirable for devices to facilitate the configuration parameters of those upper layer protocols to enable more hands-free configuration. This - document defines a new L3DP PDU to communicate these Upper-Layer + document defines a new L3ND PDU to communicate these Upper-Layer Protocol Configuration parameters.
- The reader is assumed to have read Layer-3 Discovery and Liveness - . The terminology and PDUs there + The reader is assumed to have read Layer-3 Neighbor Discovery + . The terminology and PDUs there are assumed here. Familiarity with the BGP4 Protocol is - assumed. Familiarity with BGP-SPF, , might be useful. + assumed.
@@ -104,7 +103,7 @@ PDU is defined as follows:
@@ -112,19 +111,17 @@ 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 = 9 | Payload Length ~ +| Version = 0 | Type = 8 | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ | ULPC Type | AttrCount | ~ +| | ULPC Type | AttrCount | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ Attribute List ... | Sig Type | Signature Len ~ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ | Signature ... | +| Attribute List ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- The Type and Payload Length are defined in . + The Type and Payload Length are defined in . ULPC Type: An integer denoting the type of the upper-layer @@ -179,37 +176,37 @@ each address family. A peer receiving BGP ULPC PDUs has only one active BGP ULPC PDU - for an particular address family at any point in time; receipt of - a new BGP ULPC PDU for a particular address family replaces any - previous one. + for an particular address family on a specific link at any point + in time; receipt of a new BGP ULPC PDU for a particular address + family replaces any previous one. If there are one or more open BGP sessions, receipt of a new BGP ULPC PDU does not affect these sessions and the PDU SHOULD be discarded. If a peer wishes to replace an open BGP session, they - must first close the running session and then send a new BGP ULPC - PDU. + MUST first close the running BGP session and then send a new BGP + ULPC PDU. As a link may have multiple encapsulations and multiple - addresses for an IP encapsulation, which address of which - encapsulation is to be used for the BGP session MUST be + addresses for an IP encapsulation; therefore which address of + which encapsulation is to be used for the BGP session MUST be specified. For each BGP peering on a link here MUST be one agreed encapsulation, and the addresses used MUST be in the corresponding - L3DP IPv4/IPv6 Announcement PDUs. If the choice is ambiguous, an + L3ND IPv4/IPv6 Announcement PDUs. If the choice is ambiguous, an Attribute may be used to signal preferences. - If a peering address has been announced as a loopback, - i.e. MUST BE flagged as such in the L3DL Encapsulation PDU (see - Sec. 13.2), a two or three hop - BGP session will be established. Otherwise a direct one hop - session is used. The BGP session to a loopback will forward to - the peer's address which was marked as Primary in the L3DL - Encapsulation Flags, iff it is in a subnet which is shared with - both BGP speakers. If the primary is not in a common subnet, then - the BGP speaker MAY pick a forwarding next hop that is in a subnet - they share. If there are multiple choices, the BGP speaker SHOULD - have signaled which subnet to choose in an Upper-Layer Protocol + If a peering address has been announced as a loopback, i.e. + MUST BE flagged as such in the L3ND Encapsulation PDU (see Sec. 13.2), a two or three hop BGP + session will be established. Otherwise a direct one hop session + is used. The BGP session to a loopback will forward to the peer's + address which was marked as Primary in the L3DL Encapsulation + Flags, iff it is in a subnet which is shared with both BGP + speakers. If the primary is not in a common subnet, then the BGP + speaker MAY pick a forwarding next hop that is in a subnet they + share. If there are multiple choices, the BGP speaker SHOULD have + signaled which subnet to choose in an Upper-Layer Protocol Configuration PDU Attribute. apply to this PDU. As the ULPC PDU may contain keying material, see , it SHOULD BE signed. + target="bgpmd5"/>, it SHOULD BE over TLS. Any keying material in the PDU SHOULD BE salted and hashed. @@ -435,7 +432,6 @@ -