Re: [Softwires] [Idr] [bess] 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 ; softwires@ietf.org; 
i...@ietf.org; b...@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>>; 
softwires@ietf.org; 
i...@ietf.org; b...@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: [Softwires] [Idr] [bess] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

[Zhuangshunwan]

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:softwires-boun...@ietf.org] On Behalf Of Vigoureux, 
Martin (Nokia - FR/Paris-Saclay)
Sent: Thursday, June 27, 2019 6:37 PM
To: Xiejingrong ; Alexander Okonnikov 
; Robert Raszuk ; 
b...@ietf.org
Cc: softwires@ietf.org; i...@ietf.org
Subject: Re: [Softwires] [Idr] [bess] 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 
> ; softwires@ietf.org; i...@ietf.org; 
> ian.far...@telekom.de; b...@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
> 
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

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

[Zhuangshunwan]

Hi Ian,

Thanks for your response!

The opinion I have collected is:
Per RFC4634, the IPv4-VPN routes shall carry the V4 Next-hop, beginning with an 
8-octet RD and ending with a 4-octet IPv4 address.
Per RFC4659, the IPv6-VPN routes shall carry the V6 Next-hop, beginning with an 
8-octet RD and ending with a 16-octet IPv6 address.
When we start to implement the IPv4 VPN over IPv6 Core,  it is a natural way to 
encode the IPv4-VPN routes with VPN-IPv6 next-hop (i.e. beginning with an 
8-octet RD and ending with a 16-octet IPv6 address) .

I believe this is not just a minority opinion, and some of the current 
implementations are also doing this way.

I hope that the WGs can give a consistent opinion on this issue and avoid 
interoperability problem in the future.

Thanks,
Shunwan

From: ianfar...@gmx.com [mailto:ianfar...@gmx.com]
Sent: Monday, June 24, 2019 8:08 PM
To: Zhuangshunwan 
Cc: b...@ietf.org; softwires@ietf.org
Subject: Re: [Softwires] Regarding the Next Hop Network Address coding for IPv4 
VPN over IPv6 Core in RFC5549

Hi,

My reading of Section 3 of RFC5549 is that the v6 next-hop is encoded as an 
IPv6 address:

   The BGP speaker receiving the advertisement MUST use the Length of
   Next Hop Address field to determine which network-layer protocol the
   next hop address belongs to.  When the Length of Next Hop Address
   field is equal to 16 or 32, the next hop address is of type IPv6.

It’s also worth noting that RFC4659 Section 2 states:

A VPN-IPv6 address is a 24-octet quantity, beginning with an 8-octet
   "Route Distinguisher" (RD) and ending with a 16-octet IPv6 address.

So, not 16 or 32 bytes.

Thanks,
Ian



On 22. Jun 2019, at 09:59, Zhuangshunwan 
mailto:zhuangshun...@huawei.com>> wrote:

Dear authors and WGs,

RFC5549 Section 6.2 says:

. 6.2.  IPv4 VPN over IPv6 Core
.
.The extensions defined in this document may be used for support of
.IPV4 VPNs over an IPv6 backbone.  In this application, PE routers
.would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with an IPv6
.Next Hop.
.
.The MP_REACH_NLRI is encoded with:
.
.o  AFI = 1
.
.o  SAFI = 128
.
.o  Length of Next Hop Network Address = 16 (or 32)
.
.o  Network Address of Next Hop = IPv6 address of Next Hop
.
.o  NLRI = IPv4-VPN routes


Regarding IPv4-VPN routes, RFC4634 Section 4.3.2 says:

. 4.3.2.  Route Distribution Among PEs by BGP
[snip]
.When a PE router distributes a VPN-IPv4 route via BGP, it uses its
.own address as the "BGP next hop".  This address is encoded as a
.VPN-IPv4 address with an RD of 0.  ([BGP-MP] requires that the next
.hop address be in the same address family as the Network Layer
.Reachability Information (NLRI).)  It also assigns and distributes an
.MPLS label.  (Essentially, PE routers distribute not VPN-IPv4 routes,
.but Labeled VPN-IPv4 routes.  Cf. [MPLS-BGP].)  When the PE processes
.a received packet that has this label at the top of the stack, the PE
.will pop the stack, and process the packet appropriately.
[snip]


Question:
RFC5549 defines "IPv4 VPN over IPv6 Core", When a PE router distributes a 
VPN-IPv4 route with an IPv6 Next-Hop via BGP, should the IPv6 Next-Hop be 
encoded as an VPN-IPv6 address with an RD of 0 ?


Thanks,
Shunwan
___
Softwires mailing list
Softwires@ietf.org<mailto:Softwires@ietf.org>
https://www.ietf.org/mailman/listinfo/softwires

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

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

[Zhuangshunwan]

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
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires