Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

[JOSE MANUEL CRESPO GARCIA <[e-mail]>]

Hi

                Just 2 comments:

“There are many ways for fixing loop and I do not see why it needs to be common to all vendor.”
We think that’s the spirit of the standardization organizations. Operators use to have multiple vendors in our networks, so for us, is  better to have common an uniform solutions. We think that it is also good for vendors, it saves time to all of us.

“Having a separate draft (especially informal) allows customers to request compliancy with…. Which I disagree.”
Regardless of if it is in a draft, in an RFC or none of them, all the RFQs for L2VPN devices that we have been running since 2002, include  mandatory requirements for  loop protection mechanisms.  At the moment, we have an RFQ open and it includes not only the funcionality of this draft but also other loop protection mechanisms: “Port loop protection (TX and RX connection)”, “automatic mac pinning”, “interface blocking in case of mac move situations”, “hierarchy in the order of interface blocking”, etc…
After 17 years  of experience with L2VPN services, we would never deploy a network solution with a vendor that doesn’t implement strong loop protection mechanisms in order to protect our customer services.
Asumming that loops are not only a problem for Telefónica, we would like to have, at least for EVPN, the loop protection solutions included in an RFC, so that all vendor will solve the problem in the same way.

Regards

De: Patrice Brissette (pbrisset) <[e-mail]>
Enviado el: viernes, 4 de octubre de 2019 18:59
Para: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]>; Stephane Litkowski <[e-mail]>; [e-mail]
CC: [e-mail]; [e-mail]; [e-mail]
Asunto: Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

This is my last email on this… looks like the message doesn’t go thru …maybe there is a loop somewhere.

This informal draft is like a suggestion … It is about an action output of a well document procedure in RFC7432.
A suggestion may be vendor specific or not. There is nothing for vendors to interop with.

The fact that I’m seeing MUST in the draft and the fact it has been pushed to EANTC, it looks to me that it is not just a suggestion.
There is kind of hidden agenda there.
I simply disagree with that. I don’t want customer to ask me if we support your vendor specific solution.
Regards,
Patrice Brissette, Principal Engineer
Cisco Systems
Help us track your SP SR/EVPN Customer Opportunity/Status by filling these forms: Segment Routing<https://app.smartsheet.com/b/form/185833ace35b4894b324dfb8afbd2060> / EVPN<https://app.smartsheet.com/b/form/136bd5c3a22641bf92316523e79d6f22>

http://e-vpn.io, http://go2.cisco.com/evpn




From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]<mailto:[e-mail]>>
Date: Friday, October 4, 2019 at 11:55
To: Patrice Brissette <[e-mail]<mailto:[e-mail]>>, Stephane Litkowski <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

:-)

Patrice,
Our draft is Informational because it does not require to change the EVPN control plane, so we thought it was the right track.

Thanks.
Jorge

From: "Patrice Brissette (pbrisset)" <[e-mail]<mailto:[e-mail]>>
Date: Friday, October 4, 2019 at 5:17 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]<mailto:[e-mail]>>, Stephane Litkowski <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

Jorge,

If that is the case…since it looks like you were able to push the blackhole MAC at EANTC (not sure what magic you have done to get privilege), why is your draft informal?
Regards,
Patrice Brissette, Principal Engineer
Cisco Systems
Help us track your SP SR/EVPN Customer Opportunity/Status by filling these forms: Segment Routing<https://app.smartsheet.com/b/form/185833ace35b4894b324dfb8afbd2060> / EVPN<https://app.smartsheet.com/b/form/136bd5c3a22641bf92316523e79d6f22>

http://e-vpn.io, http://go2.cisco.com/evpn




From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]<mailto:[e-mail]>>
Date: Friday, October 4, 2019 at 09:20
To: Patrice Brissette <[e-mail]<mailto:[e-mail]>>, Stephane Litkowski <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

Hi Patrice,

Having a common way to solve loops is beneficial for the community. And if there are better ways, we should discuss them and maybe modify the document.

An informational draft that explains how some vendors solve this, I think, is relevant to the WG.
There is a public report where you have proof of multivendor support.

http://www.eantc.de/fileadmin/eantc/downloads/News/2019/EANTC-MPLSSDNNFV2019-WhitePaper-v1.2.pdf
(page 11)

Thanks.
Jorge

From: "Patrice Brissette (pbrisset)" <[e-mail]<mailto:[e-mail]>>
Date: Friday, October 4, 2019 at 2:49 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]<mailto:[e-mail]>>, Stephane Litkowski <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

Hi,

It is difficult to argue against an informal draft since it does not provides any obligation to any vendor to do it. There are many ways for fixing loop and I do not see why it needs to be common to all vendor.

That said, a paragraph in RFC7432bis reminding people about the problem is a good thing.

Having a separate draft (especially informal) allows customers to request compliancy with…. Which I disagree.

