diff --git a/draft-ymbk-idr-l3nd-ulpc.xml b/draft-ymbk-idr-l3nd-ulpc.xml index db97a19..a721544 100644 --- a/draft-ymbk-idr-l3nd-ulpc.xml +++ b/draft-ymbk-idr-l3nd-ulpc.xml @@ -11,7 +11,7 @@ - + @@ -75,7 +75,7 @@ Massive Data Centers (MDCs) which use upper-layer protocols such as BGP4 and other routing protocols may use the Layer-3 Neighbor - Discovery Protocol, L3ND, to + 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 @@ -87,7 +87,7 @@
The reader is assumed to have read Layer-3 Neighbor Discovery - . The terminology and PDUs there + . The terminology and PDUs there are assumed here. Familiarity with the BGP4 Protocol is @@ -120,260 +120,18 @@ - The Type and Payload Length are defined in . + The Type and Payload Length are defined in apply to this PDU. - - ULPC Type: An integer denoting the type of the upper-layer - protocol - - Reserved - BGP - Reserved - - - The AttrCount is the number of attribute sub-TLVs in the - Attribute List. - - The Attribute List is a, possibly null, set of sub-TLVs - describing the configuration attributes of the specific upper-layer - protocol. - - An Attribute consists of a one octet Attribute Type, a one octet - Attribute Length of the number of octets in the Attribute, and a - Payload of arbitrary length up to 253 octets. - - - -
- - 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 | Payload | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
- - -
- - 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. - - The goal is to provide the minimal set of configuration - parameters needed by BGP OPEN to successfully start a BGP peering. - The goal is specifically not to replace or conflict with data - exchanged during BGP OPEN. Multiple sources of truth are a recipe - for complexity and hence pain. - - If there are multiple BGP sessions on a link, e.g., IPv4 and - IPv6, then multiple sets of BGP sub-TLVs MAY BE exchanged within - the BGP ULPC PDU or multiple BGP ULPC PDUs may be sent, one for - each address family. - - A peer receiving BGP ULPC PDUs has only one active BGP ULPC PDU - 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 BGP session and then send a new BGP - ULPC PDU. - - As a link may have multiple encapsulations and multiple - 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 - 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 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. - - - -
- - The Autonomous System number of the sender MUST be specified. - If the AS Number is less than 32 bits, it is padded with high - order zeros. - -
- - 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 = 6 | My ASN ~ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
- -
- -
- - - - The BGP IPv4 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. - - As usual, the BGP OPEN capability negotiation will determine - the AFI/SAFIs to be transported over the peering, see . - -
- - 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 = 7 | My IPv4 Peering Address ~ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ | Prefix Len | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
- -
- -
- - 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. - - As usual, the BGP OPEN capability negotiation will determine - the AFI/SAFIs to be transported over the peering, see . - - - -
- - 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 = 19 | | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + -| | -+ + -| My IPv6 Peering Address | -+ + -| | -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| | Prefix Len | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
- -
- -
- - The BGP Authentication sub-TLV provides any authentication - data needed to OPEN the BGP session. Depending on operator - configuration of the environment, it might be a simple MD5 key - (see ), the name of a key chain in a - KARP database (see ), or one of multiple - Authentication sub-TLVs to support hop. - - - -
- - 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 | ~ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ -~ BGP Authentication Data ... ~ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
- -
- -
- - The BGP session OPEN has extensive, and a bit complex, - 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. - - -
- - 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 = 4 | Misc Flags | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
- - Misc Attrs: - - - GTSM - Must be zero - - - The GTSM flag indicates that the sender wishes to enable the - Generalized TTL Security Mechanism for - the session. - -
- -
- -
- -
- - All the Security considerations of apply to this PDU. - - As the ULPC PDU may contain keying material, see , it SHOULD BE over TLS. + As the ULPC PDU may contain keying material, e.g. , it SHOULD BE over TLS. Any keying material in the PDU SHOULD BE salted and hashed. The BGP Authentication sub-TLV provides for provisioning MD5, which is a quite weak hash, horribly out of fashion, and kills puppies. But, like it or not, it has been sufficient against the - kinds of attacks BGP TCP sessions have endured. Soit is what BGP + kinds of attacks BGP TCP sessions have endured. So it is what BGP deployments use.
@@ -408,13 +166,12 @@ - + @@ -422,16 +179,15 @@ - + - - + - - + +