Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

[Jeffrey (Zhaohui) Zhang]

Hi Ashutosh,

Sorry for the late response. Please see zzh> below.

From: Ashutosh Gupta 
mailto:ashutoshgupta.i...@gmail.com>>
Sent: Wednesday, August 15, 2018 3:57 AM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>
Cc: Ali Sajassi mailto:saja...@cisco.com>>; 
bess@ietf.org
Subject: Re: [bess] Comments on draft-sajassi-bess-evpn-mvpn-seamless-interop

Hey Jeffrey,

Thanks for your comments & please find my responses inline  .

On Fri, Jul 20, 2018 at 9:53 AM, Jeffrey (Zhaohui) Zhang 
mailto:zzh...@juniper.net>> wrote:
Hi Ali,

Here are the comments that I did not get a chance for in the meeting today.

Regarding "ttl decrement" and "src mac change":
--

Since "bridging/switching in the same BD" is not put down as a requirement in 
the spec but rather discounted citing "emulation", the listed "requirements" 
should be changed to "properties" as well - one could also argue that those may 
not be true requirements and could also discounted.

 seamless-Interop solution supports both intra-subnet and inter-subnet 
forwarding which are the basic requirement along with Efficient fabric 
utilization and Operational simplicity. More specifically, having many 
discussions with customers we didn't come across any use-case where strict 
intra-subnet bridging was needed along with inter-subnet routing, so we can 
argue that "strict bridging/switching in the same BD" is just an idealistic 
requirement.

Zzh> The point is, those “requirements” are really somewhat 
arbitrary/subjective. We have not heard real requirements about “seamless 
integration” either, and even when the requirement comes, the OISM can do that 
seamless integration by having every EVPN as an MEG.

Even if RFC7432 does not prove true ethernet service, "ttl decrement" and "src 
mac change" for intra-subnet traffic does NOT happen with RFC7432. In other 
words, this is a step-down from RFC7432.

 It is not a step down since we are not losing any needed functionality.

Zzh> It is a step down from what RFC7432 provides. The argument that TTL/mac 
change for intra-subnet is not an issue is subjective.

Again, seamless-interop solution utilizes existing and well deployed technology 
(MVPN) instead of re-defining all the constructs of MVPN into EVPN. 
evpn-irb-multicast draft takes later approach and achieves in-signification 
functionality gain at the expense of huge overhead in control-plane (Explained 
on a separate thread). From our customer interactions, we understand that 
Multicast is a complex technology to deploy, operate and troubleshoot. So any 
amount of simplification results in Opex reduction. Additionally, re-use of 
existing MVPN implementation for additional EVPN use-cases results in quick 
time-to-market with lower investment.

Zzh> Please see Eric’s comment on a separate thread. Both Eric and I are from 
MVPN background - trust us that we’d not be against “just use MVPN” if it 
solves EVPN problems effectively.
Zzh> BTW, with the seamless approach, aren’t you guys abandoning the SMET 
solution defined in draft-ietf-bess-evpn-igmp-mld-proxy?

About the comment "MVPN also decrements ttl and change src mac address" - 
that's expected behavior because it is routing between subnets not "intra 
subnet", and no application that uses MVPN service has assumption on constant 
TTL and src mac.

More regarding the "requirements" (or "properties")
---

With the other solution (evpn-irb-multicast, aka OISM), if every EVPN PE runs 
the MEG procedures then the same set of "requirements" is also achieved - it is 
also "seamless interop" but based on the OISM procedures, but that does not 
"translate into this method" (as defined in the seamless-interop draft) (I 
think that's what you mentioned when addressing Jorge's comment). What's more, 
it does not have the "ttl decrementing" and "src mac change" issue for intra 
subnet traffic.
 The point was made that once multicast traffic reaches MVPN domain, it 
doesn't belong to any specific BD and hence intra-subnet and inter-subnet 
receivers are treated similarly. Even with evpn-irb-multicast solution, it 
would be the same unless a second copy of traffic is send over BD specific 
tunnel.