Regards,
Patrice Brissette, Principal Engineer
Cisco Systems
Help us track your SP SR/EVPN Customer Opportunity/Status by filling these forms: Segment Routing<https://app.smartsheet.com/b/form/185833ace35b4894b324dfb8afbd2060> / EVPN<https://app.smartsheet.com/b/form/136bd5c3a22641bf92316523e79d6f22>

http://e-vpn.io, http://go2.cisco.com/evpn




From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]<mailto:[e-mail]>>
Date: Friday, October 4, 2019 at 03:13
To: Patrice Brissette <[e-mail]<mailto:[e-mail]>>, Stephane Litkowski <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

Hi Patrice,

Thanks for explaining.

So I think you agree with the goal behind the draft, and the fact that has to be specified somewhere since you suggest rfc7432bis.
What you are arguing is whether it has to be in an already published document, or a yet-to-be-published document. Sure, that should be decided by WG rough consensus and chairs.

Some other points to your comments:

-    It is informational because it does not change any control plane element in RFC7432.

-    It explains the whole mac duplication process for the benefit of the reader

-    The use of Normative language can be certainly discussed

-    Loops are important and we think EVPN specs are not complete without addressing them. They can be resolved in different ways. This is an approach that tries to have a uniform behavior across implementations. That’s why we thought a draft was needed, and in particular, the Service Provider that co-authors the draft thought that way.

Thanks.
Jorge


From: "Patrice Brissette (pbrisset)" <[e-mail]<mailto:[e-mail]>>
Date: Friday, October 4, 2019 at 3:43 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]<mailto:[e-mail]>>, Stephane Litkowski <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

Hi Jorge,


As I mentioned, the draft is actually pretty thin as stated in section 4.2: This document enhances the EVPN MAC Duplication Mechanism by extending it with an optional Loop-protection action that is applied on the duplicate-MAC addresses.

The document describes at glance the problem. I agree that the problem is real and must be fixed.
However, the extension is simply an action on the MAC duplication mechanism to install a blackhole MAC as an option.
I’m not sure why there is a need for a draft. The action can be vendor specific. The fact that the draft is informal makes more sense. However, there is a requirement section with *MUST* keywords…. I’m confuse about this…since it is informal.

IMO, I would rather add a text to RFC7432bis to suggest what can be done. That will highlight the importance of such problem.

Having too many draft dilute the strength of our work.
Regards,
Patrice Brissette, Principal Engineer
Cisco Systems
Help us track your SP SR/EVPN Customer Opportunity/Status by filling these forms: Segment Routing<https://app.smartsheet.com/b/form/185833ace35b4894b324dfb8afbd2060> / EVPN<https://app.smartsheet.com/b/form/136bd5c3a22641bf92316523e79d6f22>

http://e-vpn.io, http://go2.cisco.com/evpn




From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, October 3, 2019 at 08:37
To: Patrice Brissette <[e-mail]<mailto:[e-mail]>>, Stephane Litkowski <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

Hi Patrice,

I understand that you may not support the draft.
However, it would help if you clarify the reason why:


-    Is it because you don’t think loops should be protected in the way the draft describes? If so please elaborate.

-    Or is it that you do support the idea in the draft, but think that it does not deserves its own document

-    Or maybe none of them? :-)

I think it is important to clarify that on the list.

Thank you.
Jorge


From: "Patrice Brissette (pbrisset)" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, October 3, 2019 at 2:25 PM
To: Stephane Litkowski <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Resent-Date: Thursday, October 3, 2019 at 2:24 PM

Hi,

I do not support that draft. I think it is a very tiny minor update which can incorporated in RFC7432bis.

Regards,
Patrice Brissette, Principal Engineer
Cisco Systems
Help us track your SP SR/EVPN Customer Opportunity/Status by filling these forms: Segment Routing<https://app.smartsheet.com/b/form/185833ace35b4894b324dfb8afbd2060> / EVPN<https://app.smartsheet.com/b/form/136bd5c3a22641bf92316523e79d6f22>

http://e-vpn.io, http://go2.cisco.com/evpn




From: BESS <[e-mail]<mailto:[e-mail]>> on behalf of Stephane Litkowski <[e-mail]<mailto:[e-mail]>>
Date: Thursday, September 19, 2019 at 05:05
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

Hi,

The poll has ended.
I haven't seen a lot of support from the various vendor while Jorge has mentioned that there are multiple implementations. Before closing definitely this poll, I would like to let the opportunity to other vendors to raise their voice and support the draft especially if they have implementations.
I will let an additional week.

Stephane


On Mon, Sep 2, 2019 at 4:29 PM <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

This email begins a two-weeks WG adoption poll for draft-snr-bess-evpn-loop-protect-04 [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 16th September 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-snr-bess-evpn-loop-protect/




[Orange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: [phone] <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>  NEW !
mobile: [phone] <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>  NEW !
[e-mail]<mailto:[e-mail]>


_________________________________________________________________________________________________________________________



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.

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição