Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

[Sandy Breeze]

Hi Wen,

Yes, we absolutely need to support more than one remote VTEP in the access 
side.  As for how to deal with one or more than one remote VTEP, I don’t agree 
it’s quite the same as one CE vs more than one CE.  For a single VNI in a BD, 
we should treat this as a single virtual ES in a BD, regardless of how many 
remote VTEPs there are participating in it.  This is treated differently to 
multiple CE on a BD, because multiple CE might imply multiple ES’s.

Cheers
Sandy

On 03/04/2018, 19:01, "Wen Lin" > 
wrote:

The question is, in general,  whether we need to support more than one remote 
VTEP in this type of use case when VXLAN is used on the access side?   I think 
the answer is yes.

So the question about how to deal with “one remote VTEP verses more than one 
remote VTEP” is logically the same as “one CE verses more than one CE”.

Thanks,
Wen


From: BESS  on behalf of "Ali Sajassi (sajassi)" 

Date: Monday, March 26, 2018 at 2:54 PM
To: "UTTARO, JAMES" , John E Drake , 
"Rabadan, Jorge (Nokia - US/Mountain View)" , Eric 
Rosen , Sandy Breeze , "Satya 
Mohanty (satyamoh)" 
Cc: "Ali Sajassi (sajassi)" , "bess@ietf.org" 
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Hi Jim,

Draft-mohanty-bess-evpn-bum-opt is for a very specific use case and that use 
case is described in section 4.4 of draft-ietf-bess-dci-evpn-overlay. The 
solution for optimization for this use case could have been covered either in 
igmp-mld-proxy draft itself or it could be covered in a separate draft. I 
suggested it to be covered in a separate draft because I wasn’t keen in adding 
a new section to igmp-mld-proxy given that it is getting ready for WG LC. 
However, if people think it should be covered in igmp-mld-proxy draft then we 
can take that under consideration.

The interconnect of L2 to IRB/L3 core will be covered in the corresponding IRB 
mcast drafts.

Cheers,
Ali

From: "UTTARO, JAMES" 
Date: Monday, March 26, 2018 at 10:46 AM
To: Cisco Employee , John E Drake , 
"Rabadan, Jorge (Nokia - US/Mountain View)" , Eric 
Rosen , Sandy Breeze , "Satya 
Mohanty (satyamoh)" 
Cc: "bess@ietf.org" 
Subject: RE: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Ali,

So, is this going to be a family of drafts dealing with 
inter-connection aspects across a set of use cases ? Would it be useful to 
right up a requirements draft like we did with EVPN??

Thanks,
Jim Uttaro

From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Monday, March 26, 2018 1:20 PM
To: UTTARO, JAMES ; John E Drake ; Rabadan, 
Jorge (Nokia - US/Mountain View) ; Eric Rosen 
; Sandy Breeze ; Satya Mohanty 
(satyamoh) 
Cc: bess@ietf.org
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Hi Jim,

draft-mohanty-bess-evpn-bum-opt will focus on L2 only between EVPN overlay 
(VxLAN) access domain and EVPN MPLS core. Connectivity EVPN IRB core (or EVPN 
L3 core) will be covered in the other drafts that I mentioned below because 
they are  already doing it for other use cases.

Cheers,
Ali

From: "UTTARO, JAMES" >
Date: Monday, March 26, 2018 at 10:03 AM
To: Cisco Employee >, John E Drake 
>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" >, 
Eric Rosen >, Sandy Breeze 
>, "Satya Mohanty 
(satyamoh)" >
Cc: "bess@ietf.org" >
Subject: RE: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Ali,

So is the plan to incorporate Sandy’s work in these docs??

Thanks,
Jim Uttaro


From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Monday, March 26, 2018 11:55 AM
To: UTTARO, JAMES >; John E Drake 
>; Rabadan, Jorge (Nokia - 
US/Mountain View) >; 
Eric Rosen >; Sandy Breeze 
>; Satya 

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

[Alexander Vainshtein]

Ali,
Lots of thanks for a prompt and very informative response.

You answers address all my comments, I expect to see them in the -03 revision 
of the draft..

All,
I support progressing the draft with the changes mentioned in Ali’s email.


Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Tuesday, April 3, 2018 5:14 AM
To: Alexander Vainshtein ; Bocci, Matthew 
(Nokia - GB) 
Cc: bess-cha...@ietf.org; draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org; 
bess@ietf.org
Subject: Re: WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

Hi Sasha,

Once more thank very much for your review and your comments. Please refer to my 
reply inline

From: Alexander Vainshtein 
>
Date: Thursday, March 29, 2018 at 4:32 AM
To: "Bocci, Matthew (Nokia - GB)" 
>
Cc: "bess-cha...@ietf.org" 
>, 
"draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org"
 
