Re: [bess] I-D Action: draft-ietf-bess-evpn-ipvpn-interworking-02.txt

[Rabadan, Jorge (Nokia - US/Mountain View)]

FYI

Based on some received feedback, we published a new version of this draft 
clarifying the use of the D-PATH attribute when more than 255 domains are 
needed.
Any comments are welcome.

Otherwise the document is ready for WG LC.

Thanks.
Jorge

-Original Message-
From: BESS  on behalf of "internet-dra...@ietf.org" 

Reply-To: "bess@ietf.org" 
Date: Friday, November 29, 2019 at 8:21 AM
To: "i-d-annou...@ietf.org" 
Cc: "bess@ietf.org" 
Subject: [bess] I-D Action: draft-ietf-bess-evpn-ipvpn-interworking-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : EVPN Interworking with IPVPN
Authors : Jorge Rabadan
  Ali Sajassi
Filename: draft-ietf-bess-evpn-ipvpn-interworking-02.txt
Pages   : 24
Date: 2019-11-28

Abstract:
   EVPN is used as a unified control plane for tenant network intra and
   inter-subnet forwarding. When a tenant network spans not only EVPN
   domains but also domains where IPVPN provides inter-subnet
   forwarding, there is a need to specify the interworking aspects
   between both EVPN and IPVPN domains, so that the end to end tenant
   connectivity can be accomplished. This document specifies how EVPN
   should interwork with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families
   for inter-subnet forwarding.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-ipvpn-interworking/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-ipvpn-interworking-02

https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-ipvpn-interworking-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-ipvpn-interworking-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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

[bess] I-D Action: draft-ietf-bess-evpn-ipvpn-interworking-02.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : EVPN Interworking with IPVPN
Authors : Jorge Rabadan
  Ali Sajassi
Filename: draft-ietf-bess-evpn-ipvpn-interworking-02.txt
Pages   : 24
Date: 2019-11-28

Abstract:
   EVPN is used as a unified control plane for tenant network intra and
   inter-subnet forwarding. When a tenant network spans not only EVPN
   domains but also domains where IPVPN provides inter-subnet
   forwarding, there is a need to specify the interworking aspects
   between both EVPN and IPVPN domains, so that the end to end tenant
   connectivity can be accomplished. This document specifies how EVPN
   should interwork with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families
   for inter-subnet forwarding.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-ipvpn-interworking/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-ipvpn-interworking-02
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-ipvpn-interworking-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-ipvpn-interworking-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Jakob Heitz (jheitz)]

I support adoption.

Regards,
Jakob.

From: BESS  On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Wednesday, November 27, 2019 4:37 AM
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures against this document.

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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG Adoption and IPR Poll fordraft-litkowski-bess-rfc5549revision-00

[zhang.zheng]

Support the adoption. This document does make sense.






Thanks,


Sandy









原始邮件



发件人：Bocci,Matthew(Nokia-GB) 
收件人：bess@ietf.org ;
抄送人：bess-cha...@ietf.org ;
日 期 ：2019年11月27日 20:37
主 题 ：[bess] WG Adoption and IPR Poll fordraft-litkowski-bess-rfc5549revision-00




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



Hello,


 


This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .


 


Please review the draft and post any comments to the BESS working group list.


 


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, copying the BESS mailing list. The document won't progress 
without
 answers from all the authors and contributors.


 


Currently, there are no IPR disclosures against this document.


 


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.


 


This poll for adoption closes on Wednesday 11th December 2019.  


 


Regards,


Matthew


 


[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Neeraj Malhotra]

Hi,

Support adoption.

Thanks,
Neeraj

> On Nov 27, 2019, at 4:36 AM, Bocci, Matthew (Nokia - GB) 
>  wrote:
> 
> Hello,
>  
> This email begins a two-weeks WG adoption poll for 
> draft-litkowski-bess-rfc5549revision-00 [1] .
>  
> Please review the draft and post any comments to the BESS working group list.
>  
> 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, copying the BESS mailing list. The document won't 
> progress without answers from all the authors and contributors.
>  
> Currently, there are no IPR disclosures against this document.
>  
> 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.
>  
> This poll for adoption closes on Wednesday 11th December 2019.  
>  
> Regards,
> Matthew
>  
> [1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/
>  
>  
>  
> ___
> 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] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Robert Raszuk]

Stephane,

Adding ability to recognize the length of the next hop to any code is
purely incremental thing. When vendors were asked I do not even recall if
there was a question if given implementation can infer next hop format from
length or not - and that is the key problem/point here.

Just asking if you are prepending zeros or not to NH in some SAFIs and
stating that if so you do revise 5549 to reflect that is not what we should
be doing.

The main reason is that as SAFIs are being defined every now and then and
there is still no clear document if next hop should match NLRI type or not.
Moreover 4364 is still being developed in few vendors. Sure they want to be
backwards compatible too, but with that let's also give them a chance to do
the right thing vs just follow legacy.

So yes if you are opening that box my suggestion is to define an additional
capability indicating if receiver can process next hop without any
additional nonsense zero padding. All it takes is one paragraph/section and
one IANA codepoint.

Stating that this should be new separate document again updating 5549 and
now 5549revised is really not the best option.

Best,
Robert

On Thu, Nov 28, 2019 at 5:40 PM  wrote:

> Hi Robert,
>
>
>
> Please see some replies inline.
>
>
>
> Brgds,
>
>
>
> *From:* Robert Raszuk 
> *Sent:* mercredi 27 novembre 2019 22:18
> *To:* Bocci, Matthew (Nokia - GB) 
> *Cc:* bess@ietf.org; bess-cha...@ietf.org
> *Subject:* Re: [bess] WG Adoption and IPR Poll for
> draft-litkowski-bess-rfc5549revision-00
>
>
>
> *I do not support this draft in the current form. *
>
>
>
> This document instead of improving the original specification makes it
> actually worse.
>
> [SLI]
>
>
>
> Point 1 -
>
>
>
> Original RFC sec. 6.2:
>
>
>o  Network Address of Next Hop = IPv6 address of Next Hop
>
>
>
> Proposed text:
>
>
>
>
>o  Network Address of Next Hop = VPN-IPv6 address of Next Hop whose
>
> RD is set to zero
>
>
>
>
>
> As it has been explained when you negotiate in capability AFI2 as next hop
> it is just 16 octets - not 24.
>
> [SLI] AFI2 means that the nexthop is encoded with a format compliant with
> an AFI2, but does not tell anything about the SAFI. A VPN-IPv6 address is
> still AFI2.
>
>
>
> Next hop never has an RD.
>
> [SLI] We have already discussed about that. RD doesn’t make any sense for
> a nexthop address. No one disagrees on that point. However our legacy
> 2547bis introduced a nexthop encoded as a VPN-IP address, and all VPN
> unicast SAFIs are following this. As RD does not make sense, zeroes are
> just added to fit the size of the address format. In reality, it is just an
> IP address with 0es padded before. Of course,  it would have been cleaner
> to use only a regular IP address instead of a VPN-IP address but again
> that’s our legacy.
>
>
>
> The fact that some implementations are matching length of NLRI with length
> of next hop no where should be made equal that next hop has 8 octet dummy
> Route Distinguisher.
>
> [SLI] Again this is coming from legacy.
>
>
>
>
>
> If revision is to be made would be to explicitly negotiate capability to
> infer next hop encoding from the length.
>
> [SLI] Are you talking about a new capability or the existing ENH cap ? ENH
> tells you what is the NH AFI, so the only length check required is for the
> case of one or two IPv6 addresses. A new cap means a new solution, and
> that’s not the goal here.
>
>
>
>
>
> Point 2 -
>
>
>
> Addition of section 6.3 and SAFI 129 is fine, but again next hop encoding
> is lightly stating suboptimal.
>
>
>
> Conclusion:
>
>
>
> As we have discussed on and off line if revision is to be made let's make
> it both backwards compatible, Let's make it applicable to both IPv4 and
> IPv6 next hop addresses and let's allow explicit capability where
> implementations could indicate that it can recognize next hop value from
> its length. After all we are talking about just 4 discrete possible values
> here.
>
> [SLI] The goal is not to create something new here, but just to reflect
> how RFC5549 has been implemented for the SAFI 128/129 cases. The goal is
> also to minimize running code changes too (and even avoid !). We have to
> deal with what has been shipped and deployed by vendors today. We can still
> create something completely new, with a new cap and new procedures, but I
> think this is orthogonal to “aligning RFC5549 with implementations” as
> RFC5549 is there anyway and we can’t blindly forget it due to the codes
> that are available.
>
>
>
>
>
>
>
> Cheers,
>
> Robert.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Nov 27, 2019 at 1:36 PM Bocci, Matthew (Nokia - GB) <
> matthew.bo...@nokia.com> wrote:
>
> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-litkowski-bess-rfc5549revision-00 [1] .
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has 

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[slitkows.ietf]

