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

[stephane.litkowski]

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:rob...@raszuk.net]
Sent: Friday, June 28, 2019 11:11
To: LITKOWSKI Stephane OBS/OINIS
Cc: Xiejingrong; softwi...@ietf.org; draft-dawra-bess-srv6-servi...@ietf.org; 
bess@ietf.org; i...@ietf.org
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 
mailto:stephane.litkow...@orange.com>> wrote:
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]: 1
  Extended Community (16), length: 8, Flags [OT]:
target (0x0002), Flags [none]: 1:00200 (= 59.153.68.40)

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

Brgds,



From: Idr [mailto:idr-boun...@ietf.org] On Behalf 
Of Robert Raszuk
Sent: Thursday, June 27, 2019 12:50
To: Xiejingrong
Cc: softwi...@ietf.org; 
draft-dawra-bess-srv6-servi...@ietf.org;
 bess@ietf.org; i...@ietf.org
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address 
coding for IPv4 VPN over IPv6 Core in RFC5549

> 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,

> maybe the WG would like to reach a conclusion on how to treat that erratum:
> 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 
mailto:xiejingr...@huawei..com>> wrote:
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 

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

[Robert Raszuk]

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  wrote:

> 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]: 1
>
>   Extended Community (16), length: 8, Flags [OT]:
>
> target (0x0002), Flags [none]: 1:00200 (= 59.153.68.40)
>
>
>
> Note that this behavior caused some interop issues with another vendor who
> partially supported RFC4659.
>
>
>
> Brgds,
>
>
>
>
>
>
>
> *From:* Idr [mailto:idr-boun...@ietf.org] *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, June 27, 2019 12:50
> *To:* Xiejingrong
> *Cc:* softwi...@ietf.org; draft-dawra-bess-srv6-servi...@ietf.org;
> bess@ietf.org; i...@ietf.org
> *Subject:* Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network
> Address coding for IPv4 VPN over IPv6 Core in RFC5549
>
>
>
> > 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,
>
>
>
> > maybe the WG would like to reach a conclusion on how to treat that
> erratum:
>
> > 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  > wrote:
>
> 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.
>
>
>
>  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  to add
> the above text, and update RFC4364/4659/4760/5549, to eliminate the worries
> about interoperation. 

[bess] Discussion on various NH encoding

[stephane.litkowski]

Hi WG,

(Speaking as co-chair)

The current discussion on the NH encodings in our AFI/SAFIs requires some 
particular attention.
We would like to take the opportunity of the next IETF to discuss the subject 
face to face.

In the meantime, we are looking for few volunteers who will:

-  Do an inventory of what do we have in our specifications: which 
AFI/SAFI, which NH encoding rules

-  Identify inconsistencies (if any) or assess if it hurts or not 
(theoretically)

-  What is implemented or is there some known implementation issues

-  Present and drive the discussion at next IETF

Based on this, we will see if there is something to do or not.
Timing is short before next IETF, however the more material we have, the better 
the discussion will be.

Who wants to help on this ?


Brgds,

Stephane & Matthew


_

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.

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[stephane.litkowski]

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 
 carried in the attribute.”

Brgds,

Stephane

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Rajiv Asati (rajiva)
Sent: Thursday, June 27, 2019 13:37
To: Robert Raszuk
Cc: i...@ietf.org; Xiejingrong; Alexander Okonnikov; softwi...@ietf.org; 
bess@ietf.org; draft-dawra-bess-srv6-servi...@ietf.org
Subject: Re: [bess] [Softwires] [Idr] Regarding the Next Hop Network Address 
coding for IPv4 VPN over IPv6 Core in RFC5549


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


On Jun 27, 2019, at 6:50 AM, Robert Raszuk 
mailto:rob...@raszuk.net>> 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.

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,

> maybe the WG would like to reach a conclusion on how to treat that erratum:
> 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 
mailto:xiejingr...@huawei..com>> wrote:
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.

 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  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:alexander.okonni...@gmail.com]
Sent: Wednesday, June 26, 2019 9:38 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: UTTARO, JAMES mailto:ju1...@att.com>>; Xiejingrong 
mailto:xiejingr...@huawei.com>>; 

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

[stephane.litkowski]

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]: 1
  Extended Community (16), length: 8, Flags [OT]:
target (0x0002), Flags [none]: 1:00200 (= 59.153.68.40)

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

Brgds,



From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, June 27, 2019 12:50
To: Xiejingrong
Cc: softwi...@ietf.org; draft-dawra-bess-srv6-servi...@ietf.org; bess@ietf.org; 
i...@ietf.org
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address 
coding for IPv4 VPN over IPv6 Core in RFC5549

> 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,

> maybe the WG would like to reach a conclusion on how to treat that erratum:
> 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 
mailto:xiejingr...@huawei..com>> wrote:
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.

 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  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:alexander.okonni...@gmail.com]
Sent: Wednesday, June 26, 2019 9:38 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: UTTARO, JAMES mailto:ju1...@att.com>>; Xiejingrong 
mailto:xiejingr...@huawei.com>>; 
softwi...@ietf.org; 
i...@ietf.org; 
ian.far...@telekom.de; 
bess@ietf.org; ianfar...@gmx.com
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address 
coding for IPv4 VPN over IPv6 Core in RFC5549

Hi Robert,

Sorry, I was not