One document matched: draft-hares-idr-nexthop-path-record-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2385 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2385.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC5925 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5925.xml">
<!ENTITY I-D.keyupate-idr-i2rs-bgp-usecases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.keyupate-idr-i2rs-bgp-usecases.xml">
<!ENTITY I-D.ietf-idr-custom-decision SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-custom-decision.xml">
<!ENTITY I-D.ietf-mpls-seamless-mpls SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-seamless-mpls.xml">
<!ENTITY I-D.ietf-idr-add-paths SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-add-paths.xml">
<!ENTITY I-D.ietf-idr-error-handling SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-error-handling.xml">
<!ENTITY I-D.rosen-idr-tunnel-encaps SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rosen-idr-tunnel-encaps.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-hares-idr-nexthop-path-record-00" ipr="trust200902">
<front>
<title abbrev="NEXTHOP_PATH_RECORD">Record NEXTHOP_PATH ATTIBUTE for BGP</title>
<author fullname="Susan Hares" initials="S." surname="Hares">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>7453 Hickory Hill</street>
<city>Saline</city>
<region>MI</region>
<code>48176</code>
<country>USA</country>
</postal>
<email>shares@ndzh.com</email>
</address>
</author>
<author fullname="Zhenbin Li" initials="Z. " surname="Li">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>lizhenbin@huawei.com</email>
</address>
</author>
<author fullname="Li Zhang" initials="L." surname="Zhang ">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>monica.zhangli@huawei.com</email>
</address>
</author>
<date year="2015"/>
<abstract>
<t> In some BGP deployments, BGP next hops may use a set or
tunnels or run across converged networks such as seamless MPLS.
This document describes a new optional
transitive path attribute, NEXTHOP_PATH ATTRIBUTE for BGP
that records the next hop path which can be used
by BGP network management to monitor and manage the
BGP infrastructure via management interfaces (such as I2RS).
</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
<xref target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>Network topologies may use BGP to become more highly interconnected
via tunnels <xref target="I-D.rosen-idr-tunnel-encaps"></xref>
or become interconnected carrier MPLS networks that
<xref target="I-D.ietf-mpls-seamless-mpls"></xref>
with multiple IGPs connected by IBGP into a single AS.
In addition, BGP provides teh ability to use
provide additions paths <xref target="I-D.ietf-idr-add-paths"></xref>,
or use custom decision paths <xref target="I-D.ietf-idr-custom-decision"></xref>
This document proposes a new path attribute that can record the next
hop path of the route to help network management debugging of
these new scenarios. </t>
</section>
<section title="Definition of NEXTHOP_PATH_RECORD ATTRIBUTE">
<t>The NEXTHOP_PATH_RECORD ATTRIBUTE is an optional transitive BGP Path
Attribute. The NEXTHOP_PATH_RECORD ATTRIBUTE type is defined as below (refer to
<xref target="RFC4271"></xref> ):
</t>
<t><figure>
<artwork>
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr. Flags |Attr. Type Code|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 NEXTHOP_PATH_RECORD ATTRIBUTE Type definition
</artwork>
</figure>Attr. Flags</t>
<t>SHOULD be optional transitive</t>
<t>Attr. Type Code</t>
<t>SHOULD be allocated by IANA</t>
<t>NEXTHOP_PATH is composed of a sequence of next hop path segments.
Each next hop path segment is represented by a triple <path segment
type, path segment length, path segment value>. The format of the
next hop path segment is shown in the figure 3.</t>
<t>
<figure align="center">
<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 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 NH_SEQUENCE_V4 TLV
</artwork>
</figure>
</t>
<t> Type: A single octet encoding the TLV Type of path segement.
The Type of NH_SEQENCE_V4 is defined in this document, which needs to be
allocated by IANA. A registry for other types of NH Path segements
should be established by IANA.</t>
<t>Length: Two octets encoding the length in octets of the TLV,
including the type and length fields. The length is encoded as an
unsigned binary integer.</t>
<t>Reserved: A single octet that must be zero now.</t>
<t>NextHop: This contains a variable length of NextHops.
For type NH_SEQUENCE_V4 the length of this value is four octets. </t>
</section>
<section title="Process of NEXTHOP_PATH_RECORD ATTRIBUTE" >
<t> The NEXTHOP_PATH attribute defined in this section is an
optional transitive BGP Path Attribute as described in
<xref target="RFC4271"></xref>.
</t>
<section title="Creating and Modifying the NEXTHOP_PATH Attribute">
<t>When a BGP speaker distributes a route to its BGP peer within
UPDATE message, the NEXTHOP_PATH ATTRIBUTE should be processed based
on different route states:</t>
<t><list style="numbers">
<t>If the route is originated in this BGP speaker
<list style="symbols">
<t>If the NEXTHOP_PATH ATTRIBUTE is supported, the
NEXTHOP_PATH ATTRIBUTE SHOULD be originated including the BGP
speaker's own next hop address in a next hop path segment. In
this case, the next hop address of the originating BGP speaker
will be the only entry of the next hop path segment, and this
path segment will be the only segment in NEXTHOP_PATH
ATTRIBUTE.</t>
<t>If the NEXTHOP_PATH_RECORD ATTRIBUTE is not supported, the route
will be distributed without NEXTHOP_PATH ATTRIBUTE.</t>
</list></t>
<t>if the route is received from one BGP speaker's UPDATE
message and and the NEXTHOP_PATH_RECORD is enabled
and the nexthop is changed (via nexthop self or other means)
<list style="symbols">
<t>If the NEXTHOP_PATH_RECORD ATTRIBUTE is NULL
the NEXTHOP_PATH ATTRIBUTE SHOULD be originated including the
BGP speaker's own next hop address in a next hop path segment.
In this case, the next hop address of this BGP speaker will be
the only entry to the next hop path segment, and this path
segment will be the only segment in NEXTHOP_PATH ATTRIBUTE</t>
<t>If the NEXTHOP_PATH_RECORD ATTRIBUTE is non-NULL and the local BGP
speaker support NEXTHOP_PATH ATTRIBUTE, when the route is
propagated to another IBGP speaker with next hop self (NHS ),
the BGP speaker MUST appends its own next hop address as the
last one of the next hop path segments.</t>
</list></t>
<t>If the NEXTHOP_PATH_RECORD ATTRIBUTE is non-NULL and the local BGP
speaker support NEXTHOP_PATH ATTRIBUTE, when the route is
propagated to another BGP speaker without changing the next
hop by the BGP speaker, the BGP speaker MUST NOT change the
next hop path sequence.</t>
<t>If the BGP does not support the NEXTHOP_PATH record,
it should keep the NEXTHOP_PATH RECORD unchanged.</t>
</list></t>
</section>
<section title="Error handling of NEXTHOP_PATH_RECORD Attribute">
<t>
If there are errors in the internal format of the NEXTHOP_PATH attribute,
this attribute should simply be discarded as
<xref target="I-D.ietf-idr-error-handling"></xref> specifies in
section 3 as Attribute discard. The NEXTHOP_PATH_RECORD simply
records nexthop information for monitoring.
</t>
</section>
</section>
<section title="Deployment considerations">
<t>Two deployment examples are given to demonstrate how the
nexthop information can be deployed in existing BGP technologies to
monitor and tune the BGP clouds (IBGP or EBGP) to provide better operation.
maintenance. This attribute has records information.
</t>
<section title="BGP Tunnels ">
<t> The <xref target="I-D.rosen-idr-tunnel-encaps"></xref>
describes how BGP nexthop can be a set of tunnels. NEXTHOP_PATH_RECORD
attribute can allow BGP routers to record when the BGP nexthop changes.
</t>
</section>
<section title="Customized Best Path Selection">
<t> The next_hop information gathered on an IBGP or EBP route could be
used by off-line decision processing to select paths, and
re-inserted as policy to affect the decision making via I2RS.
The I2RS BGP use case draft <xref target="I-D.keyupate-idr-i2rs-bgp-usecases"></xref>
describes this its section on customized best path selection (section 4.1)
which uses the BGP feature <xref target="I-D.ietf-idr-custom-decision"></xref>
to set a custom decision community. </t>
</section>
<section title="Use in Seamless MPLS case with PE-RR ">
<t>In a Seamless MPLS network <xref target="I-D.ietf-mpls-seamless-mpls"></xref>,
the Area Border Routers (ABRs) which run IBGP may act RR-clients
or be part of RR mesh as described in section 5.1.7.
Seamless MPLS places restrictions on the BGP NEXT_HOP
to make Seamless MPLS work in the general case, but this
may be tuned by tunnels or additional paths or other
mechanism. </t>
<t>
<figure align="center">
<artwork>
Inline RR Inline RR Inline RR
+------+ +------+ +------+
/ |ABR-a |---------|ABR-b |--------|ABR-c |
/ +------+ +------+ +------+\
/ | | | \
+-----+/ | | | \
|PE1 | IGP area1 | IGP area2 | IGP area3 | IGP area4 \+-----+
+-----+\ | | | | PE2|
\ | | | /+-----+
\ +------+ +------+ +---- -+ /
\|ABR-a'|---------|ABR-b'|--------|ABR-c'| /
+------+ +------+ +---- -+/
Inline RR Inline RR Inline RR
Figure 1 Seamless MPLS Network with Multiple IGP Areas
</artwork>
</figure>
</t>
<t>NEXTHOP_PATH_RECORD attribution
may aid in monitoring paths in this complex paths that may consists
of tunnels, customized paths, or Seamless MPLS topology. </t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>IANA need to assign the codepoint in the "BGP Path Attributes"
registry to the NEXTHOP_PATH_RECORD ATTRIBUTE.</t>
<t>IANA shall create a registry for "next hop path segment". The type
field consists of a single octet, with possible values from 0 to 255.
The allocation policy for this field is to be "Standards Action with
Early Allocation". A new Type should be defined as "NH_SEQUENCE_V4".</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Note that, the NEXTHOP_PATH ATTRIBUTE is defined as a optional
transitive BGP Path attribute. Both the IBGP and EBGP speaker can use
this attribute. When an ASBR propagates the route receive from a IBGP
peer to an EBGP peer, the NEXTHOP_PATH ATTRIBUTE will be distribute to
the EBGP Speaker which may be controlled by other Service Provider.
If the EBGP speaker can support the NEXTHOP_PATH ATTRIBUTE, it can parse
the NEXTHOP_PATH ATTRIBUTE to get the inner network architecture of the
other network.</t>
<t> BGP requires the use of TCP-MD5 <xref target="RFC2385">TCP-MD5</xref>
or <xref target="RFC5925">TCP-AO</xref>). Use of encryption will prevent
unauthorized view of the NEXTHOP_PATH. For those not supporting
the required TCP-MD5 or TCP-AO, the NEXTHOP_PATH
ATTRIBUTE capability SHOULD disabled for specific BGP speaker to
prevent this attack. </t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC2385;
&RFC4271;
&RFC5925;
&I-D.ietf-idr-error-handling;
</references>
<references title="Informative References">
&I-D.ietf-mpls-seamless-mpls;
&I-D.ietf-idr-custom-decision;
&I-D.ietf-idr-add-paths;
&I-D.keyupate-idr-i2rs-bgp-usecases;
&I-D.rosen-idr-tunnel-encaps;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:24:40 |