>,
 "bess@ietf.org" >, 
Cisco Employee >
Subject: RE: WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

Hi all,
Please see below some technical and editorial comments/question on the draft.

Technical:

  1.  Section 3 mentions that integration between VPLS and EVPN is “possible 
(but cumbersome)” even if the brownfield VPLS service instance has been set up 
without BGP-based auto-discovery. I wonder if such integration is possible even 
if the VPLS PEs do not support BGP-based VPLS auto-discovery at all. (Note that 
Section 3.1 says that the VPLS PEs “advertise the BGP VPLS AD route”)
Such integration is possible but cumbersome. So, I added an explanation to the 
end of the sentence describing why it is cumbersome:
“In order to support seamless integration with (PBB-)VPLS PEs, this document 
requires that (PBB-)VPLS PEs support VPLS AD per [RFC6074] and (PBB-)EVPN PEs 
support both BGP EVPN routes per [RFC7432] and VPLS BGP-based A-D per 
[RFC6074]. All the logic for this seamless integration SHALL reside on the 
(PBB-)EVPN PEs. However, if a VPLS instance is setup without the use of 
BGP-based A-D, it is still possible (but cumbersome) for (PBB-)EVPN PEs to 
integrate into that VPLS instance by manually configuring the target VPLS PE 
addresses for each VPLS instance on each (PBB-)EVPN PE (i.e., the integration 
is no longer seamless).”


  1.  In Section 3.1, the draft says that, if the operator uses the same RT for 
 VPLS AD routes and EVPN routes, “when a (PBB-)VPLS PE receives the EVPN 
Inclusive Multicast route, it will ignore it on the basis that it belongs to an 
unknown SAFI”.  This statement raises two comments:
 *   Should not “will” here be “MUST”?
I think both are correct but changed it to “MUST” to make it stronger.


 *   What if SAFI used for the EVPN Inclusive MC route is known to the 
MP-BGP instance in the VPLS PE (e.g., because some EVPN instance with MAC-VRF 
in this PE has been already set)? I assume that the EVPN Inclusive MC route 
still MUST be ignored, but the basis for that would be that it is not 
understood by the VSI that represents the VPLS instance in this PE
The VPLS PEs don’t support EVPN SAFI. If they do, then they are called EVPN 
PEs. In other words, only EVPN PEs are bi-lingual (can speak both EVPN and VPLS 
languages).


  1.  The text in Section 4.2.1 says that if, following MAC move from an EVPN 
PE to a VPLS PE, it initiates BUM traffic, this traffic is flooded to both VPLS 
and EVPN PEs and “the receiving PEs update their MAC tables (VSI or MAC-VRF)”. 
However, Section 3.2 says that MAC addresses received by the EVPN PE via PWs 
from VPLS PEs are “not injected into (PBB-)EVPN MAC-VRF tables but rather they 
are injected into their corresponding (PBB-)VPLS VSI table”. These two 
statements look mutually contradictory to me. (See also my editorial comment 
about having both MAC-VRF and VSI MAC table in the EVPN PE).
In general, the MAC addresses learned over PWs should be injected into the 
MAC-VRF but depending on whether the PW is access-facing or core-facing, it 
will or will not be advertised in control-plane. So, I updated the paragraph in 
section 3.2 to the following:
“When the (PBB-)EVPN PE receives traffic over the pseudowires, it learns the 
associated MAC addresses in the data-plane. The MAC addresses learned over PWs 
are injected into (PBB-)EVPN MAC-VRF table. For seamless integration between 
(PBB-)EVPN and (PBB-)VPLS PEs, 

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

[Henderickx, Wim (Nokia - BE/Antwerp)]

Support, we have an implementation on this

From: BESS  on behalf of EXT Jeff Tantsura 

Date: Wednesday, 4 April 2018 at 00:59
To: "Bocci, Matthew (Nokia - GB)" , 
"draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org" 
, "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: Re: [bess] WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

Yes/support

Cheers,
Jeff
From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Wednesday, March 28, 2018 at 5:50 AM
To: "draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org" 
, "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

This email begins a two-week working group last call for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

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 is one IPR declaration 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.
We are also polling for any existing implementations.
The working group last call closes on Wednesday 11th April.

Regards,
Matthew and Stéphane

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

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

Support

G/

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia - 
GB)
Sent: Wednesday, March 28, 2018 14:50
To: draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

This email begins a two-week working group last call for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

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 is one IPR declaration 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.

We are also polling for any existing implementations.

The working group last call closes on Wednesday 11th April.

Regards,

Matthew and Stéphane
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess