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

[<[e-mail]>]

Hi all,

 

This adoption call is running for a long time. The WG adoption was a bit tough or at least unusual.

 

I hold on this call waiting for a sync-up with my co-chair to decide how we proceed.

 

We keep you posted asap.

 

Stephane

 

 

From: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]> 
Sent: jeudi 3 octobre 2019 00:51
To: Ali Sajassi (sajassi) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

 

Hi Ali,

 

Thank you for your feedback.

 

The draft is going through a WG adoption call, and although during the first part of the adoption call there was not much feedback, the draft has now fair good support from several Service Providers and vendors. We also got the feedback from a Service Provider that the topic is important enough to deserve a separate document where the WG can throw feedback and can be improved to make sure all cases are covered. So I believe it has to be adopted as an (Informational) WG document. 

 

When 7432bis is WG adopted (it’s not even published yet!), as a WG we can decide if loop-protection is part of it or not. My co-authors, other WG members and chairs can express their opinion as well.

 

About backhole mac vs ACL – backhole is more generic. You can implement it via ACL or flags in the bridge table or any other way. We don’t mandate how to do it, only the required behavior. If you do it via an “automatic” ACL, that’s your implementation choice. 

 

About the timer, it would be good if you can elaborate why it is questionable. We are very interested in your feedback and we would like to encourage the WG to also participate in the discussion, if the WG thinks loops are an important topic.

 

Thanks.

Jorge

 

 

From: "Ali Sajassi (sajassi)" <[e-mail] <mailto:[e-mail]> >
Date: Thursday, October 3, 2019 at 8:17 AM
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]> " <[e-mail] <mailto:[e-mail]> >
Cc: "[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 8:17 AM

 

 

We need to cover the loop protection for EVPN as we needed to cover MAC duplicate detection in EVPN. However, I am wondering why not simply cover it in couple of paragraphs in RFC7432bis. I made this comment when this draft was presented for the first time. My rational for it is as follow:

 

1)      The detection mechanism for loop protection is identical to MAC duplicate detection as described in section 15.1 of RFC 7432. As the matter of fact the procedure described in section 15.1 of RFC 7432 is repeated in this new draft.

2)      The only difference is action taken. For MAC duplicate detection, we stop advertising the learned MAC address; whereas, for loop prevention, we install an ACL for the duplicate MAC.

3)      We should also try to use commonly used terms as opposed to inventing new terms – i.e., instead of creating a new section in describing what blackhole MAC is, we should simply say we want to install ACL for MAC SA (to get discarded). 

4)      The new timer for flushing MAC SA and restarting the process IMO is questionable and should not be used.

 

Again, if we were not doing RFC7432bis, I would have been very supportive of this draft as we do need to cover loop protection; however, given that we can cover this loop protection by just adding one or two paragraphs to section 15.1, then I really don’t see the need to create unnecessary reading materials for our community.

 

Cheers,

Ali

 

 

 

From: BESS <[e-mail] <mailto:[e-mail]> > on behalf of "[e-mail] <mailto:[e-mail]> " <[e-mail] <mailto:[e-mail]> >
Date: Monday, September 2, 2019 at 7:29 AM
To: "[e-mail] <mailto:[e-mail]> " <[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]> >
Subject: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

 

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/

 

 

 

 

 <http://www.orange.com/> 

 

Stephane Litkowski 
Network Architect 
Orange/SCE/EQUANT/OINIS/NET

Orange Expert Future Networks

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> [phone]  NEW !
mobile:  <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> [phone]  NEW !
 <mailto:[e-mail]> [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.