-01 published, first real doc
This commit is contained in:
parent
1ee9a36046
commit
506c272598
1 changed files with 14 additions and 258 deletions
|
|
@ -11,7 +11,7 @@
|
||||||
<?rfc tocindent="yes"?>
|
<?rfc tocindent="yes"?>
|
||||||
<?rfc tocompact="yes"?>
|
<?rfc tocompact="yes"?>
|
||||||
|
|
||||||
<rfc consensus="yes" category="std" submissionType="IETF" docName="draft-ymbk-idr-l3nd-ulpc-00" ipr="trust200902">
|
<rfc consensus="yes" category="std" submissionType="IETF" docName="draft-ymbk-idr-l3nd-ulpc-01" ipr="trust200902">
|
||||||
|
|
||||||
<front>
|
<front>
|
||||||
|
|
||||||
|
|
@ -75,7 +75,7 @@
|
||||||
|
|
||||||
<t>Massive Data Centers (MDCs) which use upper-layer protocols such
|
<t>Massive Data Centers (MDCs) which use upper-layer protocols such
|
||||||
as BGP4 and other routing protocols may use the Layer-3 Neighbor
|
as BGP4 and other routing protocols may use the Layer-3 Neighbor
|
||||||
Discovery Protocol, L3ND, <!--xref target="I-D.ymbk,l3nd"--> to
|
Discovery Protocol, L3ND, <xref target="I-D.ymbk-idr-l3nd"/> to
|
||||||
reveal the inter-device links of the topology. It is desirable for
|
reveal the inter-device links of the topology. It is desirable for
|
||||||
devices to facilitate the configuration parameters of those upper
|
devices to facilitate the configuration parameters of those upper
|
||||||
layer protocols to enable more hands-free configuration. This
|
layer protocols to enable more hands-free configuration. This
|
||||||
|
|
@ -87,7 +87,7 @@
|
||||||
<section anchor="terminology" title="Reading and Terminology">
|
<section anchor="terminology" title="Reading and Terminology">
|
||||||
|
|
||||||
<t>The reader is assumed to have read Layer-3 Neighbor Discovery
|
<t>The reader is assumed to have read Layer-3 Neighbor Discovery
|
||||||
<!--xref target="I-D.ymbk,l3nd"-->. The terminology and PDUs there
|
<xref target="I-D.ymbk-idr-l3nd"/>. The terminology and PDUs there
|
||||||
are assumed here.</t>
|
are assumed here.</t>
|
||||||
|
|
||||||
<t>Familiarity with the BGP4 Protocol <xref target="RFC4271"/> is
|
<t>Familiarity with the BGP4 Protocol <xref target="RFC4271"/> is
|
||||||
|
|
@ -120,260 +120,18 @@
|
||||||
</artwork>
|
</artwork>
|
||||||
</figure>
|
</figure>
|
||||||
|
|
||||||
<t>The Type and Payload Length are defined in <!--xref
|
<t>The Type and Payload Length are defined in <xref
|
||||||
target="I-D.ymbk,l3nd"-->.</t>
|
target="I-D.ymbk-idr-l3nd"/> apply to this PDU.</t>
|
||||||
|
|
||||||
<?rfc subcompact="yes"?>
|
<t>As the ULPC PDU may contain keying material, e.g. <xref
|
||||||
<t>ULPC Type: An integer denoting the type of the upper-layer
|
target="RFC2385"/>, it SHOULD BE over TLS.</t>
|
||||||
protocol
|
|
||||||
<list style="hanging" hangIndent="6">
|
|
||||||
<t hangText="0 :">Reserved</t>
|
|
||||||
<t hangText="1 :">BGP</t>
|
|
||||||
<t hangText="2-255 :">Reserved</t>
|
|
||||||
<?rfc subcompact="no"?></list></t>
|
|
||||||
|
|
||||||
<t>The AttrCount is the number of attribute sub-TLVs in the
|
|
||||||
Attribute List.</t>
|
|
||||||
|
|
||||||
<t>The Attribute List is a, possibly null, set of sub-TLVs
|
|
||||||
describing the configuration attributes of the specific upper-layer
|
|
||||||
protocol.</t>
|
|
||||||
|
|
||||||
<t>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.</t>
|
|
||||||
|
|
||||||
<!--
|
|
||||||
protocol "Attr Type = 1:8,Attr Len:8,Payload: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 = 1 | Attr Len | Payload |
|
|
||||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
||||||
</artwork>
|
|
||||||
</figure>
|
|
||||||
|
|
||||||
|
|
||||||
<section anchor="bgp" title="BGP ULPC Attribute sub-TLVs">
|
|
||||||
|
|
||||||
<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>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.</t>
|
|
||||||
|
|
||||||
<t>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.</t>
|
|
||||||
|
|
||||||
<t>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.</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 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; 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
|
|
||||||
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 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>
|
|
||||||
|
|
||||||
<!--
|
|
||||||
protocol "Attr Type = 1:8,Attr Len = 6:8,My ASN:32"
|
|
||||||
-->
|
|
||||||
|
|
||||||
<section anchor="asn" title="BGP ASN">
|
|
||||||
|
|
||||||
<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>
|
|
||||||
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 ~
|
|
||||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
||||||
~ |
|
|
||||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
||||||
</artwork>
|
|
||||||
</figure>
|
|
||||||
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section anchor="bgpv4" title="BGP IPv4 Address">
|
|
||||||
|
|
||||||
<!--
|
|
||||||
protocol "Attr Type = 2:8,Attr Len = 7:8,My IPv4 Peering Address:32,Prefix Len:8"
|
|
||||||
-->
|
|
||||||
|
|
||||||
<t>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.</t>
|
|
||||||
|
|
||||||
<t>As usual, the BGP OPEN capability negotiation will determine
|
|
||||||
the AFI/SAFIs to be transported over the peering, see <xref
|
|
||||||
target="RFC4760"/> .</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 = 7 | 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>
|
|
||||||
|
|
||||||
<t>As usual, the BGP OPEN capability negotiation will determine
|
|
||||||
the AFI/SAFIs to be transported over the peering, see <xref
|
|
||||||
target="RFC4760"/> .</t>
|
|
||||||
|
|
||||||
<!--
|
|
||||||
protocol "Attr Type = 3:8,Attr Len = 19: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 = 19 | |
|
|
||||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|
|
||||||
| |
|
|
||||||
+ +
|
|
||||||
| My IPv6 Peering Address |
|
|
||||||
+ +
|
|
||||||
| |
|
|
||||||
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
||||||
| | Prefix Len |
|
|
||||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
||||||
</artwork>
|
|
||||||
</figure>
|
|
||||||
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section anchor="bgpmd5" title="BGP Authentication sub-TLV">
|
|
||||||
|
|
||||||
<t>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 <xref target="RFC2385"/>), the name of a key chain in a
|
|
||||||
KARP database (see <xref target="RFC7210"/>), or one of multiple
|
|
||||||
Authentication sub-TLVs to support hop<xref
|
|
||||||
target="RFC4808"/>.</t>
|
|
||||||
|
|
||||||
<!--
|
|
||||||
protocol "Attr Type = 4:8,Attr Len:8,BGP Authentication Data ...:48"
|
|
||||||
-->
|
|
||||||
|
|
||||||
<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 | ~
|
|
||||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
|
|
||||||
~ BGP Authentication Data ... ~
|
|
||||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
||||||
</artwork>
|
|
||||||
</figure>
|
|
||||||
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section anchor="bgpflags" title="BGP Miscellaneous Flags">
|
|
||||||
|
|
||||||
<t>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.</t>
|
|
||||||
<!--
|
|
||||||
protocol "Attr Type = 5:8,Attr Len = 4: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 = 4 | Misc Flags |
|
|
||||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
||||||
</artwork>
|
|
||||||
</figure>
|
|
||||||
|
|
||||||
<t>Misc Attrs:
|
|
||||||
<list style="hanging">
|
|
||||||
<?rfc subcompact="yes"?>
|
|
||||||
<t hangText="Bit 0: ">GTSM</t>
|
|
||||||
<t hangText="Bit 1-15:">Must be zero</t>
|
|
||||||
<?rfc subcompact="no"?></list></t>
|
|
||||||
|
|
||||||
<t>The GTSM flag indicates that the sender wishes to enable the
|
|
||||||
<xref target="RFC5682"/> Generalized TTL Security Mechanism for
|
|
||||||
the session.</t>
|
|
||||||
|
|
||||||
</section>
|
|
||||||
|
|
||||||
</section>
|
|
||||||
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section anchor="security" title="Security Considerations">
|
|
||||||
|
|
||||||
<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 over TLS.</t>
|
|
||||||
|
|
||||||
<t>Any keying material in the PDU SHOULD BE salted and hashed.</t>
|
<t>Any keying material in the PDU SHOULD BE salted and hashed.</t>
|
||||||
|
|
||||||
<t>The BGP Authentication sub-TLV provides for provisioning MD5,
|
<t>The BGP Authentication sub-TLV provides for provisioning MD5,
|
||||||
which is a quite weak hash, horribly out of fashion, and kills
|
which is a quite weak hash, horribly out of fashion, and kills
|
||||||
puppies. But, like it or not, it has been sufficient against the
|
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.</t>
|
deployments use.</t>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
|
@ -408,13 +166,12 @@
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<!--
|
|
||||||
<section anchor="acks" title="Acknowledgments">
|
<section anchor="acks" title="Acknowledgments">
|
||||||
|
|
||||||
<t>The authors thank.</t>
|
<t>The authors thank Rob Austein and Sue Hares.</t>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
-->
|
|
||||||
</middle>
|
</middle>
|
||||||
|
|
||||||
<back>
|
<back>
|
||||||
|
|
@ -422,16 +179,15 @@
|
||||||
<references title="Normative References">
|
<references title="Normative References">
|
||||||
<?rfc include="reference.RFC.2119.xml"?>
|
<?rfc include="reference.RFC.2119.xml"?>
|
||||||
<?rfc include="reference.RFC.4271.xml"?>
|
<?rfc include="reference.RFC.4271.xml"?>
|
||||||
<?rfc include="reference.RFC.4760.xml"?>
|
<!--<?rfc include="reference.RFC.4760.xml"?> -->
|
||||||
<?rfc include="reference.RFC.5226.xml"?>
|
<?rfc include="reference.RFC.5226.xml"?>
|
||||||
<?rfc include="reference.RFC.5682.xml"?>
|
|
||||||
<?rfc include="reference.RFC.8174.xml"?>
|
<?rfc include="reference.RFC.8174.xml"?>
|
||||||
<?rfc include="reference.I-D.ietf-lsvr-l3dl.xml"?>
|
<?rfc include="reference.I-D.ymbk-idr-l3nd.xml"?>
|
||||||
</references>
|
</references>
|
||||||
<references title="Informative References">
|
<references title="Informative References">
|
||||||
<?rfc include="reference.RFC.2385.xml"?>
|
<?rfc include="reference.RFC.2385.xml"?>
|
||||||
<?rfc include="reference.RFC.4808.xml"?>
|
<!--<?rfc include="reference.RFC.4808.xml"?> -->
|
||||||
<?rfc include="reference.RFC.7210.xml"?>
|
<!--<?rfc include="reference.RFC.7210.xml"?> -->
|
||||||
</references>
|
</references>
|
||||||
|
|
||||||
</back>
|
</back>
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue