Subject: Re: [Idr] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

From: Xiejingrong <[email-masked]>
Date: Wed, 26 Jun 2019 11:38:12 +0000

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-masked]] On Behalf Of [email-masked]
Sent: Tuesday, June 25, 2019 11:12 PM
To: Zhuangshunwan <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
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

Thanks,
Ian

From: Softwires <[email-masked]<mailto:[email-masked]>> on behalf of Zhuangshunwan <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 25. June 2019 at 13:18
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, June 24, 2019 8:08 PM
To: Zhuangshunwan <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Jun 2019 13:52:59 +0200

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-masked]> 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.
>
> 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).
>
> 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.
>
> *From:* Softwires [mailto:[email-masked]] *On Behalf Of *
> [email-masked]
> *Sent:* Tuesday, June 25, 2019 11:12 PM
> *To:* Zhuangshunwan <[email-masked]>; [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *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.
>
>
>
> 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.
>
> *From: *Softwires <[email-masked]> on behalf of Zhuangshunwan
> <[email-masked]>
> *Date: *Tuesday, 25. June 2019 at 13:18
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [Softwires] Regarding the Next Hop Network Address coding
> for IPv4 VPN over IPv6 Core in RFC5549
>
>
>
> Hi Ian,
>
>
>
> 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) .
>
>
>
> *From:* [email-masked] [mailto:[email-masked] <[email-masked]>]
> *Sent:* Monday, June 24, 2019 8:08 PM
> *To:* Zhuangshunwan <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [Softwires] Regarding the Next Hop Network Address coding
> for IPv4 VPN over IPv6 Core in RFC5549
>
>
>
> Hi,
>
>
>
> On 22. Jun 2019, at 09:59, Zhuangshunwan <[email-masked]> wrote:
>
>
>
> Dear authors and WGs,
>
>
>
> 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
>
> [email-masked]
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 26 Jun 2019 13:05:55 +0000

+1

From: Idr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Wednesday, June 26, 2019 7:53 AM
To: Xiejingrong <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
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-masked]<mailto:[email-masked]>> wrote:
Hi folks,

Thanks
Jingrong

From: Softwires [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, June 25, 2019 11:12 PM
To: Zhuangshunwan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

Hi Shunwan,

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

Hi Ian,

Thanks,
Shunwan

Hi,

So, not 16 or 32 bytes.

Thanks,
Ian

Dear authors and WGs,

Question:

Thanks,
Shunwan
_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]>
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=>

---

From: Alexander Okonnikov <[email-masked]>
Date: Wed, 26 Jun 2019 16:22:22 +0300

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-masked]> написал(а):
> 
> +1
>  
> From: Idr <[email-masked] <mailto:[email-masked]>> On Behalf Of Robert Raszuk
> To: Xiejingrong <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On Wed, Jun 26, 2019 at 1:40 PM Xiejingrong <[email-masked] <mailto:[email-masked]>> wrote:
> Hi folks,
>  
> From: Softwires [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of [email-masked] <mailto:[email-masked]>
> To: Zhuangshunwan <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> 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-masked] <mailto:[email-masked]>> on behalf of Zhuangshunwan <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Zhuangshunwan <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On 22. Jun 2019, at 09:59, Zhuangshunwan <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Dear authors and WGs,
>  
> [email-masked] <mailto:[email-masked]>
> 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=>
>  
> [email-masked] <mailto:[email-masked]>
> 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-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Jun 2019 15:22:36 +0200

And just to self complete the last sentence ...

The same leading zeros were also added to SAFI 128  in the next hop field
as to match the length of RD:IP prefix of the L3VPN NLRI. Original 2547 or
subsequent 4364 did not define explicitly that the size of the next hop
could be inferred from the nh length field - just took verbatim from 4760
that next hop is identified by AFI/SAFI of the NLRI itself .

But in general MP-BGP spec does not limit protocol designers. When you
define a new SAFI you are free to say that format of next hop will be
inferred from its length field or that next hop may not be present at all
as it does not make sense for a given SAFI (ref 5575) and that in turn will
be indicated by zero nh length

Many thx,
R.

On Wed, Jun 26, 2019 at 3:06 PM UTTARO, JAMES <[email-masked]> wrote:

> *+1*
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of * Robert Raszuk
> *Sent:* Wednesday, June 26, 2019 7:53 AM
> *To:* Xiejingrong <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network
> Address coding for IPv4 VPN over IPv6 Core in RFC5549
>
>
>
> All,
>
>
>
> <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
>
>
>
> <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=>
>
>
>
> <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=>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Jun 2019 15:27:18 +0200

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-masked]> 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.
>
> *From:* Idr <[email-masked]> *On Behalf Of *Robert Raszuk
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>
>

---

From: Alexander Okonnikov <[email-masked]>
Date: Wed, 26 Jun 2019 16:38:00 +0300

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-masked]> написал(а):
> 
> Hi Alex,
> 
> "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) 
> 
> 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-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
>> 26 июня 2019 г., в 16:05, UTTARO, JAMES <[email-masked] <mailto:[email-masked]>> написал(а):
>> 
>> +1
>>

---

From: Xiejingrong <[email-masked]>
Date: Thu, 27 Jun 2019 09:15:08 +0000

Thanks for the RFC historical lessons.
--there was historically some assumption that next hop must be of the same AF as prefix.
--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.
--authors of RFC 4364 were trying to make it consistent with 4760.
--Also, drafts of RFC 4364 and RFC 4760 were being developed practically at the same time period.

The problem is clear, the nexthop field has been inconsistent between different L3VPN/MVPN scenarios and different implementations in the long history.

<draft-dawra-bess-srv6-services-00> is the latest draft, but it has different nexthop in section 3.1 to 3.4, in the year 2019.

Back to my suggestion: implementation should interpret nexthop RD+IPv4 and nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the same.

I think it may be helpful for <draft-dawra-bess-srv6-services-00> to add the above text, and update RFC4364/4659/4760/5549, to eliminate the worries about interoperation. ----is there any worries about interoperation ?

Thanks
Jingrong

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Wednesday, June 26, 2019 9:38 PM
To: Robert Raszuk <[email-masked]>
Cc: UTTARO, JAMES <[email-masked]>; Xiejingrong <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

Hi Robert,

Thank you!

---

From: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Thu, 27 Jun 2019 10:36:45 +0000

since we are discussing that topic,

maybe the WG would like to reach a conclusion on how to treat that erratum:
http://www.rfc-editor.org/errata/eid5738

Thanks
-m

Le 2019-06-27 à 11:15, Xiejingrong a écrit :
> --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.
> 
> The problem is clear, the nexthop field has been inconsistent between 
> different L3VPN/MVPN scenarios and different implementations in the long 
> history.
> 
> <draft-dawra-bess-srv6-services-00> is the latest draft, but it has 
> different nexthop in section 3.1 to 3.4, in the year 2019.
> 
> Back to my suggestion: implementation should interpret nexthop RD+IPv4 
> and nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop 
> IPv6 the same.
> 
> I think it may be helpful for <draft-dawra-bess-srv6-services-00> to add 
> the above text, and update RFC4364/4659/4760/5549, to eliminate the 
> worries about interoperation. ----is there any worries about 
> interoperation ?
> 
> Thanks
> 
> Jingrong
> 
> *From:*Alexander Okonnikov [mailto:[email-masked]]
> *Sent:* Wednesday, June 26, 2019 9:38 PM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* UTTARO, JAMES <[email-masked]>; Xiejingrong 
> <[email-masked]>; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> 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!
> 
> 
> 
> 
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 27 Jun 2019 12:49:36 +0200

> Back to my suggestion: implementation should interpret nexthop RD+IPv4
and nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6
the same.

When elements of BGP UPDATE message are being parsed code must know what to
expect. Note that we are dealing here with deployed SAFI 128 for nearly 20
years.

So today there are two ways to know what format of next hop is in MP_REACH:

a) Inferring it from AFI/SAFI per section 3 of RFC4760

or (in addition to the above coarse assumption)

b) Inferring it from the discrete value of next hop length field as defined
in section 3 of RFC5549

