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. 

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 

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

[Zhuangshunwan]

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) .

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: Xiejingrong
Sent: Thursday, June 27, 2019 7:41 PM
To: Robert Raszuk 
Cc: Alexander Okonnikov ; softwi...@ietf.org; 
i...@ietf.org; bess@ietf.org; draft-dawra-bess-srv6-servi...@ietf.org
Subject: RE: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address 
coding for IPv4 VPN over IPv6 Core in RFC5549

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 
 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 
 section 3.2.

Thank you very much !
Jingrong

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Thursday, June 27, 2019 6:50 PM
To: Xiejingrong mailto:xiejingr...@huawei.com>>
Cc: Alexander Okonnikov 
mailto:alexander.okonni...@gmail.com>>; 
softwi...@ietf.org; 
i...@ietf.org; bess@ietf.org; 
draft-dawra-bess-srv6-servi...@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 

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

[Xiejingrong]

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 
 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 
 section 3.2.

Thank you very much !
Jingrong

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Thursday, June 27, 2019 6:50 PM
To: Xiejingrong 
Cc: Alexander Okonnikov ; softwi...@ietf.org; 
i...@ietf.org; bess@ietf.org; draft-dawra-bess-srv6-servi...@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 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!


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

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

[Xiejingrong]

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:martin.vigour...@nokia.com] 
Sent: Thursday, June 27, 2019 6:37 PM
To: Xiejingrong ; Alexander Okonnikov 
; Robert Raszuk ; 
bess@ietf.org
Cc: softwi...@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

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 :
> 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 
> *Cc:* UTTARO, JAMES ; Xiejingrong 
> ; 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 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!
> 
> 
> 
> 
> 
> ___
> 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

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

[Robert Raszuk]

> 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. 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 
> *Cc:* UTTARO, JAMES ; Xiejingrong ;
> 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 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!
>
>
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Vigoureux, Martin (Nokia - FR/Paris-Saclay)]

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 :
> 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 
> *Cc:* UTTARO, JAMES ; Xiejingrong 
> ; 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 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!
> 
> 
> 
> 
> 
> ___
> 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

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

[Xiejingrong]

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 
Cc: UTTARO, JAMES ; Xiejingrong ; 
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 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!



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

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

[Alexander Okonnikov]

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  написал(а):
> 
> 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 
> mailto: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 > > написал(а):
>> 
>> +1
>>  
>> From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
>> Robert Raszuk
>> Sent: Wednesday, June 26, 2019 7:53 AM
>> To: Xiejingrong mailto: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 > > 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 > >; ianfar...@gmx.com 
>> 
>> Cc: softwi...@ietf.org ; bess@ietf.org 
>> 
>> 

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

[Robert Raszuk]

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  написал(а):
>
> *+1*
>
> *From:* Idr  *On Behalf Of *Robert Raszuk
> *Sent:* Wednesday, June 26, 2019 7:53 AM
> *To:* Xiejingrong 
> *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 
> 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 ; 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
> 

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

[Robert Raszuk]

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

> *+1*
>
>
>
> *From:* Idr  *On Behalf Of * Robert Raszuk
> *Sent:* Wednesday, June 26, 2019 7:53 AM
> *To:* Xiejingrong 
> *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 
> 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 ; 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
> 
>
>
>
> Thanks,
>
> Ian
>
>
>
> *From: *Softwires  on behalf of Zhuangshunwan
> 
> *Date: *Tuesday, 25. June 2019 at 13:18
> *To: *"ianfar...@gmx.com" 
> *Cc: *"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 

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

[Alexander Okonnikov]

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  написал(а):
> 
> +1
>  
> From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
> Robert Raszuk
> Sent: Wednesday, June 26, 2019 7:53 AM
> To: Xiejingrong mailto: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  > 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  >; 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 
> 
>  
> Thanks,
> Ian
>  
> From: Softwires  > on behalf of Zhuangshunwan 
> mailto:zhuangshun...@huawei.com>>
> Date: Tuesday, 25. June 2019 at 13:18
> To: "ianfar...@gmx.com "  >
> Cc: 

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

[UTTARO, JAMES]

+1

From: Idr  On Behalf Of Robert Raszuk
Sent: Wednesday, June 26, 2019 7:53 AM
To: Xiejingrong 
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 
mailto: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 mailto: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

Thanks,
Ian

From: Softwires mailto:softwires-boun...@ietf.org>> 
on behalf of Zhuangshunwan 
mailto:zhuangshun...@huawei.com>>
Date: Tuesday, 25. June 2019 at 13:18
To: "ianfar...@gmx.com" 
mailto:ianfar...@gmx.com>>
Cc: "softwi...@ietf.org" 
mailto:softwi...@ietf.org>>, 
"bess@ietf.org" mailto: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