Zzh> But for traffic reaching MVPN domain, we don’t need to worry about TTL and 
src mac address change, while we do need to worry about that on EVPN side in 
case of intra-subnet. Indeed separate copies are sent for EVPN and MVPN, but 
the MVPN copy is only when a remote MVPN PE is not also an EVPN PE. It’s hard 
to argue that removing that one extra MVPN copy (that is sent towards MVPN-only 
PEs) is a hard “requirement”.
Zzh> A bit more elaboration on the above “extra copy”. While the traffic is 
sent on a BD specific tunnel and on an MVPN tunnel, if we’re using ingress 
replication then there is no extra copy at all – one copy is sent to each EVPN 
PEs (the 

Re: [bess] Second WG Last Call on draft-ietf-bess-vpls-multihoming-02

[Bocci, Matthew (Nokia - GB)]

Folks

Across the two working group last calls for this draft, I think we have 
consensus to publish it as an RFC.

I will sends a document shepherd’s review shortly.

Best regards

Matthew

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

Date: Monday, 24 September 2018 at 12:04
To: "bess@ietf.org" 
Subject: [bess] Second WG Last Call on draft-ietf-bess-vpls-multihoming-02

All

Since we have received a recent IPR declaration on this draft and the first WG 
last call was so long ago, we are running a second last call to reaffirm WG 
consensus to publish the draft as an RFC.

Therefore, this email begins a two-week working group last call for 
draft-ietf-bess-vpls-multihoming-02.txt

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

Currently there is one IPR declaration against this document.

We are also polling for any existing implementations.

The working group last call closes on Monday 8th Oct 2018.

Regards,
Matthew and Stéphane



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

Re: [bess] Signaling Control Word in EVPN => please strip recipients

[stephane.litkowski]

Hi Folks,

We are receiving a lot of moderation requests for this topic due to the long 
list of recipients.
Please keep only BESS list as a recipient for any further message so the 
message will be published automatically on the list.

Thanks in advance,


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Andrew G. Malis
Sent: Tuesday, October 09, 2018 16:54
To: jwbens...@gmail.com
Cc: Muthu Arul Mozhi Perumal; Alexander Vainshtein; shell.nak...@ecitele.com; 
yechiel.rosengar...@ecitele.com; michael.gorokhov...@ecitele.com; 
dmitry.vald...@ecitele.com; ron.sday...@ecitele.com; bess@ietf.org; Rotem Cohen
Subject: Re: [bess] Signaling Control Word in EVPN

James,

Agreed. We touched on that in section 7 of draft-ietf-pals-ethernet-cw, where 
we advised operators that enabling post-CW DPI for ECMP calculations could 
cause misordering.

Cheers,
Andy


On Tue, Oct 9, 2018 at 10:35 AM James Bensley 
mailto:jwbens...@gmail.com>> wrote:
On Tue, 9 Oct 2018 at 15:16, Andrew G. Malis 
mailto:agma...@gmail.com>> wrote:
>
> James,

Hi Andy,

> It's much harder to mandate use of EL than the CW for several reasons:

I didn't say it should be mandated, but recommended.

> - CW implementation is much more common than EL implementation
> - PWs and/or EVPN are rarely the only traffic in an MPLS traffic tunnel, 
> rather, they will be multiplexed with other MPLS-based applications that are 
> using the traffic tunnel to reach a common destination. Thus, by using the 
> CW, you can disable ECMP only for those MPLS packets that cannot tolerate 
> reordering.

The CW does not disable ECMP. Any LSR on the path between ingress and
egress LER is free to look beyond the MPLS label stack and
misinterpret the 0x00 0x00 at the start of a control-word as a valid
MAC that starts 00:00:XX:XX:XX:XX and try to hash on Ethernet headers
starting directly after the MPLS label stack, and not label stack + 4
bytes. This is my point. The PWMCW doesn't stop re-ording in all
cases, but it does in most. So yes, not all devices support EL, but CW
doesn't stop re-ordering in all cases, so?

> That said, I'm also concerned that because of the existing text in 7432, 
> implementations may not be using the CW even for P2P EVPN.
>
> And we still don't have a good answer for Muthu's original question. :-)

Sorry my intention is not to send this thread off-topic.

Cheers,
James.

_

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