Hi Alex, > My understanding is follow: RD is encoded in Next Hop field
That is subtle misinterpretation of the 4364 :) The text says: "When a PE router distributes a VPN-IPv4 route via BGP, it uses its own address as the "BGP next hop". This address is encoded as a VPN-IPv4 address with an RD of 0." That can be read as: A) Next hop field has prepended zeros to match the NLRI format of 8 octet RD + 4 octet IPv4 (for IPv4 case) B) Next hop is of format RD:IPv4 where RD=0 My recollection and number of direct discussions with authors of both2547/4364 & 4760 at that time leads me to believe we are dealing with A. Of course anyone can see option B as valid, but at the end of the day it is the same on the wire :) So I am not sure what exactly the problem or the question we are trying to answer is :) Cheers, R. On Wed, Jun 26, 2019 at 3:22 PM Alexander Okonnikov < alexander.okonni...@gmail.com> wrote: > Hi, > > My understanding is follow: RD is encoded in Next Hop field, because > authors of RFC 4364, while referring to RFC 2858, were trying to make it > consistent with RFC 4760 (obsoletes RFC 2858). RFC 2858 says that Next Hop > field should match AFI. On the other hand, RFC 4760 says that Next Hop > Field should match combination of AFI/SAFI. Also, drafts of RFC 4364 and > RFC 4760 were being developed practically at the same time period. > > 26 июня 2019 г., в 16:05, UTTARO, JAMES <ju1...@att.com> написал(а): > > *+1* > > *From:* Idr <idr-boun...@ietf.org> *On Behalf Of *Robert Raszuk > *Sent:* Wednesday, June 26, 2019 7:53 AM > *To:* Xiejingrong <xiejingr...@huawei.com> > *Cc:* i...@ietf.org; ian.far...@telekom.de; ianfar...@gmx.com; > softwi...@ietf.org; bess@ietf.org > *Subject:* Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network > Address coding for IPv4 VPN over IPv6 Core in RFC5549 > > All, > > RD is a property of the NLRI not next hop. I am not sure where in this > thread or some spec someone came to the conclusion that next hop field > should contain an RD. RD is not useful there and should never be part of > any next hop field. > > Remember RD role is to make prefix unique - that's it - no more no less. > Next hop uniqness is given by architecture and there is no need to make it > unique. > > In some cases when we need to carry IPv4 address in IPv6 next hop field > (there was historically some assumption that next hop must be of the same > AF as prefix) we prepend to it numerical zeros. > > Thx, > R. > > > > > > On Wed, Jun 26, 2019 at 1:40 PM Xiejingrong <xiejingr...@huawei.com> > wrote: > > Hi folks, > > I guess this is an inconsistency due to past carelessness. Is there anyone > can tell us the history of this inconsistency ? > RFC4364(VPNv4 over IPv4 network) and RFC4659(VPNv6 over IPv4 or IPv6 > network) both require to use RD+IP(v4 or v6 respectively) as nexthop. > RFC5549(VPNv4/IPv4 over IPv6 network) requires to use IPv6 without RD as > nexthop. > This same question also occur in MVPN: RFC6515, which talks about MVPN6 > over IPv4/IPv6, or MVPN over IPv6, but does imply loosely to use IPv4/IPv6 > without RD as nexthop (see below). > The purpose of this document is to make clear that whenever a PE > address occurs in an MCAST-VPN route (whether in the NLRI or in an > attribute), the IP address family of that address is determined by > the length of the address (a length of 4 octets for IPv4 addresses, a > length of 16 octets for IPv6 addresses), NOT by the AFI field of the > route. > > My suggestion: implementation should interpret nexthop RD+IPv4 and nexthop > IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the same. > The RFC5549/SRv6-VPN/RFC6515 can keep as current shape, while interoperate > can meet between different implementations. > Need a new draft to clarify this and to give a guide on further FooService > over FooNetwork ? > > Thanks > Jingrong > > *From:* Softwires [mailto:softwires-boun...@ietf.org] *On Behalf Of * > ian.far...@telekom.de > *Sent:* Tuesday, June 25, 2019 11:12 PM > *To:* Zhuangshunwan <zhuangshun...@huawei.com>; ianfar...@gmx.com > *Cc:* softwi...@ietf.org; bess@ietf.org > *Subject:* Re: [Softwires] Regarding the Next Hop Network Address coding > for IPv4 VPN over IPv6 Core in RFC5549 > > Hi Shunwan, > > I’ve just re-checked RFC5539, and the referenced section 3 of RFC2545 and > I can find nothing about using VPN-IPv6 for encoding the next-hop. Section > 3 of RFC5539 is very clear that it’s a 16-byte GU IPv6 address or 32-bytes > with a GU and LL address. > > Can you point me to the text that gives you the impression that VPN-IPv6 > is correct? > > Note – I see that there is reported Errata on RFC5549, (not verified) > saying that the length should be 24 or 48 to include the RD. However, as > mentioned above, the supporting text in multiple places in the RFC and its > references support the use of an IPv6 address (or 2) with no RD at 16 or 32 > bytes, so this does seem to be the intention of the document as written. > https://www.rfc-editor.org/errata_search.php?rfc=5549 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_errata-5Fsearch.php-3Frfc-3D5549&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=UIVZS5gA4_SHRLCgtb5AnrGyg_Rit-E-t_ZsSB8Z5hQ&s=333xV6xato3JrUqR7cF_lNHZ6cCgzHqaeva-aNH6ORY&e=> > > Thanks, > Ian > > *From: *Softwires <softwires-boun...@ietf.org> on behalf of Zhuangshunwan > <zhuangshun...@huawei.com> > *Date: *Tuesday, 25. June 2019 at 13:18 > *To: *"ianfar...@gmx.com" <ianfar...@gmx.com> > *Cc: *"softwi...@ietf.org" <softwi...@ietf.org>, "bess@ietf.org" < > bess@ietf.org> > *Subject: *Re: [Softwires] Regarding the Next Hop Network Address coding > for IPv4 VPN over IPv6 Core in RFC5549 > > Hi Ian, > > Thanks for your response! > > The opinion I have collected is: > Per RFC4634, the IPv4-VPN routes shall carry the V4 Next-hop, beginning > with an 8-octet RD and ending with a 4-octet IPv4 address. > Per RFC4659, the IPv6-VPN routes shall carry the V6 Next-hop, beginning > with an 8-octet RD and ending with a 16-octet IPv6 address. > When we start to implement the IPv4 VPN over IPv6 Core, it is a natural > way to encode the IPv4-VPN routes with VPN-IPv6 next-hop (i.e. beginning > with an 8-octet RD and ending with a 16-octet IPv6 address) . > > I believe this is not just a minority opinion, and some of the current > implementations are also doing this way. > > I hope that the WGs can give a consistent opinion on this issue and avoid > interoperability problem in the future. > > Thanks, > Shunwan > > *From:* ianfar...@gmx.com [mailto:ianfar...@gmx.com <ianfar...@gmx.com>] > *Sent:* Monday, June 24, 2019 8:08 PM > *To:* Zhuangshunwan <zhuangshun...@huawei.com> > *Cc:* bess@ietf.org; softwi...@ietf.org > *Subject:* Re: [Softwires] Regarding the Next Hop Network Address coding > for IPv4 VPN over IPv6 Core in RFC5549 > > Hi, > > My reading of Section 3 of RFC5549 is that the v6 next-hop is encoded as > an IPv6 address: > > The BGP speaker receiving the advertisement MUST use the Length of > Next Hop Address field to determine which network-layer protocol the > next hop address belongs to. When the Length of Next Hop Address > field is equal to 16 or 32, the next hop address is of type IPv6. > > It’s also worth noting that RFC4659 Section 2 states: > > A VPN-IPv6 address is a 24-octet quantity, beginning with an 8-octet > "Route Distinguisher" (RD) and ending with a 16-octet IPv6 address. > > So, not 16 or 32 bytes. > > Thanks, > Ian > > > > > On 22. Jun 2019, at 09:59, Zhuangshunwan <zhuangshun...@huawei.com> wrote: > > Dear authors and WGs, > > RFC5549 Section 6.2 says: > > . 6.2. IPv4 VPN over IPv6 Core > . > . The extensions defined in this document may be used for support of > . IPV4 VPNs over an IPv6 backbone. In this application, PE routers > . would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with an IPv6 > . Next Hop. > . > . The MP_REACH_NLRI is encoded with: > . > . o AFI = 1 > . > . o SAFI = 128 > . > . o Length of Next Hop Network Address = 16 (or 32) > . > . o Network Address of Next Hop = IPv6 address of Next Hop > . > . o NLRI = IPv4-VPN routes > > > Regarding IPv4-VPN routes, RFC4634 Section 4.3.2 says: > > > . 4.3.2. Route Distribution Among PEs by BGP > [snip] > . When a PE router distributes a VPN-IPv4 route via BGP, it uses its > . own address as the "BGP next hop". This address is encoded as a > . VPN-IPv4 address with an RD of 0. ([BGP-MP] requires that the next > . hop address be in the same address family as the Network Layer > . Reachability Information (NLRI).) It also assigns and distributes an > . MPLS label. (Essentially, PE routers distribute not VPN-IPv4 routes, > . but Labeled VPN-IPv4 routes. Cf. [MPLS-BGP].) When the PE processes > . a received packet that has this label at the top of the stack, the PE > . will pop the stack, and process the packet appropriately. > [snip] > > > Question: > RFC5549 defines "IPv4 VPN over IPv6 Core", When a PE router distributes a > VPN-IPv4 route with an IPv6 Next-Hop via BGP, should the IPv6 Next-Hop be > encoded as an VPN-IPv6 address with an RD of 0 ? > > > Thanks, > Shunwan > _______________________________________________ > Softwires mailing list > softwi...@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_softwires&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=UIVZS5gA4_SHRLCgtb5AnrGyg_Rit-E-t_ZsSB8Z5hQ&s=-VhqM-U7CXqqrJK30vJoT0RsvjQI4Kbnek9L-JvjNs8&e=> > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=UIVZS5gA4_SHRLCgtb5AnrGyg_Rit-E-t_ZsSB8Z5hQ&s=JKi7zUQKOeE3U_Ii2m4n4NQcorfG6hvi8c7XZ1qywEs&e=> > > _______________________________________________ > Idr mailing list > i...@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
