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

modified for l3nd

Browse source
This commit is contained in:
Randy Bush 2022-02-09 12:42:59 -08:00
parent 464fb20cb7
commit e5af9a8923
1 changed files with 40 additions and 44 deletions
Download patch file Download diff file Expand all files Collapse all files

84
draft-ymbk-idr-l3nd-ulpc.xml
View file

@ -15,7 +15,7 @@
<front>
<title>L3DL Upper-Layer Protocol Configuration</title>
<title>L3ND Upper-Layer Protocol Configuration</title>
<author fullname="Randy Bush" initials="R." surname="Bush">
<organization>Arrcus &amp; IIJ</organization>
@ -49,8 +49,8 @@
<abstract>
<t>This document uses the Layer-3 Liveness and Discovery protocol
to communicate the parameters needed to exchange inter-device Upper
<t>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.
</t>
@ -74,25 +74,24 @@
<section anchor="intro" title="Introduction">
<t>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, <xref target="I-D.ietf-lsvr-l3dl"/> to
as BGP4 and other routing protocols may use the Layer-3 Neighbor
Discovery Protocol, L3ND, <!--xref target="I-D.ymbk,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.</t>
</section>
<section anchor="terminology" title="Reading and Terminology">
<t>The reader is assumed to have read Layer-3 Discovery and Liveness
<xref target="I-D.ietf-lsvr-l3dl"/>. The terminology and PDUs there
<t>The reader is assumed to have read Layer-3 Neighbor Discovery
<!--xref target="I-D.ymbk,l3nd"-->. The terminology and PDUs there
are assumed here.</t>
<t>Familiarity with the BGP4 Protocol <xref target="RFC4271"/> is
assumed. Familiarity with BGP-SPF, <xref
target="I-D.ietf-lsvr-bgp-spf"/>, might be useful. </t>
assumed.</t>
</section>
@ -104,7 +103,7 @@
PDU is defined as follows:</t>
<!--
protocol "Type = 8:9,Payload Length:32,ULPC Type:8,AttrCount:8,Attribute List ...:24,Sig Type:8,Signature Len:16,Signature ...:24"
protocol "Version = 0:8,Type = 8:8,Payload Length:32,ULPC Type:8,AttrCount:8,Attribute List ...:32"
-->
<figure>
@ -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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The Type and Payload Length are defined in <xref
target="I-D.ietf-lsvr-l3dl"/>.</t>
<t>The Type and Payload Length are defined in <!--xref
target="I-D.ymbk,l3nd"-->.</t>
<?rfc subcompact="yes"?>
<t>ULPC Type: An integer denoting the type of the upper-layer
@ -179,37 +176,37 @@
each address family.</t>
<t>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.</t>
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.</t>
<t>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.</t>
MUST first close the running BGP session and then send a new BGP
ULPC PDU.</t>
<t>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.</t>
<t>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.</t>
<t>If a peering address has been announced as a loopback,
i.e. MUST BE flagged as such in the L3DL Encapsulation PDU (see
<xref target="I-D.ietf-lsvr-l3dl"/> 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
<t>If a peering address has been announced as a loopback, i.e.
MUST BE flagged as such in the L3ND Encapsulation PDU (see <xref
target="I-D.ietf-lsvr-l3dl"/> 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.</t>
<!--
@ -218,9 +215,9 @@
<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>
<t>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.</t>
<figure>
<artwork>
@ -365,11 +362,11 @@
<section anchor="security" title="Security Considerations">
<t>All the Security considerations of <xref
target="I-D.ietf-lsvr-l3dl"/> apply to this PDU.</t>
<t>All the Security considerations of <!--xref
target="I-D.ymbk,l3nd"--> apply to this PDU.</t>
<t>As the ULPC PDU may contain keying material, see <xref
target="bgpmd5"/>, it SHOULD BE signed.</t>
target="bgpmd5"/>, it SHOULD BE over TLS.</t>
<t>Any keying material in the PDU SHOULD BE salted and hashed.</t>
@ -435,7 +432,6 @@
<?rfc include="reference.RFC.2385.xml"?>
<?rfc include="reference.RFC.4808.xml"?>
<?rfc include="reference.RFC.7210.xml"?>
<?rfc include="reference.I-D.ietf-lsvr-bgp-spf.xml"?>
</references>
</back>