Hi Robert, Sorry, I was not so precise :-) Of course, RD part in Next Hop is not copied from RD of NLRI, but zeroed. I was trying to explain why Next Hop field in RFC 4364 and RFC 4659 has format RD:IP (VPNvX address) rather than just IP.
Thank you! > 26 июня 2019 г., в 16:27, Robert Raszuk <[email protected]> написал(а): > > 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 > <[email protected] <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> написал(а): >> >> +1 >> >> From: Idr <[email protected] <mailto:[email protected]>> On Behalf Of >> Robert Raszuk >> Sent: Wednesday, June 26, 2019 7:53 AM >> To: Xiejingrong <[email protected] <mailto:[email protected]>> >> Cc: [email protected] <mailto:[email protected]>; [email protected] >> <mailto:[email protected]>; [email protected] >> <mailto:[email protected]>; [email protected] <mailto:[email protected]>; >> [email protected] <mailto:[email protected]> >> 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 <[email protected] >> <mailto:[email protected]>> 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:[email protected] >> <mailto:[email protected]>] On Behalf Of [email protected] >> <mailto:[email protected]> >> Sent: Tuesday, June 25, 2019 11:12 PM >> To: Zhuangshunwan <[email protected] >> <mailto:[email protected]>>; [email protected] >> <mailto:[email protected]> >> Cc: [email protected] <mailto:[email protected]>; [email protected] >> <mailto:[email protected]> >> 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 <[email protected] >> <mailto:[email protected]>> on behalf of Zhuangshunwan >> <[email protected] <mailto:[email protected]>> >> Date: Tuesday, 25. June 2019 at 13:18 >> To: "[email protected] <mailto:[email protected]>" <[email protected] >> <mailto:[email protected]>> >> Cc: "[email protected] <mailto:[email protected]>" <[email protected] >> <mailto:[email protected]>>, "[email protected] <mailto:[email protected]>" >> <[email protected] <mailto:[email protected]>> >> 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: [email protected] <mailto:[email protected]> [mailto:[email protected] >> <mailto:[email protected]>] >> Sent: Monday, June 24, 2019 8:08 PM >> To: Zhuangshunwan <[email protected] >> <mailto:[email protected]>> >> Cc: [email protected] <mailto:[email protected]>; [email protected] >> <mailto:[email protected]> >> 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 <[email protected] >> <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> 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 >> [email protected] <mailto:[email protected]> >> 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 >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/idr >> <https://www.ietf.org/mailman/listinfo/idr>
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
