[bess] Comments on

[Xiejingrong]

Hi
I have read this documents several times.
I think it is useful and stable to advance as a solution of L3VPN/EVPN service 
over IPv6 networks.
Here are some minor comments:

   SRv6 Service SID refers to an SRv6 SID that MAY be associated with
   one of the service specific behavior on the advertising Provider
   Edge(PE) router, such as (but not limited to), in the case of L3VPN
   service, END.DT (Table lookup in a VRF) or END.DX (crossconnect to a
   nexthop) functions
[xjr] what are the things "but not limited to" ? Please specify explicitly or 
delete the words in this paragraph and other places.

   To provide SRv6 service with best-effort connectivity, the egress PE
   signals an SRv6 Service SID with the BGP overlay service route.  The
   ingress PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID provided by the egress
   PE.  The underlay between the PEs only need to support plain IPv6
   forwarding [RFC2460].
[xjr]"with best-effort connectivity" is not clear to me.
[xjr] I suggest a section can be added to say about "not using color and SRH", 
"using color and SRH" for easy-deployment and for path-optimization 
respectively.
[xjr] s/RFC2460/RFC8200/g

   To provide SRv6 service in conjunction with an underlay SLA from the
   ingress PE to the egress PE, the egress PE colors the overlay service
   route with a Color extended
   community[I-D.ietf-idr-segment-routing-te-policy].  The ingress PE
   encapsulates the payload packet in an outer IPv6 header with an SRH
   that contains the SR policy associated with the related SLA followed
   by the SRv6 Service SID associated with the route.  The underlay
   nodes whose SRv6 SID's are part of the SRH must support SRv6 data
   plane.
[xjr] see above suggestion.

SRv6 Service Sub-TLV Type (1 octet): This field is set to 1 to
  represent SRv6 SID Informaton Sub-TLV.
[xjr] s/Informaton/information/g

   Egress PEs which supports SRv6 based L3 services advertises overlay
   service prefixes along with a Service SID enclosed in a SRv6 L3
   Service TLV within the BGP SID attribute.  This TLV serves two
   purposes - first, it indicates that the egress PE is reachable via an
   SRv6 underlay and the BGP ingress PE receiving this route MAY choose
   to encapsulate or insert an SRv6 SRH; second ,it indicates the value
   of the SID to include in the SRH encapsulation.
[xjr] The two purposes I can see, the indication of the reachability to this 
PE, and the indication of a specific Service this SRv6 SID bound to.
[xjr] Use of SRH or not is determined by Color Extended Community, or more 
precisely, the SR-policy installed on Ingress Node, not this TLV.

4.6.  EVPN multicast routes (Route Types 6, 7, 8) over SRv6 core
   These routes do not require the advertisement of SRv6 Service TLVs
   along with them.  Similar to EVPN Route Type 4, the BGP Nexthop is
   equal to the IPv6 address of egress PE.  More details may be added in
   future revisions of this document.
[xjr] is this determined that No SRv6 Service TLVs required ? the document 
 had seen the use of SRv6 Service TLV in multicast 
VPN.
[xjr] Suggest to say simply this is outside of this document, which I think 
covers unicast service only, and helpful to advance.

Thanks
Jingrong

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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-igmp-mld-proxy

[Anuj Budhiraja (abudhira)]

Support.

Thanks,
Anuj Budhiraja

From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Monday, June 17, 2019 at 1:56 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-igmp-mld-proxy


Hello Working Group,



This email starts a three weeks Working Group Last Call on  
draft-ietf-bess-evpn-igmp-mld-proxy [1].



This poll runs until *the 28th of June*.



We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this Document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.



We have several IPRs already disclosed.



If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.



We are also polling for any existing implementation as per [2].



Thank you,

Stephane & Matthew


[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy/

[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw



[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



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] MPLS Label value 3 in

[Xiejingrong]

s/6556/8556/g

7432 section 8.2.1
The MPLS label in the NLRI MUST be set to 0.

8556 section 3
The MPLS label field SHOULD be set to zero.
From:Xiejingrong 
To:draft-dawra-bess-srv6-servi...@ietf.org 
;bess@ietf.org 
Date:2019-06-27 19:57:30
Subject:[bess] MPLS Label value 3 in

Hi folks,

One question about MPLS Label value 3 used in 
:

the Label value in any service route NLRI encoding MUST be set to Implicit NULL 
[RFC3032].

Label = Implicit NULL

I think the more common use of MPLS Label to represent “invalid” is to use 
zero, as in RFC7432 and RFC6556.

Why this document use value 3 (Implicit NULL as defined in RFC3032) ?

Thanks
Jingrong

___
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

[ian.farrer]

Hi,

(co-chair hat off)

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

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

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

Thanks,
Ian

From: Softwires  on behalf of Robert Raszuk 

Date: Thursday, 27. June 2019 at 13:53
To: Zhuangshunwan 
Cc: "i...@ietf.org" , Alexander Okonnikov 
, "softwi...@ietf.org" , 
"Vigoureux, Martin (Nokia - FR/Paris-Saclay)" , 
"bess@ietf.org" 
Subject: Re: [Softwires] [bess] [Idr] Regarding the Next Hop Network Address 
coding for IPv4 VPN over IPv6 Core in RFC5549


My vote - Reject.

Justification:

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

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

Thx,
R.

On Thu, Jun 27, 2019 at 1:39 PM Zhuangshunwan 
mailto:zhuangshun...@huawei.com>> wrote:
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 mailto:xiejingr...@huawei.com>>; 
Alexander Okonnikov 
mailto:alexander.okonni...@gmail.com>>; Robert 
Raszuk mailto:rob...@raszuk.net>>; 
bess@ietf.org
Cc: softwi...@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 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] MPLS Label value 3 in

[Xiejingrong]

Hi folks,

One question about MPLS Label value 3 used in 
:

the Label value in any service route NLRI encoding MUST be set to Implicit NULL 
[RFC3032].

Label = Implicit NULL

I think the more common use of MPLS Label to represent "invalid" is to use 
zero, as in RFC7432 and RFC6556.

Why this document use value 3 (Implicit NULL as defined in RFC3032) ?

Thanks
Jingrong

___
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

[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] [Softwires] [Idr] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

[Robert Raszuk]

My vote - Reject.

Justification:

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

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

Thx,
R.

On Thu, Jun 27, 2019 at 1:39 PM Zhuangshunwan 
wrote:

> 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 <
> alexander.okonni...@gmail.com>; Robert Raszuk ;
> bess@ietf.org
> Cc: softwi...@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
> > ; 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
> >
> ___
> Softwires mailing list
> softwi...@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
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]

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