Hi Robert,

 

Please see some replies inline.

 

Brgds,

 

From: Robert Raszuk  
Sent: mercredi 27 novembre 2019 22:18
To: Bocci, Matthew (Nokia - GB) 
Cc: bess@ietf.org; bess-cha...@ietf.org
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

 

I do not support this draft in the current form. 

 

This document instead of improving the original specification makes it actually 
worse. 

[SLI]

 

Point 1 - 

 

Original RFC sec. 6.2:   



   o  Network Address of Next Hop = IPv6 address of Next Hop

 

Proposed text:

 





   o  Network Address of Next Hop = VPN-IPv6 address of Next Hop whose


RD is set to zero



 



 

As it has been explained when you negotiate in capability AFI2 as next hop it 
is just 16 octets - not 24. 

[SLI] AFI2 means that the nexthop is encoded with a format compliant with an 
AFI2, but does not tell anything about the SAFI. A VPN-IPv6 address is still 
AFI2.

 

Next hop never has an RD. 

[SLI] We have already discussed about that. RD doesn’t make any sense for a 
nexthop address. No one disagrees on that point. However our legacy 2547bis 
introduced a nexthop encoded as a VPN-IP address, and all VPN unicast SAFIs are 
following this. As RD does not make sense, zeroes are just added to fit the 
size of the address format. In reality, it is just an IP address with 0es 
padded before. Of course,  it would have been cleaner to use only a regular IP 
address instead of a VPN-IP address but again that’s our legacy. 

 

The fact that some implementations are matching length of NLRI with length of 
next hop no where should be made equal that next hop has 8 octet dummy Route 
Distinguisher. 

[SLI] Again this is coming from legacy. 

 

 

If revision is to be made would be to explicitly negotiate capability to infer 
next hop encoding from the length. 

[SLI] Are you talking about a new capability or the existing ENH cap ? ENH 
tells you what is the NH AFI, so the only length check required is for the case 
of one or two IPv6 addresses. A new cap means a new solution, and that’s not 
the goal here. 

 

 

Point 2 - 

 

Addition of section 6.3 and SAFI 129 is fine, but again next hop encoding is 
lightly stating suboptimal. 

 

Conclusion: 

 

As we have discussed on and off line if revision is to be made let's make it 
both backwards compatible, Let's make it applicable to both IPv4 and IPv6 next 
hop addresses and let's allow explicit capability where implementations could 
indicate that it can recognize next hop value from its length. After all we are 
talking about just 4 discrete possible values here. 

[SLI] The goal is not to create something new here, but just to reflect how 
RFC5549 has been implemented for the SAFI 128/129 cases. The goal is also to 
minimize running code changes too (and even avoid !). We have to deal with what 
has been shipped and deployed by vendors today. We can still create something 
completely new, with a new cap and new procedures, but I think this is 
orthogonal to “aligning RFC5549 with implementations” as RFC5549 is there 
anyway and we can’t blindly forget it due to the codes that are available. 

 

 

 

Cheers,

Robert.

 

 

 

 

 

 

 

 

 

On Wed, Nov 27, 2019 at 1:36 PM Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com> > wrote:

Hello,

 

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

 

Please review the draft and post any comments to the BESS working group list.

 

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

 

Currently, there are no IPR disclosures against this document.

 

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.

 

This poll for adoption closes on Wednesday 11th December 2019.  

 

Regards,

Matthew 

 

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/

 

 

 

___
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] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Lizhenbin]

Hi Bocci & WG,
I support the adoption of the draft. There have been multiple implementations 
and the revision is well accepted.


Best Regards,
Zhenbin (Robin)





From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia - 
GB)
Sent: Wednesday, November 27, 2019 8:37 PM
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures against this document.

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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Dongjie (Jimmy)]

Hi,

I support the adoption of this document.

Best regards,
Jie
发件人：Bocci, Matthew (Nokia - GB) 
收件人：bess 
抄 送：bess-chairs 
时 间：2019-11-27 20:37:25
主题[bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

Currently, there are no IPR disclosures against this document.

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.

This poll for adoption closes on Wednesday 11th December 2019.

Regards,
Matthew

[1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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