Note that if we would be defining new SAFI we can write anything we like to
the rules of constructing the update message. But here again we are dealing
with something which is deployed so sort of operating on the plane in
flight.

If implementation can infer next hop type from length we are safe to define
all sections to have next hop length = 16 octets and be done. But if there
are some implementations which would only take AFI/SAFI to check if the
next hop is correct or even further to check if the next hop length is
correct then we have a problem.

/* Btw this notion of next hop length = 32 is bizarre ! I have never seen
any BGP implementation sending two next hops (global IPv6 address followed
by link local IPv6 address) not I am able to find any docs describing how
any BGP stack would handle it. IMHO we should move this 32 next hop length
to historic asap. */

To the msg from Martin,

> http://www.rfc-editor.org/errata/eid5738

I would vote to reject the errata. There is no value of stuffing 8 octet of
zeros in the next hop field. If the RFC got defined in 2012 that really
means that most implementations are capable of inferring next hop format
from the length field - which is very good. Accepting the errata would be a
step backwords.

Thx,
R.

On Thu, Jun 27, 2019 at 11:15 AM Xiejingrong <[email-masked]> wrote:

> Back to my suggestion: implementation should interpret nexthop RD+IPv4 and
> nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the
> same.
>
>
>
> the above text, and update RFC4364/4659/4760/5549, to eliminate the worries
> about interoperation. ----is there any worries about interoperation ?
>
>
>
> Thanks
>
> Jingrong
>
>
>
>
>
> *From:* Alexander Okonnikov [mailto:[email-masked]]
> *Cc:* UTTARO, JAMES <[email-masked]>; Xiejingrong <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> field in RFC 4364 and RFC 4659 has format RD:IP (VPNvX address) rather than
> just IP.
>
>
>
> Thank you!
>
>
>
>
>

---

From: Xiejingrong <[email-masked]>
Date: Thu, 27 Jun 2019 11:22:25 +0000

Please reject this erratum. 
RFC6515 is mandatory to require 4/16 bytes nexthop, and mandatory to reject 12/24 bytes nexthop. 

Thanks.
Jingrong.

-----Original Message-----
From: Vigoureux, Martin (Nokia - FR/Paris-Saclay) [mailto:[email-masked]] 
Sent: Thursday, June 27, 2019 6:37 PM
To: Xiejingrong <[email-masked]>; Alexander Okonnikov <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

Thanks
-m

Le 2019-06-27 à 11:15, Xiejingrong a écrit :
> --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.
> 
> different L3VPN/MVPN scenarios and different implementations in the 
> long history.
> 
> I think it may be helpful for <draft-dawra-bess-srv6-services-00> to 
> add the above text, and update RFC4364/4659/4760/5549, to eliminate 
> the worries about interoperation. ----is there any worries about 
> interoperation ?
> 
> Thanks
> 
> Jingrong
> 
> 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!
> 
> 
> 
> 
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 27 Jun 2019 11:37:04 +0000

I agree and sometimes flexibility becomes an unwanted necessity (as is the case here with option (a)).

IMO, option (b) length based check for NH should be preferred, since it works for all AFI/SAFIs with an assumption that NH could be one IPv4 or IPv6 prefix. Very reasonable option.

Option (a) AFI/SAFI based interpretation doesn’t work for all AFI/SAFIs that don’t distribute non-routing information  e.g. policy, capabilities, LS etc.

Cheers,
Rajiv

> Back to my suggestion: implementation should interpret nexthop RD+IPv4 and nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the same.

When elements of BGP UPDATE message are being parsed code must know what to expect. Note that we are dealing here with deployed SAFI 128 for nearly 20 years.

b) Inferring it from the discrete value of next hop length field as defined in section 3 of RFC5549

Note that if we would be defining new SAFI we can write anything we like to the rules of constructing the update message. But here again we are dealing with something which is deployed so sort of operating on the plane in flight.

If implementation can infer next hop type from length we are safe to define all sections to have next hop length = 16 octets and be done. But if there are some implementations which would only take AFI/SAFI to check if the next hop is correct or even further to check if the next hop length is correct then we have a problem.

/* Btw this notion of next hop length = 32 is bizarre ! I have never seen any BGP implementation sending two next hops (global IPv6 address followed by link local IPv6 address) not I am able to find any docs describing how any BGP stack would handle it. IMHO we should move this 32 next hop length to historic asap. */

To the msg from Martin,

> http://www.rfc-editor.org/errata/eid5738

I would vote to reject the errata. There is no value of stuffing 8 octet of zeros in the next hop field. If the RFC got defined in 2012 that really means that most implementations are capable of inferring next hop format from the length field - which is very good. Accepting the errata would be a step backwords.

Thx,
R.

On Thu, Jun 27, 2019 at 11:15 AM Xiejingrong <[email-masked]<mailto:xiejingrong@huawei..com>> wrote:

Thanks
Jingrong

From: Alexander Okonnikov [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, June 26, 2019 9:38 PM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: UTTARO, JAMES <[email-masked]<mailto:[email-masked]>>; Xiejingrong <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

Hi Robert,

Thank you!

---

From: Zhuangshunwan <[email-masked]>
Date: Thu, 27 Jun 2019 11:39:21 +0000

Hi all,

Can the WG reach a conclusion on how to treat that erratum related to RFC5549:

https://www.rfc-editor.org/errata/eid5253

Thanks,
Shunwan

-----Original Message-----
From: Softwires [mailto:[email-masked]] On Behalf Of Vigoureux, Martin (Nokia - FR/Paris-Saclay)
Sent: Thursday, June 27, 2019 6:37 PM
To: Xiejingrong <[email-masked]>; Alexander Okonnikov <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Softwires] [Idr] [bess] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

Thanks
-m

---

From: Xiejingrong <[email-masked]>
Date: Thu, 27 Jun 2019 11:41:10 +0000

Hi Robert:

I was convinced. All of your points:

(1)     No need to relax the check of nexthop as my previous suggestion.

(2)     No need to update 5549/6515, and the nexthops defined in <draft-dawra-bess-srv6-services-00> section 3.1 to 3.4 are all right to me now.

(3)     if we would be defining new SAFI we can write anything we like to the rules. Old SAFIs follow the RFCs already defind.

(4)     next hop length = 32 is bizarre, and so does length = 48 as in <draft-dawra-bess-srv6-services-00> section 3.2.

Thank you very much !
Jingrong

From: Robert Raszuk [mailto:[email-masked]]
Sent: Thursday, June 27, 2019 6:50 PM
To: Xiejingrong <[email-masked]>
Cc: Alexander Okonnikov <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

To the msg from Martin,

Thx,
R.

On Thu, Jun 27, 2019 at 11:15 AM Xiejingrong <[email-masked]<mailto:[email-masked]>> wrote:

Thanks
Jingrong

Hi Robert,

Thank you!

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 27 Jun 2019 13:52:18 +0200

My vote - Reject.

Justification:

Irrespective if we would reject or accept the erratum implementations must
be able to handle 10 years old RFC so must be able to properly recognize
the next hop to be either of length 16 or 24. (I am putting aside the 32/48
invention).

So that means that next hop length should be used to recognize format of
the next hop. That with the fact that stuffing next hop address with
useless 64 zeros in the front leads me to believe that if we are to produce
any erratums it should be the other way around ... we should replace all
documents which call for having next hops full of zeros in the front to
normalize it to consist of just real IPv4 or IPv6 single address.

Thx,
R.

On Thu, Jun 27, 2019 at 1:39 PM Zhuangshunwan <[email-masked]>
wrote:

> From: Softwires [mailto:[email-masked]] On Behalf Of
> Vigoureux, Martin (Nokia - FR/Paris-Saclay)
> To: Xiejingrong <[email-masked]>; Alexander Okonnikov <
> [email-masked]>; Robert Raszuk <[email-masked]>;
> [email-masked]
> Subject: Re: [Softwires] [Idr] [bess] Regarding the Next Hop Network

---

From: Zhuangshunwan <[email-masked]>
Date: Thu, 27 Jun 2019 11:53:41 +0000

Hi all,

For L3VPN features,  there are some differences:

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 (first sense) 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) .

From: Xiejingrong
Sent: Thursday, June 27, 2019 7:41 PM
To: Robert Raszuk <[email-masked]>
Cc: Alexander Okonnikov <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

Hi Robert:

Thank you very much !
Jingrong

From: Robert Raszuk [mailto:[email-masked]]
Sent: Thursday, June 27, 2019 6:50 PM
To: Xiejingrong <[email-masked]<mailto:[email-masked]>>
Cc: Alexander Okonnikov <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

To the msg from Martin,

Thx,
R.

Thanks
Jingrong

Hi Robert,

Thank you!

---

From: <[email-masked]>
Date: Thu, 27 Jun 2019 12:15:22 +0000

Hi,

(co-chair hat off)

I also vote to reject this erratum on the following grounds: The erratum text was raised as:

Section 6.2 says:
Length of Next Hop Network Address = 16 (or 32)
It should say:
Length of Next Hop Network Address = 24 (or 48)
Notes:
The lengths should include the RD length also, right ?

However, RFC5549 specifies in several places that the next-hop address is of type IPv6 address (Sections 3, 4, 6.1 and 6.2). The use of an IPv6 address as the next hop was clearly the intention of the author and the document was reviewed and published as such. The existing text in section 6.2 (Length of Next Hop Network Address = 16 (or 32)) is consistent with this and changing it as proposed in the would only introduce an inconsistency.

Thanks,
Ian

From: Softwires <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Thursday, 27. June 2019 at 13:53
To: Zhuangshunwan <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Alexander Okonnikov <[email-masked]>, "[email-masked]" <[email-masked]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Softwires] [bess] [Idr] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

My vote - Reject.

Justification:

Irrespective if we would reject or accept the erratum implementations must be able to handle 10 years old RFC so must be able to properly recognize the next hop to be either of length 16 or 24. (I am putting aside the 32/48 invention)..

So that means that next hop length should be used to recognize format of the next hop. That with the fact that stuffing next hop address with useless 64 zeros in the front leads me to believe that if we are to produce any erratums it should be the other way around ... we should replace all documents which call for having next hops full of zeros in the front to normalize it to consist of just real IPv4 or IPv6 single address.

Thx,
R.

On Thu, Jun 27, 2019 at 1:39 PM Zhuangshunwan <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Thanks,
Shunwan

-----Original Message-----
From: Softwires [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Vigoureux, Martin (Nokia - FR/Paris-Saclay)
Sent: Thursday, June 27, 2019 6:37 PM
To: Xiejingrong <[email-masked]<mailto:[email-masked]>>; Alexander Okonnikov <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Softwires] [Idr] [bess] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

Thanks
-m

Le 2019-06-27 à 11:15, Xiejingrong a écrit :
> *From:*Alexander Okonnikov [mailto:[email-masked]<mailto:[email-masked]>]
> *To:* Robert Raszuk <[email-masked]<mailto:[email-masked]>>
> *Cc:* UTTARO, JAMES <[email-masked]<mailto:[email-masked]>>; Xiejingrong
> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: <[email-masked]>
Date: Fri, 28 Jun 2019 07:48:21 +0000

Hi Robert,

There are implementations which set two NHs, here is a capture:

Update Message (2), length: 150
          Multi-Protocol Reach NLRI (14), length: 100, Flags [O]:
            AFI: IPv6 (2), SAFI: labeled VPN Unicast (128)
            nexthop: RD: 0:0 (= 0.0.0.0), 2000::162RD: 0:0 (= 0.0.0.0), fe80::2a94:fff:fefa:3cc0, nh-length: 48, no SNPA
              RD: 10283:803700200 (= 47.231.125.232), 2000:bebe:37::/56, label:1313 (bottom)
              RD: 10283:803700200 (= 47.231.125.232), 2000:bebe:37::1/128, label:1314 (bottom)
          Origin (1), length: 1, Flags [T]: IGP
          AS Path (2), length: 6, Flags [T]: 11111
          Extended Community (16), length: 8, Flags [OT]:
            target (0x0002), Flags [none]: 11111:999900200 (= 59.153.68.40)

Note that this behavior caused some interop issues with another vendor who partially supported RFC4659.

Brgds,

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, June 27, 2019 12:50
To: Xiejingrong
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

To the msg from Martin,

Thx,
R.

Thanks
Jingrong

Hi Robert,

Thank you!

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Fri, 28 Jun 2019 08:29:41 +0000

Hi Rajiv,

IMO, I don’t think that “Inferring it from AFI/SAFI per section 3 of RFC4760” means that there is a format match between the NH field and NLRI, it just says that there is a relation between the AFI/SAFI and the protocol layer of the NH.
When you know the AFI/SAFI, you can deduce the NH encoding based on the NH encoding rules defines for this particular AFI/SAFI. RFC4760 doesn’t say that there is an exact match between NLRI format and NH format.

“The Network Layer protocol associated with the Network Address of
         the Next Hop is identified by a combination of <AFI, SAFI>
         carried in the attribute.”

Brgds,

Stephane

From: BESS [mailto:[email-masked]] On Behalf Of Rajiv Asati (rajiva)
Sent: Thursday, June 27, 2019 13:37
To: Robert Raszuk
Cc: [email-masked]; Xiejingrong; Alexander Okonnikov; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bess] [Softwires] [Idr] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

Cheers,
Rajiv

To the msg from Martin,

Thx,
R.

Thanks
Jingrong

Hi Robert,

Thank you!

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Jun 2019 11:11:18 +0200

Stephane,

Sure you can send two NHs next to each other. But my main question is what
should the receiver of such "thing" do ? Which next hop is more important
to be actually used in forwarding ? Based on what elements such decision is
made ...

If you know some history and can share it here iI think it may be useful
for others.

Btw which implementation sends two :) ? Should not be a big secret I
suppose.

Thx,
R.

On Fri, Jun 28, 2019 at 9:48 AM <[email-masked]> wrote:

>             nexthop: RD: 0:0 (= 0.0.0.0), 2000::162RD: 0:0 (= 0.0.0.0),
> fe80::2a94:fff:fefa:3cc0, nh-length: 48, no SNPA
>
> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, June 27, 2019 12:50
> *To:* Xiejingrong
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> When elements of BGP UPDATE message are being parsed code must know what
> to expect. Note that we are dealing here with deployed SAFI 128 for nearly
> 20 years.
>
>
>
> Note that if we would be defining new SAFI we can write anything we like
> to the rules of constructing the update message. But here again we are
> dealing with something which is deployed so sort of operating on the plane
> in flight.
>
>
>
> If implementation can infer next hop type from length we are safe to
> define all sections to have next hop length = 16 octets and be done. But if
> there are some implementations which would only take AFI/SAFI to check if
> the next hop is correct or even further to check if the next hop length is
> I would vote to reject the errata. There is no value of stuffing 8 octet
> of zeros in the next hop field. If the RFC got defined in 2012 that really
> On Thu, Jun 27, 2019 at 11:15 AM Xiejingrong <[email-masked]
> <xiejingrong@huawei..com>> wrote:
>

---

From: <[email-masked]>
Date: Fri, 28 Jun 2019 14:25:39 +0000

Unfortunately I don’t have the history, we discovered this behavior when doing some VPNv6 testings a couple of months ago between IOS and Junos. IOS XE does advertise two nexthops.

From: Robert Raszuk [mailto:[email-masked]]
Sent: Friday, June 28, 2019 11:11
To: LITKOWSKI Stephane OBS/OINIS
Cc: Xiejingrong; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

Stephane,

Sure you can send two NHs next to each other. But my main question is what should the receiver of such "thing" do ? Which next hop is more important to be actually used in forwarding ? Based on what elements such decision is made ...

If you know some history and can share it here iI think it may be useful for others.

Btw which implementation sends two :) ? Should not be a big secret I suppose.

Thx,
R.

On Fri, Jun 28, 2019 at 9:48 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Brgds,

From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Thursday, June 27, 2019 12:50
To: Xiejingrong
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

To the msg from Martin,

Thx,
R.

Thanks
Jingrong

Hi Robert,

Thank you!

Thank you.