Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07

[stephane.litkowski]

Hi WG,

The poll has ended.
Some concerns have been raised on having this opaque route. More discussion is 
required before adopting the document.

Stephane


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Stephane Litkowski
Sent: Monday, August 19, 2019 16:32
To: bess@ietf.org
Subject: [bess] WG adoption call and IPR poll for 
draft-rabadan-bess-vendor-evpn-route-07

Hi,

This email begins a two-weeks WG adoption poll for 
draft-rabadan-bess-vendor-evpn-route-07 [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 2nd September 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/

_

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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-igmp-mld-proxy

[stephane.litkowski]

Hi Mankamana,

When do you think the next revision will be available ?

Thanks,

Stephane


From: Mankamana Mishra (mankamis) [mailto:manka...@cisco.com]
Sent: Tuesday, August 27, 2019 23:17
To: Anoop Ghanwani
Cc: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org; bess-cha...@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-igmp-mld-proxy

Thanks Anoop for your valuable comment.  Really apricate you taking time to 
have quick call. As agreed on call, I have covered most of your view comment.  
It would be seen in next revision.

Thanks
Mankamana


From: Anoop Ghanwani 
Date: Sunday, June 30, 2019 at 10:05 AM
To: "Mankamana Mishra (mankamis)" 
Cc: "stephane.litkow...@orange.com" , 
"bess@ietf.org" , "bess-cha...@ietf.org" 
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-igmp-mld-proxy
Resent-From: 
Resent-To: , , 

Resent-Date: Sunday, June 30, 2019 at 10:05 AM

Hi Mankamana,

I sent the doc to the authors, and I have put a pdf version here:
https://anoop.updog.co/ietf/draft-ietf-bess-evpn-igmp-mld-proxy-AG.pdf

Thanks,
Anoop

On Sun, Jun 30, 2019 at 6:12 AM Mankamana Mishra (mankamis) 
mailto:manka...@cisco.com>> wrote:
Hi Anoop,
Please send it across. We are going to make changes about editorial comment 
right after WGLC and post updated version.

Thanks
Mankamana


From: Anoop Ghanwani mailto:an...@alumni.duke.edu>>
Date: Saturday, June 29, 2019 at 1:04 AM
To: "stephane.litkow...@orange.com" 
mailto:stephane.litkow...@orange.com>>
Cc: "bess@ietf.org" 
mailto:bess@ietf.org>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-igmp-mld-proxy
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: mailto:matthew.bo...@nokia.com>>, 
mailto:stephane.litkow...@orange.com>>, 
mailto:manka...@cisco.com>>
Resent-Date: Saturday, June 29, 2019 at 1:04 AM

I support the publication of the document as an RFC.

I have several editorial comments and I'll send them in a Word document markup 
to the authors.

If the mailing list accepts attachments, I'd be happy to post it here as well.

Thanks,
Anoop

On Mon, Jun 17, 2019 at 1:53 AM 
mailto:stephane.litkow...@orange.com>> wrote:

Hello Working Group,



This email starts a three weeks Working Group Last Call on  
draft-ietf-bess-evpn-igmp-mld-proxy [1].



This poll runs until *the 28th of June*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



We have several IPRs already disclosed.



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 implementation as per [2].



Thank you,

Stephane & Matthew


[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy/

[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw



[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



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 

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

[stephane.litkowski]

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]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_

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

Re: [bess] draft-ietf-bess-evpn-igmp-mld-proxy-03 shepherd's review

[stephane.litkowski]

Hi Mankamana,

Pls find additional feedbacks inline.

Brgds,

Stephane


From: Mankamana Mishra (mankamis) [mailto:manka...@cisco.com]
Sent: Tuesday, August 27, 2019 00:38
To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org; 
bess@ietf.org
Cc: Mankamana Mishra (mankamis)
Subject: Re: [bess] draft-ietf-bess-evpn-igmp-mld-proxy-03 shepherd's review

Hi Stephane,
Thanks for your review comment. Please find inline.

Thanks
Mankamana


From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Tuesday, August 20, 2019 at 6:20 AM
To: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "bess@ietf.org" 
Subject: [bess] draft-ietf-bess-evpn-igmp-mld-proxy-03 shepherd's review

Hi,

There are some Nits to fix:
https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bess-evpn-igmp-mld-proxy-03.txt


Here is my review of the document:

Abstract & Intro:
s/RFC 7432/ RFC7432.
The reference should be removed from the abstract (as per IDNits).
Mankamana:   Will be taken care of in next revision.

§2.1:
It may be good to change the paragraph name to IGMP/MLD proxy and use IGMP/MLD 
in the paragraph. This comment could apply to various other places of the 
document.
 Mankamana: Will take care for paragraph name. Inside paragraph we have used 
IGMP , and start of the document we did state that all of IGMP procedure are 
applicable for MLD too.  Is it ok ?
§2.1.1:

-“it only sends a single BGP
   message corresponding to the very first IGMP Join”.
[SLI] Do we really care about the IGMP message (first or second…) used as a 
source to build the EVPN route ? The important point is that we do it only one 
time.
   Mankamana:   changing text to “very first IGMP Join received”.  
Purpose of this text is to clarify that we send BGP route as soon as we process 
it for first time locally. Subsequent joins are not sent.
[SLI2] Could you add a statement about this goal of sending the 
BGP update asap ?




-  For MLD what is the expected behavior in term of flag setting in the 
SMET, do we set v2 for MLDv2 or do we consider that it is equivalent to IGMPv3 
and then we set v3 ?
   Mankamana:  Have text in terminology
“ This document also assumes familiarity with the 
terminology of
   [RFC7432]. Though most of the place this document uses term IGMP
   membership request (Joins), the text applies equally for MLD
   membership request too. Similarly, text for IGMPv2 applies to MLDv1
   and text for  IGMPv3 applies to MLDv2”

I hope this covers your comment.

[SLI2] It does partially, the thing that IGMPv2 is similar to MLDv1 does not 
explicitly say what we do it term of encoding of the version number. As the 
version encoding is clearly stated in §7.1, it would be better to point to this 
paragraph rather than giving an ambiguous/partial information there.



-  s/BGP is a statefull/BGP is a stateful  ?
Mankamana : Done.


-  In 1),  for clarity purpose, it would be good to separate the (*,G) 
and (S,G) case in two separate paragraphs. At the first read, when reading “In 
case of IGMPv3, exclude flag…”, I thought it was always applicable for IGMPv3 
which does not make sense, while it is applicable only “If the IGMP Join is for 
(*,G)”.
Mankamana: Across document (*,G) and (S,G) processing have been written 
together, do you think for consistency it might be good to keep it in single 
paragraph ?

[SLI2] They can remain in the same section, I just wanted to add an empty line 
just before “If the IGMP Join is for (S,G),”.



-  IMO, 1) 2) 3) and 4) should use normative language
Mankamana: Will be taken care in next update.



-  Wouldn’t it be better to present the encoding of SMET before ? 
Because the text talks about fields set in the route while it hasn’t been 
presented yet.
Mankamana:   Do you want to move BGP encoding before this section ?
[SLI2] Two options, you move the encoding before or you at least point to the 
section where the encoding is detailed.




-  5) talks about errors that SHOULD be logged, but from a BGP 
perspective, is it considered as a BGP error ? What is the expected behavior 
per RFC7606 ?
Mankamana: Would update this, and it SHOULD be considered as BGP error and 
should be handled as per RFC7606



-  7) is not clear about IGMPv3, the first part of the text tells that 
the IGMP Join must not be sent if there is no PIM router. While the end of the 
text tells that it is not a problem for IGMPv3. So is there a difference 
between IGMPv2 and IGMPv3 reports ?
Mankamana: This comment is not clear. Last part of the paragraph trying to 
explain that what is difference in behavior for IGMPv2 and IGMPv3 .  If you 
think text should be modified, it would be great if you could suggest expected 
text .
[SLI2] It is not clear to me if the IGMP suppression is applicable both to 
IGMPv3 and IGMPv2 or only to IGMPv2 as IGMPv3 does not 

Re: [bess] Fwd: I-D Action: draft-ietf-bess-mvpn-fast-failover-07.txt

[stephane.litkowski]

Thanks Greg, I will have a look at the document in the coming weeks and proceed 
accordingly.


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Greg Mirsky
Sent: Sunday, August 25, 2019 02:12
To: BESS; bess-cha...@ietf.org; Jeffrey (Zhaohui) Zhang
Subject: [bess] Fwd: I-D Action: draft-ietf-bess-mvpn-fast-failover-07.txt

Dear All,
this version addresses all the comments received during the WGLC.

Regards,
Greg
-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Sat, Aug 24, 2019 at 5:05 PM
Subject: [bess] I-D Action: draft-ietf-bess-mvpn-fast-failover-07.txt
To: mailto:i-d-annou...@ietf.org>>
Cc: mailto:bess@ietf.org>>



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   : Multicast VPN fast upstream failover
Authors : Thomas Morin
  Robert Kebler
  Greg Mirsky
Filename: draft-ietf-bess-mvpn-fast-failover-07.txt
Pages   : 18
Date: 2019-08-24

Abstract:
   This document defines multicast VPN extensions and procedures that
   allow fast failover for upstream failures, by allowing downstream PEs
   to take into account the status of Provider-Tunnels (P-tunnels) when
   selecting the upstream PE for a VPN multicast flow, and extending BGP
   MVPN routing so that a C-multicast route can be advertised toward a
   standby upstream PE.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-mvpn-fast-failover-07
https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-fast-failover-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-fast-failover-07


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

_

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

Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07

[stephane.litkowski]

Hi,

Speaking as individual, what is the goal of the vendor key ? Is it to allow a 
vendor to encode multiple “sub-types” with different vendor specific info ?  Or 
is it a security key ? That would be great to mention how a vendor should use 
it.

Thanks !

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Stephane Litkowski
Sent: Monday, August 19, 2019 16:32
To: bess@ietf.org
Subject: [bess] WG adoption call and IPR poll for 
draft-rabadan-bess-vendor-evpn-route-07

Hi,

This email begins a two-weeks WG adoption poll for 
draft-rabadan-bess-vendor-evpn-route-07 [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 2nd September 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/

_

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

[bess] draft-ietf-bess-evpn-igmp-mld-proxy-03 shepherd's review

[stephane.litkowski]

Hi,

There are some Nits to fix:
https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bess-evpn-igmp-mld-proxy-03.txt


Here is my review of the document:

Abstract & Intro:
s/RFC 7432/ RFC7432.
The reference should be removed from the abstract (as per IDNits).


§2.1:
It may be good to change the paragraph name to IGMP/MLD proxy and use IGMP/MLD 
in the paragraph. This comment could apply to various other places of the 
document.

§2.1.1:

-"it only sends a single BGP
   message corresponding to the very first IGMP Join".
[SLI] Do we really care about the IGMP message (first or second...) used as a 
source to build the EVPN route ? The important point is that we do it only one 
time.


-  For MLD what is the expected behavior in term of flag setting in the 
SMET, do we set v2 for MLDv2 or do we consider that it is equivalent to IGMPv3 
and then we set v3 ?


-  s/BGP is a statefull/BGP is a stateful  ?

-  In 1),  for clarity purpose, it would be good to separate the (*,G) 
and (S,G) case in two separate paragraphs. At the first read, when reading "In 
case of IGMPv3, exclude flag...", I thought it was always applicable for IGMPv3 
which does not make sense, while it is applicable only "If the IGMP Join is for 
(*,G)".


-  IMO, 1) 2) 3) and 4) should use normative language



-  Wouldn't it be better to present the encoding of SMET before ? 
Because the text talks about fields set in the route while it hasn't been 
presented yet.



-  5) talks about errors that SHOULD be logged, but from a BGP 
perspective, is it considered as a BGP error ? What is the expected behavior 
per RFC7606 ?



-  7) is not clear about IGMPv3, the first part of the text tells that 
the IGMP Join must not be sent if there is no PIM router. While the end of the 
text tells that it is not a problem for IGMPv3. So is there a difference 
between IGMPv2 and IGMPv3 reports ?
§2.1.2:

-  You have a paragraph numbering issue "IGMP Leave Group Advertisement 
in BGP" should be 2.1.2

-  As for §2.1.1, normative language should be used

-  2) I agree that there is an error when a SMET is received with all 
version flags unset. How does the receiver handle this ? does it consider the 
NLRI has withdrawn per RFC7606 from a BGP perspective ? Does it the the current 
state of the route and ignore the update ? Does it close the session ?

-  2) "If the PE receives an EVPN SMET route withdraw, then it must
   remove the remote PE from the OIF list associated with that multicast
   group." This text is a duplicate on 3).



§2.2:
s/each PE need to have/each PE MUST have/ ?

§4:
s/support IGMP sync procedures/support IGMP synchronization procedures/

§4.1:
s/The IGMP Join Sync route carries the ES-Import RT/ The IGMP Join Sync route 
MUST carry the ES-Import RT/

Again, the paragraph lacks of normative language

§4.3:
s/procedure section(4.1)/the procedure defined in section 4.1/
s/Remote PE (PE/Remote PEs (PEs/

§5:
Need to use normative language

The paragraph uses IGMP Join Sync Route or Leave Sync route while §7 uses 
Multicast Join Synch Route. Please ensure consistency. This applies to other 
sections of the document.


§6:
Please expand "IR" in the title and add it into the acronyms section.

"all of the PEs in the BD support that tunnel type and IGMP", do you mean IGMP 
proxy ?


§7.1 brings some clarification about MLD usage which wasn't clear in section 2.
However §2 is still confusing in version numbers between IGMP and MLD. As an 
example, a SMET with a source must not exist with IGMPv2/1 while it must not 
with MLDv1 only.

§7.1.1

"Support for this route type is
   optional.". With regards to RFC7432, yes. However if an implementation 
supports this draft, the support of the NLRI is mandatory.


§7.3.1
Typo is the title: s/Multicas/Multicast/

§7.4:
s/it Must set the IGMP Proxy/it MUST set the IGMP/MLD Proxy/
Could we have some device that support IGMP proxy but not MLD proxy ?


§9:
s/RECOMENDED/RECOMMENDED

§10:
Does it change something to IGMP/MLD security ? Maybe this should be mentioned 
as well

References:
I think that IGMP and MLD RFCs should be set as normative. You should add 
MLDv1, IGMPv2, IGMPv1 as references as well and use the references in the text.

RFC7387 and 7623 are referenced but not used

s/FC4541/RFC4541/

RFC7606 and 4684 should be set as normative


Brgds,


[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

[bess] Affiliation change

[stephane.litkowski]

Hi WG,

This email is just to let you know that my affiliation will change starting 
mid-September as I'm moving from Orange to Cisco.
As per Martin's approval, I'll keep acting as co-chair for our WG.

Brgds,

Stephane

_

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

Re: [bess] Discussion on various NH encoding

[stephane.litkowski]

Hi WG,

To followup on this item, we have scheduled an open mic slot during our first 
session on Tuesday to discuss this topic and see if there is an action plan to 
trigger.
I'll prepare few slides to start the discussion.

See you in Montreal and have good travel.

Stephane


From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Friday, June 28, 2019 10:40
To: bess@ietf.org
Cc: bess-cha...@ietf.org; martin.vigour...@nokia.com
Subject: Discussion on various NH encoding

Hi WG,

(Speaking as co-chair)

The current discussion on the NH encodings in our AFI/SAFIs requires some 
particular attention.
We would like to take the opportunity of the next IETF to discuss the subject 
face to face.

In the meantime, we are looking for few volunteers who will:

-  Do an inventory of what do we have in our specifications: which 
AFI/SAFI, which NH encoding rules

-  Identify inconsistencies (if any) or assess if it hurts or not 
(theoretically)

-  What is implemented or is there some known implementation issues

-  Present and drive the discussion at next IETF

Based on this, we will see if there is something to do or not.
Timing is short before next IETF, however the more material we have, the better 
the discussion will be.

Who wants to help on this ?


Brgds,

Stephane & Matthew


_



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.

_

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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-igmp-mld-proxy

[stephane.litkowski]

Hi WG,

Sorry for the late feedback on this one.
This WGLC is closed and there is no objection to progress. In addition, we have 
implementations.
I note that Ali has to update the document and this will be part of the next 
revision. However this does not prevent to go to the next step.

Brgds,

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, June 17, 2019 10:53
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-igmp-mld-proxy


Hello Working Group,



This email starts a three weeks Working Group Last Call on  
draft-ietf-bess-evpn-igmp-mld-proxy [1].



This poll runs until *the 28th of June*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



We have several IPRs already disclosed.



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 implementation as per [2].



Thank you,

Stephane & Matthew


[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy/

[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw



[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



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.

_

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

Re: [bess] [Idr] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

[stephane.litkowski]

Unfortunately I don’t have the history, we discovered this behavior when doing 
some VPNv6 testings a couple of months ago between IOS and Junos. IOS XE does 
advertise two nexthops.

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Friday, June 28, 2019 11:11
To: LITKOWSKI Stephane OBS/OINIS
Cc: Xiejingrong; softwi...@ietf.org; draft-dawra-bess-srv6-servi...@ietf.org; 
bess@ietf.org; i...@ietf.org
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address 
coding for IPv4 VPN over IPv6 Core in RFC5549

Stephane,

Sure you can send two NHs next to each other. But my main question is what 
should the receiver of such "thing" do ? Which next hop is more important to be 
actually used in forwarding ? Based on what elements such decision is made ...

If you know some history and can share it here iI think it may be useful for 
others.

Btw which implementation sends two :) ? Should not be a big secret I suppose.

Thx,
R.

On Fri, Jun 28, 2019 at 9:48 AM 
mailto:stephane.litkow...@orange.com>> wrote:
Hi Robert,

There are implementations which set two NHs, here is a capture:

Update Message (2), length: 150
  Multi-Protocol Reach NLRI (14), length: 100, Flags [O]:
AFI: IPv6 (2), SAFI: labeled VPN Unicast (128)
nexthop: RD: 0:0 (= 0.0.0.0), 2000::162RD: 0:0 (= 0.0.0.0), 
fe80::2a94:fff:fefa:3cc0, nh-length: 48, no SNPA
  RD: 10283:803700200 (= 47.231.125.232), 2000:bebe:37::/56, 
label:1313 (bottom)
  RD: 10283:803700200 (= 47.231.125.232), 2000:bebe:37::1/128, 
label:1314 (bottom)
  Origin (1), length: 1, Flags [T]: IGP
  AS Path (2), length: 6, Flags [T]: 1
  Extended Community (16), length: 8, Flags [OT]:
target (0x0002), Flags [none]: 1:00200 (= 59.153.68.40)

Note that this behavior caused some interop issues with another vendor who 
partially supported RFC4659.

Brgds,



From: Idr [mailto:idr-boun...@ietf.org] On Behalf 
Of Robert Raszuk
Sent: Thursday, June 27, 2019 12:50
To: Xiejingrong
Cc: softwi...@ietf.org; 
draft-dawra-bess-srv6-servi...@ietf.org;
 bess@ietf.org; i...@ietf.org
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address 
coding for IPv4 VPN over IPv6 Core in RFC5549

> Back to my suggestion: implementation should interpret nexthop RD+IPv4 and 
> nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the 
> same.

When elements of BGP UPDATE message are being parsed code must know what to 
expect. Note that we are dealing here with deployed SAFI 128 for nearly 20 
years.

So today there are two ways to know what format of next hop is in MP_REACH:

a) Inferring it from AFI/SAFI per section 3 of RFC4760

or (in addition to the above coarse assumption)

b) Inferring it from the discrete value of next hop length field as defined in 
section 3 of RFC5549

Note that if we would be defining new SAFI we can write anything we like to the 
rules of constructing the update message. But here again we are dealing with 
something which is deployed so sort of operating on the plane in flight.

If implementation can infer next hop type from length we are safe to define all 
sections to have next hop length = 16 octets and be done. But if there are some 
implementations which would only take AFI/SAFI to check if the next hop is 
correct or even further to check if the next hop length is correct then we have 
a problem.

/* Btw this notion of next hop length = 32 is bizarre ! I have never seen any 
BGP implementation sending two next hops (global IPv6 address followed by link 
local IPv6 address) not I am able to find any docs describing how any BGP stack 
would handle it. IMHO we should move this 32 next hop length to historic asap. 
*/

To the msg from Martin,

> maybe the WG would like to reach a conclusion on how to treat that erratum:
> http://www.rfc-editor.org/errata/eid5738

I would vote to reject the errata. There is no value of stuffing 8 octet of 
zeros in the next hop field. If the RFC got defined in 2012 that really means 
that most implementations are capable of inferring next hop format from the 
length field - which is very good. Accepting the errata would be a step 
backwords.

Thx,
R.

On Thu, Jun 27, 2019 at 11:15 AM Xiejingrong 
mailto:xiejingr...@huawei..com>> wrote:
Thanks for the RFC historical lessons.
--there was historically some assumption that next hop must be of the same AF 
as prefix.
--RFC 2858 says that Next Hop field should match AFI. On the other hand, RFC 
4760 says that Next Hop Field should match combination of AFI/SAFI.
--authors of RFC 4364 were trying to make it consistent with 4760.
--Also, drafts of RFC 4364 and RFC 4760 were being developed practically at the 
same time period.

The problem is clear, the nexthop field has been inconsistent between different 

[bess] Discussion on various NH encoding

[stephane.litkowski]

Hi WG,

(Speaking as co-chair)

The current discussion on the NH encodings in our AFI/SAFIs requires some 
particular attention.
We would like to take the opportunity of the next IETF to discuss the subject 
face to face.

In the meantime, we are looking for few volunteers who will:

-  Do an inventory of what do we have in our specifications: which 
AFI/SAFI, which NH encoding rules

-  Identify inconsistencies (if any) or assess if it hurts or not 
(theoretically)

-  What is implemented or is there some known implementation issues

-  Present and drive the discussion at next IETF

Based on this, we will see if there is something to do or not.
Timing is short before next IETF, however the more material we have, the better 
the discussion will be.

Who wants to help on this ?


Brgds,

Stephane & Matthew


_

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

Re: [bess] [Softwires] [Idr] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

[stephane.litkowski]

Hi Rajiv,

IMO, I don’t think that “Inferring it from AFI/SAFI per section 3 of RFC4760” 
means that there is a format match between the NH field and NLRI, it just says 
that there is a relation between the AFI/SAFI and the protocol layer of the NH.
When you know the AFI/SAFI, you can deduce the NH encoding based on the NH 
encoding rules defines for this particular AFI/SAFI. RFC4760 doesn’t say that 
there is an exact match between NLRI format and NH format.

“The Network Layer protocol associated with the Network Address of
 the Next Hop is identified by a combination of 
 carried in the attribute.”

Brgds,

Stephane

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Rajiv Asati (rajiva)
Sent: Thursday, June 27, 2019 13:37
To: Robert Raszuk
Cc: i...@ietf.org; Xiejingrong; Alexander Okonnikov; softwi...@ietf.org; 
bess@ietf.org; draft-dawra-bess-srv6-servi...@ietf.org
Subject: Re: [bess] [Softwires] [Idr] Regarding the Next Hop Network Address 
coding for IPv4 VPN over IPv6 Core in RFC5549


I agree and sometimes flexibility becomes an unwanted necessity (as is the case 
here with option (a)).

IMO, option (b) length based check for NH should be preferred, since it works 
for all AFI/SAFIs with an assumption that NH could be one IPv4 or IPv6 prefix. 
Very reasonable option.

Option (a) AFI/SAFI based interpretation doesn’t work for all AFI/SAFIs that 
don’t distribute non-routing information  e.g. policy, capabilities, LS etc.

Cheers,
Rajiv


On Jun 27, 2019, at 6:50 AM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
> Back to my suggestion: implementation should interpret nexthop RD+IPv4 and 
> nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the 
> same.

When elements of BGP UPDATE message are being parsed code must know what to 
expect. Note that we are dealing here with deployed SAFI 128 for nearly 20 
years.

So today there are two ways to know what format of next hop is in MP_REACH:

a) Inferring it from AFI/SAFI per section 3 of RFC4760

or (in addition to the above coarse assumption)

b) Inferring it from the discrete value of next hop length field as defined in 
section 3 of RFC5549

Note that if we would be defining new SAFI we can write anything we like to the 
rules of constructing the update message. But here again we are dealing with 
something which is deployed so sort of operating on the plane in flight.

If implementation can infer next hop type from length we are safe to define all 
sections to have next hop length = 16 octets and be done. But if there are some 
implementations which would only take AFI/SAFI to check if the next hop is 
correct or even further to check if the next hop length is correct then we have 
a problem.

/* Btw this notion of next hop length = 32 is bizarre ! I have never seen any 
BGP implementation sending two next hops (global IPv6 address followed by link 
local IPv6 address) not I am able to find any docs describing how any BGP stack 
would handle it. IMHO we should move this 32 next hop length to historic asap. 
*/

To the msg from Martin,

> maybe the WG would like to reach a conclusion on how to treat that erratum:
> http://www.rfc-editor.org/errata/eid5738

I would vote to reject the errata. There is no value of stuffing 8 octet of 
zeros in the next hop field. If the RFC got defined in 2012 that really means 
that most implementations are capable of inferring next hop format from the 
length field - which is very good. Accepting the errata would be a step 
backwords.

Thx,
R.

On Thu, Jun 27, 2019 at 11:15 AM Xiejingrong 
mailto:xiejingr...@huawei..com>> wrote:
Thanks for the RFC historical lessons.
--there was historically some assumption that next hop must be of the same AF 
as prefix.
--RFC 2858 says that Next Hop field should match AFI. On the other hand, RFC 
4760 says that Next Hop Field should match combination of AFI/SAFI.
--authors of RFC 4364 were trying to make it consistent with 4760.
--Also, drafts of RFC 4364 and RFC 4760 were being developed practically at the 
same time period.

The problem is clear, the nexthop field has been inconsistent between different 
L3VPN/MVPN scenarios and different implementations in the long history.

 is the latest draft, but it has different 
nexthop in section 3.1 to 3.4, in the year 2019.

Back to my suggestion: implementation should interpret nexthop RD+IPv4 and 
nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the same.

I think it may be helpful for  to add the 
above text, and update RFC4364/4659/4760/5549, to eliminate the worries about 
interoperation. is there any worries about interoperation ?

Thanks
Jingrong


From: Alexander Okonnikov 
[mailto:alexander.okonni...@gmail.com]
Sent: Wednesday, June 26, 2019 9:38 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: UTTARO, JAMES mailto:ju1...@att.com>>; Xiejingrong 
mailto:xiejingr...@huawei.com>>; 

Re: [bess] [Idr] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

[stephane.litkowski]

Hi Robert,

There are implementations which set two NHs, here is a capture:

Update Message (2), length: 150
  Multi-Protocol Reach NLRI (14), length: 100, Flags [O]:
AFI: IPv6 (2), SAFI: labeled VPN Unicast (128)
nexthop: RD: 0:0 (= 0.0.0.0), 2000::162RD: 0:0 (= 0.0.0.0), 
fe80::2a94:fff:fefa:3cc0, nh-length: 48, no SNPA
  RD: 10283:803700200 (= 47.231.125.232), 2000:bebe:37::/56, 
label:1313 (bottom)
  RD: 10283:803700200 (= 47.231.125.232), 2000:bebe:37::1/128, 
label:1314 (bottom)
  Origin (1), length: 1, Flags [T]: IGP
  AS Path (2), length: 6, Flags [T]: 1
  Extended Community (16), length: 8, Flags [OT]:
target (0x0002), Flags [none]: 1:00200 (= 59.153.68.40)

Note that this behavior caused some interop issues with another vendor who 
partially supported RFC4659.

Brgds,



From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, June 27, 2019 12:50
To: Xiejingrong
Cc: softwi...@ietf.org; draft-dawra-bess-srv6-servi...@ietf.org; bess@ietf.org; 
i...@ietf.org
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address 
coding for IPv4 VPN over IPv6 Core in RFC5549

> Back to my suggestion: implementation should interpret nexthop RD+IPv4 and 
> nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the 
> same.

When elements of BGP UPDATE message are being parsed code must know what to 
expect. Note that we are dealing here with deployed SAFI 128 for nearly 20 
years.

So today there are two ways to know what format of next hop is in MP_REACH:

a) Inferring it from AFI/SAFI per section 3 of RFC4760

or (in addition to the above coarse assumption)

b) Inferring it from the discrete value of next hop length field as defined in 
section 3 of RFC5549

Note that if we would be defining new SAFI we can write anything we like to the 
rules of constructing the update message. But here again we are dealing with 
something which is deployed so sort of operating on the plane in flight.

If implementation can infer next hop type from length we are safe to define all 
sections to have next hop length = 16 octets and be done. But if there are some 
implementations which would only take AFI/SAFI to check if the next hop is 
correct or even further to check if the next hop length is correct then we have 
a problem.

/* Btw this notion of next hop length = 32 is bizarre ! I have never seen any 
BGP implementation sending two next hops (global IPv6 address followed by link 
local IPv6 address) not I am able to find any docs describing how any BGP stack 
would handle it. IMHO we should move this 32 next hop length to historic asap. 
*/

To the msg from Martin,

> maybe the WG would like to reach a conclusion on how to treat that erratum:
> http://www.rfc-editor.org/errata/eid5738

I would vote to reject the errata. There is no value of stuffing 8 octet of 
zeros in the next hop field. If the RFC got defined in 2012 that really means 
that most implementations are capable of inferring next hop format from the 
length field - which is very good. Accepting the errata would be a step 
backwords.

Thx,
R.

On Thu, Jun 27, 2019 at 11:15 AM Xiejingrong 
mailto:xiejingr...@huawei..com>> wrote:
Thanks for the RFC historical lessons.
--there was historically some assumption that next hop must be of the same AF 
as prefix.
--RFC 2858 says that Next Hop field should match AFI. On the other hand, RFC 
4760 says that Next Hop Field should match combination of AFI/SAFI.
--authors of RFC 4364 were trying to make it consistent with 4760.
--Also, drafts of RFC 4364 and RFC 4760 were being developed practically at the 
same time period.

The problem is clear, the nexthop field has been inconsistent between different 
L3VPN/MVPN scenarios and different implementations in the long history.

 is the latest draft, but it has different 
nexthop in section 3.1 to 3.4, in the year 2019.

Back to my suggestion: implementation should interpret nexthop RD+IPv4 and 
nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the same.

I think it may be helpful for  to add the 
above text, and update RFC4364/4659/4760/5549, to eliminate the worries about 
interoperation. is there any worries about interoperation ?

Thanks
Jingrong


From: Alexander Okonnikov 
[mailto:alexander.okonni...@gmail.com]
Sent: Wednesday, June 26, 2019 9:38 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: UTTARO, JAMES mailto:ju1...@att.com>>; Xiejingrong 
mailto:xiejingr...@huawei.com>>; 
softwi...@ietf.org; 
i...@ietf.org; 
ian.far...@telekom.de; 
bess@ietf.org; ianfar...@gmx.com
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address 
coding for IPv4 VPN over IPv6 Core in RFC5549

Hi Robert,

Sorry, I was not 

[bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-igmp-mld-proxy

[stephane.litkowski]

Hello Working Group,



This email starts a three weeks Working Group Last Call on  
draft-ietf-bess-evpn-igmp-mld-proxy [1].



This poll runs until *the 28th of June*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



We have several IPRs already disclosed.



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 implementation as per [2].



Thank you,

Stephane & Matthew


[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy/

[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw



[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_

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

Re: [bess] Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06

[stephane.litkowski]

Hi,

I like this proposal.
I don't think we need to put a strong requirement on the originator to withdraw 
the route. This could be seen as optional OR we could say that each BGP speaker 
should validate the path of the SFPR, if the path is invalid, it becomes 
unusable (like an unreachable nexthop) and a withdraw will be automatically 
sent if there is no other best path available which is valid.



-Original Message-
From: John E Drake [mailto:jdr...@juniper.net] 
Sent: Thursday, June 06, 2019 15:04
To: LITKOWSKI Stephane OBS/OINIS; adr...@olddog.co.uk; 
draft-ietf-bess-nsh-bgp-control-pl...@ietf.org
Cc: bess@ietf.org
Subject: RE: Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06

Hi,

We can't time-out an attribute, we would have to time-out the SFPR w/ which it 
is associated.  However, I don't think we should do that.

Rather, I think what we should do is indicate that at any point in time an SFF 
selects its next hop from the intersection of the set of next hop RDs
contained in the SFPR and the RDs contained in its local set of SFIRs.  If the 
intersection is null the SFPR is unusable. 

Similarly, when this condition obtains the originator of the SFPR should either 
withdraw the SFPR or re-advertise it w/ a new set of RDs for the affected hop. 

As an aside, the use of Pool Identifier extended community effectively 
mitigates this issue. 

Yours Irrespectively,

John


Juniper Internal

> -Original Message-
> From: stephane.litkow...@orange.com 
> Sent: Thursday, June 6, 2019 7:45 AM
> To: adr...@olddog.co.uk; draft-ietf-bess-nsh-bgp-control-pl...@ietf.org
> Cc: bess@ietf.org
> Subject: RE: Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06
> 
> Hi Adrian,
> 
> I'm not comfortable with the time-out of controlplane informations.
> How do you handle a situation where there is an unknown SFIR-RD in a hop TLV
> for a valid reason (the SF is down for a while !), so you are timing out the 
> SFPR,
> and eventually the SF is restored and comes back online ? You should, in this
> case, readvertise the SFPR from the source. I think overloading could be
> managed as usual by limiting the number of routes that a device could import
> (per VRF context or globally). If there is unnecessary controlplane 
> information,
> that's the role of the operator to do the housekeeping, not the role of the
> protocol/implementation.
> 
> For the flowspec part, I'm fine, but we need to have the agreement from IDR
> guys who master the topic.
> 
> Brgds,
> 
> Stephane
> 
> 
> -Original Message-
> From: Adrian Farrel [mailto:adr...@olddog.co.uk]
> Sent: Thursday, May 30, 2019 15:45
> To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-bess-nsh-bgp-control-
> pl...@ietf.org
> Cc: bess@ietf.org
> Subject: RE: Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06
> 
> Hi Stephane,
> 
> Thanks again for the thoroughness of your review and the time it has taken to
> herd the necessary cats.
> 
> * BGP ERROR HANDLING:
>  I don’t see the “error handling” behavior associated with this
>  attribute (discard, treat-as-withdraw…)
> >>>
> >>> I think the errors are covered by section 6 of RFC 4271, but we need
> >>> to point to it.
> >>>
> >>> [SLI] You have added " Malformed SFP attributes, or those that in
> >>> error in some way, MUST be handled as described in Section 6 of
> [RFC4271]"
> >>> This is not enough ad RFC7606 allows for a more "graceful" process
> >>> of errors and it's up to each new attribute to have its own behavior
> >>> in term of error processing. RFC7606 has some guidelines.
> >>
> >> This one will take a little more time to work up some text.
> >> We'll get back to you.
> >>
> >> [SLI2] This is an important thing to address, and the IESG or Routing
> >> Directorate may catch that as well.
> >
> > OK, a chunk more text. Does this work for you?
> >
> >   Section 6 of [RFC4271] describes the handling of malformed BGP
> >   attributes, or those that are in error in some way.  [RFC7606]
> >   revises BGP error handling specifically for the for UPDATE message,
> >   provides guidelines for the authors of documents defining new
> >   attributes, and revises the error handling procedures for a number of
> >   existing attributes.  This document introduces the SFP attribute and
> >   so defines error handling as follows:
> >
> >   o  When parsing a message, an unknown Attribute Type code or a length
> >  that suggests that the attribute is longer than the remaining
> >  message is treated as a malformed message and the "treat-as-
> >  withdraw" approach used as per [RFC7606].
> >
> >   o  When parsing a message that contains an SFP attribute, the
> >  following cases constitute errors:
> >
> >  1.  Optional bit is set to 0 in SFP attribute.
> >
> >  2.  Transitive bit is set to 0 in SFP attribute.
> >
> >  3.  Unknown TLV type field found in SFP attribute.
> >
> >  4.  TLV length that suggests the TLV extends beyond the end of the
> >  

Re: [bess] Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06

[stephane.litkowski]

Hi Adrian,

I'm not comfortable with the time-out of controlplane informations.
How do you handle a situation where there is an unknown SFIR-RD in a hop TLV 
for a valid reason (the SF is down for a while !), so you are timing out the 
SFPR, and eventually the SF is restored and comes back online ? You should, in 
this case, readvertise the SFPR from the source. I think overloading could be 
managed as usual by limiting the number of routes that a device could import 
(per VRF context or globally). If there is unnecessary controlplane 
information, that's the role of the operator to do the housekeeping, not the 
role of the protocol/implementation.

For the flowspec part, I'm fine, but we need to have the agreement from IDR 
guys who master the topic.

Brgds,

Stephane


-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk] 
Sent: Thursday, May 30, 2019 15:45
To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-bess-nsh-bgp-control-pl...@ietf.org
Cc: bess@ietf.org
Subject: RE: Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06

Hi Stephane,

Thanks again for the thoroughness of your review and the time it has taken to 
herd the necessary cats.

* BGP ERROR HANDLING:
 I don’t see the “error handling” behavior associated with this attribute
 (discard, treat-as-withdraw…)
>>>
>>> I think the errors are covered by section 6 of RFC 4271, but we need to
>>> point to it.
>>>
>>> [SLI] You have added " Malformed SFP attributes, or those that in error in
>>> some way, MUST be handled as described in Section 6 of [RFC4271]"
>>> This is not enough ad RFC7606 allows for a more "graceful" process of 
>>> errors and it's up to each new attribute to have its own behavior in term
>>> of error processing. RFC7606 has some guidelines.
>>
>> This one will take a little more time to work up some text.
>> We'll get back to you.
>>
>> [SLI2] This is an important thing to address, and the IESG or Routing 
>> Directorate
>> may catch that as well.
>
> OK, a chunk more text. Does this work for you?
>
>   Section 6 of [RFC4271] describes the handling of malformed BGP
>   attributes, or those that are in error in some way.  [RFC7606]
>   revises BGP error handling specifically for the for UPDATE message,
>   provides guidelines for the authors of documents defining new
>   attributes, and revises the error handling procedures for a number of
>   existing attributes.  This document introduces the SFP attribute and
>   so defines error handling as follows:
>
>   o  When parsing a message, an unknown Attribute Type code or a length
>  that suggests that the attribute is longer than the remaining
>  message is treated as a malformed message and the "treat-as-
>  withdraw" approach used as per [RFC7606].
>
>   o  When parsing a message that contains an SFP attribute, the
>  following cases constitute errors:
>
>  1.  Optional bit is set to 0 in SFP attribute.
>
>  2.  Transitive bit is set to 0 in SFP attribute.
>
>  3.  Unknown TLV type field found in SFP attribute.
>
>  4.  TLV length that suggests the TLV extends beyond the end of the
>  SFP attribute.
>
>  5.  Association TLV contains an unknown SFPR-RD.
>
>[SLI] That's a bit weird to find this here as the Association TLV hasn't been 
>introduced.
> Wouldn't it be better to add a dedicated Error Handling section (e.g. 3.2.3) 
> after all the encodings ?

I think we introduced it in the text at the top of the page (i.e. a few 
paragraphs earlier). It reads OK to me and it is better to group together the 
format handling issues in one place and with the text that describes the 
presence rules.

>  6.  No Hop TLV found in the SFP attribute.
>
>  7.  No SFT TLV found in a Hop TLV.
>
> [SLI] That's strange, as section 3.2.1.3 says that the SFT TLV MAY be 
> included, so optional...

Ah, this should read "No sub-TLV found in a Hop TLV".
Per 3.2.1.2 "At least one sub-TLV MUST be present."

> 8.  Unknown SFIR-RD found in a Hop TLV.
>
>   o  The errors listed above are treated as follows:
>
>  1., 2., 6., 7.:  The attribute MUST be treated as malformed and
> the "treat-as-withdraw" approach used as per [RFC7606].
>
>  3.:  Unknown TLVs SHOULD be ignored, and message processing SHOULD
> continue.
>
>  4.:  Treated as a malformed message and the "treat-as-withdraw"
> approach used as per [RFC7606]
>
>  5., 8.:  The absence of an RD with which to corollate is nothing
> more than a soft error.  The receiver SHOULD store the
> information from the SFP attribute until a corresponding
> advertisement is received.  An implementation MAY time-out such
> stored SFP attributes to avoid becoming over-loaded.
>
> [SLI] That's not really an error, there may be a lot of transient situations
>  where some routes haven't been learned yet leading to such situation. 
> I don't think that we need to time-out (even optionally) as timing out may
> create 

Re: [bess] WG adoption poll and IPR poll for draft-boutros-bess-evpn-geneve

[stephane.litkowski]

Hi WG,

We are currently missing the IPR reply from Sam to clear the IPR poll.
In addition, we lack of significant support for this draft, however we haven't 
seen any objection yet.
We, chairs, think that this document is an important piece of work as GENEVE is 
the standard overlay from NVO3 WG.

I'm extending the poll for an additional week to hear about additional support 
but also objections to adopt the document.

The polls now ends on June 12th.

Brgds,

Stephane



From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Wednesday, May 22, 2019 15:55
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: WG adoption poll and IPR poll for draft-boutros-bess-evpn-geneve

Hi,


This email begins a two-week poll for adoption of 
draft-boutros-bess-evpn-geneve-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 5th June 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-boutros-bess-evpn-geneve/

_



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.

_

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

Re: [bess] WG adoption call & IPR poll for draft-jain-bess-evpn-lsp-ping

[stephane.litkowski]

Hi,

We have a good amount of support.
This draft is adopted as a WG document.

Authors,

Please republish the document with -ietf- v00.

Thanks,


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, May 07, 2019 09:37
To: bess@ietf.org
Subject: [bess] WG adoption call & IPR poll for draft-jain-bess-evpn-lsp-ping

Hi,


This email begins a two-week poll for adoption of 
draft-jain-bess-evpn-lsp-ping-08[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 21th May 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-jain-bess-evpn-lsp-ping/

_



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.

_

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

[bess] WG adoption call & IPR poll for draft-jain-bess-evpn-lsp-ping

[stephane.litkowski]

Hi,


This email begins a two-week poll for adoption of 
draft-jain-bess-evpn-lsp-ping-08[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 21th May 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-jain-bess-evpn-lsp-ping/

_

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

Re: [bess] Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06

[stephane.litkowski]

Hi Adrian,

Please find some comments inline.

Brgds


-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk] 
Sent: Wednesday, April 24, 2019 19:38
To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-bess-nsh-bgp-control-pl...@ietf.org
Cc: bess@ietf.org
Subject: RE: Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06


* BGP ERROR HANDLING:
>>> I don’t see the “error handling” behavior associated with this attribute
>>> (discard, treat-as-withdraw…)
>>
>> I think the errors are covered by section 6 of RFC 4271, but we need to
>> point to it.
>
> [SLI] You have added " Malformed SFP attributes, or those that in error in
> some way, MUST be handled as described in Section 6 of [RFC4271]"
> This is not enough ad RFC7606 allows for a more "graceful" process of 
> errors and it's up to each new attribute to have its own behavior in term
> of error processing. RFC7606 has some guidelines.
>
> This one will take a little more time to work up some text.
> We'll get back to you.
>
> [SLI2] This is an important thing to address, and the IESG or Routing 
> Directorate
> may catch that as well.

OK, a chunk more text. Does this work for you?

   Section 6 of [RFC4271] describes the handling of malformed BGP
   attributes, or those that are in error in some way.  [RFC7606]
   revises BGP error handling specifically for the for UPDATE message,
   provides guidelines for the authors of documents defining new
   attributes, and revises the error handling procedures for a number of
   existing attributes.  This document introduces the SFP attribute and
   so defines error handling as follows:

   o  When parsing a message, an unknown Attribute Type code or a length
  that suggests that the attribute is longer than the remaining
  message is treated as a malformed message and the "treat-as-
  withdraw" approach used as per [RFC7606].

   o  When parsing a message that contains an SFP attribute, the
  following cases constitute errors:

  1.  Optional bit is set to 0 in SFP attribute.

  2.  Transitive bit is set to 0 in SFP attribute.

  3.  Unknown TLV type field found in SFP attribute.

  4.  TLV length that suggests the TLV extends beyond the end of the
  SFP attribute.

  5.  Association TLV contains an unknown SFPR-RD.
[SLI] That's a bit weird to find this here as the Association TLV hasn't been 
introduced.
Wouldn't it be better to add a dedicated Error Handling section (e.g. 3.2.3) 
after all the encodings ?

  6.  No Hop TLV found in the SFP attribute.

  7.  No SFT TLV found in a Hop TLV.
[SLI] That's strange, as section 3.2.1.3 says that the SFT TLV MAY be included, 
so optional...

  8.  Unknown SFIR-RD found in a Hop TLV.

   o  The errors listed above are treated as follows:

  1., 2., 6., 7.:  The attribute MUST be treated as malformed and
 the "treat-as-withdraw" approach used as per [RFC7606].

  3.:  Unknown TLVs SHOULD be ignored, and message processing SHOULD
 continue.

  4.:  Treated as a malformed message and the "treat-as-withdraw"
 approach used as per [RFC7606]

  5., 8.:  The absence of an RD with which to corollate is nothing
 more than a soft error.  The receiver SHOULD store the
 information from the SFP attribute until a corresponding
 advertisement is received.  An implementation MAY time-out such
 stored SFP attributes to avoid becoming over-loaded.
[SLI] That's not really an error, there may be a lot of transient situations 
where some routes haven't been learned yet leading to such situation. I don't 
think that we need to time-out (even optionally) as timing out may create 
inconsistencies in the controlplane. What you could suggest is alarming to let 
the user know that something wrong is happening.


* FLOWSPEC traffic steering:
>>> NEW COMMENT:
>>> Section 5:
>>> "Note that each FlowSpec update MUST be tagged with the route target
>>>  of the overlay or VPN network for which it is intended."
>> [SLI] You should be more clear that VPN-IPv4 and VPN-IPv6 Flowspec
>> families must be used, it's not just a matter of RTs.
>
> A couple of the authors have discussed this a bit and we are puzzled.
>
> RFC 5575 section 8 discusses the applicability of Flowspecs to VPNs.
> https://www.iana.org/assignments/flow-spec/flow-spec.xhtml#flow-spec-2 
> does not list any VPN Flowspecs.
> draft-ietf-pce-pcep-flowspec makes observations about VPN identification
> and applicability to Flowspecs.
> draft-ietf-idr-flowspec-l2vpn has a redefinition of SAFI 134 to apply to 
> Flowspecs to an L2VPN environment.
>
> [SLI2] I see various cases:
> - traffic is coming from an IPVPNv4 and should be steered on an SFC, in such
>   a case RFC5575 Section 8 (AFI/SAFI 1/134) must be used, an RT is attached.
> - traffic is coming from the global routing table and should be steered on an
>   SFC, in such a case  the base RFC5575 using AFI/SAFI 1/133 must be used
>   and 

Re: [bess] Poll to progress draft-ietf-bess-nsh-bgp-controlplane without implementation

[stephane.litkowski]

Hi,

We have a good amount of support to progress the document with implementations.
We (chairs) are now waiting for the next I-D update to move forward.

Brgds,


From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Friday, April 05, 2019 19:55
To: LITKOWSKI Stephane OBS/OINIS; Sami Boutros
Cc: bess@ietf.org
Subject: Re: [bess] Poll to progress draft-ietf-bess-nsh-bgp-controlplane 
without implementation

yes/support

Cheers,
Jeff
On Apr 5, 2019, 10:53 AM -0700, Sami Boutros 
, wrote:


Support, Please progress the document.



Thanks,



Sami



Hi WG,



draft-ietf-bess-nsh-bgp-controlplane has passed WGLC and its finishing the 
shepherd's review phasis (I-D update required). It is in a good shape to 
progress further. However we are not aware of any implementation. As per our 
Implementation Requirement Policy, we need to poll the WG to know if WG agrees 
to progress the document without implementation.



This email starts a 2 weeks poll closing on 04/18/2019.



Please raise your support or any concern regarding the progress of this 
document without implementation.

If you are aware of any implementation, please also state it.





https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/



Brgds,



Stephane & Matthew

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

_

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

[bess] Poll to progress draft-ietf-bess-nsh-bgp-controlplane without implementation

[stephane.litkowski]

Hi WG,

draft-ietf-bess-nsh-bgp-controlplane has passed WGLC and its finishing the 
shepherd's review phasis (I-D update required). It is in a good shape to 
progress further. However we are not aware of any implementation. As per our 
Implementation Requirement Policy, we need to poll the WG to know if WG agrees 
to progress the document without implementation.

This email starts a 2 weeks poll closing on 04/18/2019.

Please raise your support or any concern regarding the progress of this 
document without implementation.
If you are aware of any implementation, please also state it.


https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/

Brgds,

Stephane & Matthew

_

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

[bess] Poll to continue or not the work on draft-ietf-bess-service-chaining

[stephane.litkowski]

Hi WG,

As pointed on the mailing list and during our session in Prague (IETF 104), the 
shepherd's review of draft-ietf-bess-service-chaining [1] has identified major 
issues that make the document far from being ready.

As the document is targeted to be standard track, the work to make it ready is 
quite huge and we, chairs, are wondering if the WG still supports this work.
The current proposal from the authors is to split the document: one 
informational, one standard track (containing the BGP extensions). The work 
remains huge. While we are happy to hear about this proposal, we need to ensure 
that the WG supports this proposal and will be kind to review/comment the new 
drafts.

This email starts a 2 weeks poll to determine if the work on this document 
should continue or if this document should be parked.
Please answer to this poll telling us if you want to support this document (you 
so commit on commenting and reviewing it) or if you don't support. In both 
cases, please explain why.
Authors should also commit on the roadmap for the document split/update.

The poll ends on Wed 17th April.

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-service-chaining/


Stephane & Matthew

_

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

Re: [bess] WG adoption and IPR poll for draft-malhotra-bess-evpn-irb-extended-mobility-04

[stephane.litkowski]

Hi WG,

We have now a good amount of support for this document.
It is adopted as a new WG item.

Authors,

Pls republish the document as draft-ietf-bess-evpn-irb-extended-mobility-00


Thanks

From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Wednesday, March 20, 2019 13:51
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org; 
draft-malhotra-bess-evpn-irb-extended-mobil...@ietf.org
Cc: bess-cha...@ietf.org
Subject: RE: WG adoption and IPR poll for 
draft-malhotra-bess-evpn-irb-extended-mobility-04

Hi WG,

Apart from the authors, we haven't received a lot of feedback for this draft 
(positive or negative).
I would like to expand the poll to an additional week (ends at 26th March) to 
see if we can get more support on the list.

Brgds,

From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Tuesday, March 05, 2019 09:43
To: bess@ietf.org; draft-malhotra-bess-evpn-irb-extended-mobil...@ietf.org
Cc: bess-cha...@ietf.org
Subject: WG adoption and IPR poll for 
draft-malhotra-bess-evpn-irb-extended-mobility-04

Hi,


This email begins a two-week poll for adoption of 
draft-malhotra-bess-evpn-irb-extended-mobility-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 19th March 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-malhotra-bess-evpn-irb-extended-mobility/



_



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.

_



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.

_

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 

Re: [bess] WG adoption and IPR poll for draft-malhotra-bess-evpn-irb-extended-mobility-04

[stephane.litkowski]

Hi WG,

Apart from the authors, we haven't received a lot of feedback for this draft 
(positive or negative).
I would like to expand the poll to an additional week (ends at 26th March) to 
see if we can get more support on the list.

Brgds,

From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Tuesday, March 05, 2019 09:43
To: bess@ietf.org; draft-malhotra-bess-evpn-irb-extended-mobil...@ietf.org
Cc: bess-cha...@ietf.org
Subject: WG adoption and IPR poll for 
draft-malhotra-bess-evpn-irb-extended-mobility-04

Hi,


This email begins a two-week poll for adoption of 
draft-malhotra-bess-evpn-irb-extended-mobility-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 19th March 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-malhotra-bess-evpn-irb-extended-mobility/



_



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.

_

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

Re: [bess] Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06

[stephane.litkowski]

Hi Adrian,

Thanks for the v09, we are now close to the end.
Here are the remaining points:

* NEXTHOP encoding:
>>> How is the nexthop encoded in the NLRI ?
>>
>> A bit confused about this question.
>
> [SLI] I'm talking about the nexthop field of the MP_REACH_NLRI attribute, 
> you must set a nexthop field even if it is not used for forwarding and you
> need to set how it is encoded.

Ah, that!
Yes, it's just a loopback address of the advertising SFF.
Added a paragraph for that.
[SLI2] Thanks for the new text, I'm just wondering if it is enough detailed or 
not, especially as IPv4 or IPv6 NH could be involved.
Looking at mvpn RFCs, they are using similar wording, so I suppose we could let 
it this way.



* BGP ERROR HANDLING:
>>> I don’t see the “error handling” behavior associated with this attribute
>>> (discard, treat-as-withdraw…)
>>
>> I think the errors are covered by section 6 of RFC 4271, but we need to
>> point to it.
>
> [SLI] You have added " Malformed SFP attributes, or those that in error in
> some way, MUST be handled as described in Section 6 of [RFC4271]"
> This is not enough ad RFC7606 allows for a more "graceful" process of 
> errors and it's up to each new attribute to have its own behavior in term
> of error processing. RFC7606 has some guidelines.

This one will take a little more time to work up some text.
We'll get back to you.

[SLI2] This is an important thing to address, and the IESG or Routing 
Directorate may catch that as well.


* FLOWSPEC traffic steering:

> NEW COMMENT:
> Section 5:
> "Note that each FlowSpec update MUST be tagged with the route target
>  of the overlay or VPN network for which it is intended."
> [SLI] You should be more clear that VPN-IPv4 and VPN-IPv6 Flowspec
> families must be used, it's not just a matter of RTs.

A couple of the authors have discussed this a bit and we are puzzled.

RFC 5575 section 8 discusses the applicability of Flowspecs to VPNs.
https://www.iana.org/assignments/flow-spec/flow-spec.xhtml#flow-spec-2 does not 
list any VPN Flowspecs.
draft-ietf-pce-pcep-flowspec makes observations about VPN identification and 
applicability to Flowspecs.
draft-ietf-idr-flowspec-l2vpn has a redefinition of SAFI 134 to apply to 
Flowspecs to an L2VPN environment.

[SLI2] I see various cases:
- traffic is coming from an IPVPNv4 and should be steered on an SFC, in such a 
case RFC5575 Section 8 (AFI/SAFI 1/134) must be used, an RT is attached.
- traffic is coming from the global routing table and should be steered on an 
SFC, in such a case  the base RFC5575 using AFI/SAFI 1/133 must be used and 
there is no RT attached. The trick here is that you need to set in the action: 
- the SFC you want the traffic to be steered on as well as the VPN to look the 
SFC for (Like a redirect RT + SFC steering). If there is no VPN redirection, 
the SFC is considered to be available in the global routing table.
- traffic is coming from an L2VPN, this is similar to the L3VPN case.
- same considerations applies to IPv6 and VPNv6.


Brgds,



-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk] 
Sent: Wednesday, March 06, 2019 16:06
To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-bess-nsh-bgp-control-pl...@ietf.org
Cc: bess@ietf.org
Subject: RE: Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06

Thanks again Stephane,

I think we have closure on most (but not all) of your points. I'll post another 
revision now because it makes the incremental changes easier to process. But we 
can have another go round if any of the unresolved issues merit it.

One thing to push back on from before was the use of "portal" or "gateway". We 
were using "portal" and you asked us to change to "gateway". I initially 
thought that would be OK, but on reflection we think that "gateway" has 
specific connotations in networking where it means an interworking function 
between two different protocols and this is most definitely not what is 
intended. So, because "portal" is a synonym, we prefer to go back to using that.

   Thus the SFF can be seen as a portal in the underlay network through
   which a particular SFI is reached.

Cheers,
Adrian

> New comment:
>
> " When the SFF receives the packet and the NSH back from the SFI it
>   MUST select the next SFI"
>
> [SLI] Even if I agree that this is the intended behavior, it is not the
> purpose of this document to set the dataplane behavior of NSH. I
> think keeping the "MUST" as lower case is fine.

Ah yes.
I got carried away.

>>> The Figure 1 is not really used in this section as part of the existing
>>> text. I would be better to have a companion text that explains the
>>> figure.
>>
>> Wow! Yes. That's embarrassing.
>
> [SLI] The provided text is good. Just few comments:
>
> - the figure wraps on two pages, I missed the SFa in the figure as it is
>   located on the other page. It would be great if you could make it fit
>   on one page.

Hmmm, yes.
I will make the figure small enough to fit on one page, but 

Re: [bess] WG adoption and IPR poll for draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02

[stephane.litkowski]

Hi WG,

We have now cleared the IPR poll.

The document is adopted as a WG item.

Authors,

Please republish the document as: draft-ietf-bess-evpn-ipvpn-interworking-00


Brgds,

Stephane


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, March 05, 2019 09:48
To: draft-rabadan-sajassi-bess-evpn-ipvpn-interwork...@ietf.org; bess@ietf.org; 
w...@juniper.net; erose...@gmail.com
Cc: bess-cha...@ietf.org
Subject: Re: [bess] WG adoption and IPR poll for 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02 => MISSING IPR replies

Hi,

The document has a good level of support, however I'm missing two IPR replies 
from Eric and Wen.


Eric, Wen,

Could you please reply to the IPR poll ?

Thanks,


From: stephane..litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Monday, February 18, 2019 16:53
To: draft-rabadan-sajassi-bess-evpn-ipvpn-interwork...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: WG adoption and IPR poll for 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02


This email begins a two-week poll for adoption of 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02
[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 4th March 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-rabadan-sajassi-bess-evpn-ipvpn-interworking/


_



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.

_



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.

_

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 

Re: [bess] Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06

[stephane.litkowski]

Hi Adrian,

Thanks for the updates. More comments inline.
I have trimmed the answers we have an agreement on and added some comments.

Brgds,


-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk] 
Sent: Friday, March 01, 2019 20:18
To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-bess-nsh-bgp-control-pl...@ietf.org
Cc: bess@ietf.org
Subject: RE: Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06
> Introduction:
> - When “classifier” is used as an example of SF, do you refer to the 
> classifier used to steer
>the traffic onto an SFC ? If yes, I don’t think it could be considered as 
> an SF.

Ah, no. Hmm. Tricky.
A SF could be responsible for classifying traffic into different buckets for 
different uses. This is a very similar function to an 'SFC Classifier' 
(responsible for classifying traffic onto different SFCs).
I can't think of a way to remove this confusion except by deleting this 
example. Instead, I have boosted the list of examples by borrowing from RFC 
7498.

[SLI] Ok, there was a confusion, I thought you were talking about the SFC 
Classifier rather than a more generic classifier.
The way the text is in the new version is fine for me.


New comment:

" When the SFF receives the packet and the NSH back from the SFI it
   MUST select the next SFI"

[SLI] Even if I agree that this is the intended behavior, it is not the purpose 
of this document to set the dataplane behavior of NSH. I think keeping the 
"MUST" as lower case is fine.




> “Service Function Type (SFT) that
   is the category of SF that is supported by an SFF”. 
>
> Don’t you mean SFI rather than SFF ?

Nope.
SFFs support attached SFIs.
An SFI is an instance of an SF.
An SF has a type that is its SFT.

[SLI] I agree with your statement.
That may be an "English issue" on my side. I attached "that is supported by an 
SFF" to the "SFT" and not to the "SF" when reading.


> The Figure 1 is not really used in this section as part of the existing text. 
> I 
> would be better to have a companion text that explains the figure.

Wow! Yes. That's embarrassing.

[SLI] The provided text is good. Just few comments:
- the figure wraps on two pages, I missed the SFa in the figure as it is 
located on the other page. It would be great if you could make it fit on one 
page.
- don't you need tunnels between SFF2 and SFF3 and between SFF1 and SFF4 (full 
mesh). I agree that tunnel may be established on demand if an SFC is using two 
SFFs, but here we don't have this information.
As the figure is already complex, adding tunnels may overload it. Maybe we 
could add a text telling that to simplify the figure only some tunnels between 
SFFs are represented.
- the example of SFC looks strange to me as SFd may be used twice in the chain 
why not using " SFa, an SF of type SFTx, and SFe" ?
- There is a sentence telling that the figure illustrates loadbalancing, 
however I think that the sentence " A number of SFPs can be constructed using 
any instance of SFb or using SFd." is not enough to describe the loadbalancing. 
Who is doing the loadbalancing ?


> I don’t like (personal opinion), the “grouping” of SFIs in the Figure 1 as 
> part of an SFT. 
> What strikes me is that it could be confused with the usual representation of 
> an SF 
> composed of multiple SFIs. Again that’s just a personal feeling.

Interesting. That confusion does sort of exist.

I don't think an SF is composed of multiple SFIs. 
An SF has a type: its SFT
The may be multiple instances of an SF, the SFIs, all of the same type.
And, of course, it is the SFIs that are attached to the SFF.
There may be multiple SFs of the same type. These are not necessarily to be 
indicated as SFIs. For example, two SFs of the same type may be accessed 
through different SFFs.

I think it might help if the text discussed this, but I don't think that it is 
right to make a hierarchy in the figure.

However, since we're here, the figure could be made a bit better along with the 
text to describe it.

[SLI] I agree, the figure looks good now.



> “The Service Function Type identifies a service function”. I don’t
> think we can really say that, it identifies the type of service the SF
> is providing but not the SF itself.

Yes

[SLI] The new text sounds strange.  Even if it is correct, it sounds as a 
repetition:
" The Service Function Type identifies a service function type".
Could we use something like : "The Service Function Type identifies the 
functions/features of service function can offer".


> “Each node hosting an SFI
>   must originate an SFIR for each type of SF that it hosts, and it may
>   advertise an SFIR for each instance of each type of SF.” 
>
> Is it really “and” ? I mean can we just summarize by using “Each 
> node hosting an SFI MUST originate an SFIR for each instance of
> each type of SF” ?

No. This makes a scaling optimization. If you don't need the creator of the SFP 
to know that there are 57 instances of an SF, you just advertise once for the 

Re: [bess] WG adoption and IPR poll for draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02 => MISSING IPR replies

[stephane.litkowski]

Hi,

The document has a good level of support, however I'm missing two IPR replies 
from Eric and Wen.


Eric, Wen,

Could you please reply to the IPR poll ?

Thanks,


From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Monday, February 18, 2019 16:53
To: draft-rabadan-sajassi-bess-evpn-ipvpn-interwork...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: WG adoption and IPR poll for 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02


This email begins a two-week poll for adoption of 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02
[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 4th March 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-rabadan-sajassi-bess-evpn-ipvpn-interworking/


_



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.

_

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

[bess] WG adoption and IPR poll for draft-malhotra-bess-evpn-irb-extended-mobility-04

[stephane.litkowski]

Hi,


This email begins a two-week poll for adoption of 
draft-malhotra-bess-evpn-irb-extended-mobility-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 19th March 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-malhotra-bess-evpn-irb-extended-mobility/



_

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

Re: [bess] Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06

[stephane.litkowski]

Agree

From: Andrew G. Malis [mailto:agma...@gmail.com]
Sent: Wednesday, February 27, 2019 15:21
To: LITKOWSKI Stephane OBS/OINIS
Cc: draft-ietf-bess-nsh-bgp-control-pl...@ietf.org; bess@ietf.org
Subject: Re: [bess] Shepherd's review of 
draft-ietf-bess-nsh-bgp-control-plane-06

Stephane,

Responding to one of your comments - making mpls-sfc-encaps a normative 
reference would be a downref, as it's an informational draft. That's OK as long 
as everyone is aware of it and it's documented in the IESG writeup, but that 
does have to happen. It may just be easier to keep it as an informative 
reference. As the document shepherd, it's your call at this point.

Cheers,
Andy


On Wed, Feb 27, 2019 at 5:22 AM 
mailto:stephane.litkow...@orange.com>> wrote:
Hi,

Here is my review of draft-ietf-bess-nsh-bgp-control-plane-06

General comment:

The document is globally well written with good examples that help the 
understanding. However it requires some refinements in the normative language 
used: some statement should be normative but are not using upper case words.


Detailed comments:

Abstract:

-  Please expand “BGP” on first use

-  Please give a reference associated to “Network Service Header”

Introduction:

-  When “classifier” is used as an example of SF, do you refer to the 
classifier used to steer the traffic onto an SFC ? If yes, I don’t think it 
could be considered as an SF.

-  I think the “conventional” approach described in the intro is really 
old school and even before SFC, we had some means, like dynamic routing 
protocols and other mechanisms like separate routing tables, to steer the 
traffic through a set of services. I agree that there is also some drawback 
associated with such approaches like the operational complexity of provisioning.

Section 1.2:
It would be good to give a definition for the additional terms that are defined 
in this document.

Section 2.1:



• As the section is focused on dataplane, it would be good to rename it 
as “Reminder on NSH dataplane” or something like that. It does not provide a 
functional overview of the controlplane which is what was expected based on the 
title.



• “A special Service Function, called a Classifier, is located at each
   ingress point to a service function overlay network.  It assigns the
   packets of a given packet flow to a specific Service Function Path.
“
Again, based on my understanding, the Classifier cannot really be considered as 
an SF , at least this is a component out of the SFC which steers the traffic 
onto an SFC.


• “An unknown or invalid SPI SHALL be treated as an error and the SFF

   MUST drop the packet.  Such errors SHOULD be logged, and such logs

   MUST be subject to rate limits.”



I found strange to have such statement in this document which is focused on the 
controlplane while this statement is a dataplane statement. Isn’t it part of 
RFC8300 Section 3 : “3.  Update the NSH: SFs MUST decrement the service index 
by one.  If

   an SFF receives a packet with an SPI and SI that do not

   correspond to a valid next hop in a valid SFP, that packet MUST

   be dropped by the SFF.”

The next paragraph deals also with normative dataplane statement which is IMO 
out of scope of this document.





Section 2.2

• “The SFIR describes a particular instance of a

  particular Service Function”. Would it be good to talk about “Service 
Function Instance” rather than instance of a Service Function ? That’s 
understandable, of course, however I think it’s good to reuse the exact 
terminology.

• I think the SFT definition is appearing a bit late in this section 
and in the document as it as been referenced already multiple times before.

• “Service Function Type (SFT) that

   is the category of SF that is supported by an SFF”. Don’t you mean SFI 
rather than SFF ?

• “Thus the SFF can be seen as a portal…”. Would “gateway” be more 
suitable rather than “portal” ?

• The Figure 1 is not really used in this section as part of the 
existing text. I would be better to have a companion text that explains the 
figure.

• I don’t like (personal opinion), the “grouping” of SFIs in the Figure 
1 as part of an SFT. What strikes me is that it could be confused with the 
usual representation of an SF composed of multiple SFIs. Again that’s just a 
personal feeling.



Section 3:

• “they must use BGP Capabilities”: is it a normative MUST ?



Section 3.1:

• s/a two byte Type field and a six byte/a two bytes Type field and a 
six bytes/

• “Two SFIs of the same SFT must be associated”. Is it a normative MUST 
? Same comment for next sentences in the paragraph (multiple occurences)

• “The Service Function Type identifies a service function”. I don’t 
think we can really say that, it identifies the type of service the SF is 
providing but not the SF itself.

• “Each node 

[bess] Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06

[stephane.litkowski]

Hi,

Here is my review of draft-ietf-bess-nsh-bgp-control-plane-06

General comment:

The document is globally well written with good examples that help the 
understanding. However it requires some refinements in the normative language 
used: some statement should be normative but are not using upper case words.


Detailed comments:

Abstract:

-  Please expand "BGP" on first use

-  Please give a reference associated to "Network Service Header"

Introduction:

-  When "classifier" is used as an example of SF, do you refer to the 
classifier used to steer the traffic onto an SFC ? If yes, I don't think it 
could be considered as an SF.

-  I think the "conventional" approach described in the intro is really 
old school and even before SFC, we had some means, like dynamic routing 
protocols and other mechanisms like separate routing tables, to steer the 
traffic through a set of services. I agree that there is also some drawback 
associated with such approaches like the operational complexity of provisioning.

Section 1.2:
It would be good to give a definition for the additional terms that are defined 
in this document.

Section 2.1:



· As the section is focused on dataplane, it would be good to rename it 
as "Reminder on NSH dataplane" or something like that. It does not provide a 
functional overview of the controlplane which is what was expected based on the 
title.



· "A special Service Function, called a Classifier, is located at each
   ingress point to a service function overlay network.  It assigns the
   packets of a given packet flow to a specific Service Function Path.
"
Again, based on my understanding, the Classifier cannot really be considered as 
an SF , at least this is a component out of the SFC which steers the traffic 
onto an SFC.


· "An unknown or invalid SPI SHALL be treated as an error and the SFF

   MUST drop the packet.  Such errors SHOULD be logged, and such logs

   MUST be subject to rate limits."



I found strange to have such statement in this document which is focused on the 
controlplane while this statement is a dataplane statement. Isn't it part of 
RFC8300 Section 3 : "3.  Update the NSH: SFs MUST decrement the service index 
by one.  If

   an SFF receives a packet with an SPI and SI that do not

   correspond to a valid next hop in a valid SFP, that packet MUST

   be dropped by the SFF."

The next paragraph deals also with normative dataplane statement which is IMO 
out of scope of this document.





Section 2.2

· "The SFIR describes a particular instance of a

  particular Service Function". Would it be good to talk about "Service 
Function Instance" rather than instance of a Service Function ? That's 
understandable, of course, however I think it's good to reuse the exact 
terminology.

· I think the SFT definition is appearing a bit late in this section 
and in the document as it as been referenced already multiple times before.

· "Service Function Type (SFT) that

   is the category of SF that is supported by an SFF". Don't you mean SFI 
rather than SFF ?

· "Thus the SFF can be seen as a portal...". Would "gateway" be more 
suitable rather than "portal" ?

· The Figure 1 is not really used in this section as part of the 
existing text. I would be better to have a companion text that explains the 
figure.

· I don't like (personal opinion), the "grouping" of SFIs in the Figure 
1 as part of an SFT. What strikes me is that it could be confused with the 
usual representation of an SF composed of multiple SFIs. Again that's just a 
personal feeling.



Section 3:

· "they must use BGP Capabilities": is it a normative MUST ?



Section 3.1:

· s/a two byte Type field and a six byte/a two bytes Type field and a 
six bytes/

· "Two SFIs of the same SFT must be associated". Is it a normative MUST 
? Same comment for next sentences in the paragraph (multiple occurences)

· "The Service Function Type identifies a service function". I don't 
think we can really say that, it identifies the type of service the SF is 
providing but not the SF itself.

· "Each node hosting an SFI

   must originate an SFIR for each type of SF that it hosts, and it may

   advertise an SFIR for each instance of each type of SF." Is it really "and" 
? I mean can we just summarize by using " Each node hosting an SFI MUST 
originate an SFIR for each instance of each type of SF" ?

· "A BGP Update containing one or more SFIRs will also include". Is it 
a MUST or SHOULD "also include"?

· How is the nexthop encoded in the NLRI ?

Section 3.1.1

· s/"It can be included"/"It MAY be included"/ ?

· That would be great to give more details about the usage of pools

· The encoding in Figure 4 is not matching the text. Figure 4 has 
Type=0x80, Sub-type=TBD6, text says type=TBD6 and subtype=0x00

· 

Re: [bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-06.txt

[stephane.litkowski]

Hi Adrian,

Yes it is ready, we will proceed with the shepherd's review. However, we don't 
have any sign of implementation or roadmap yet, we (chairs) will have to ask 
the WG to determine a consensus to progress the document without an 
implementation (as per our implementation policy).

In addition, I missing the IPR poll reply from: Jim, Eric, Stuart, Keyur, 
Avinash.

Brgds,


-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: Monday, February 25, 2019 18:39
To: bess@ietf.org
Subject: Re: [bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-06.txt

All,

Thanks for the comments we received during WG last call.

John and I have also re-reviewed the entire text.

We made a small number of little changes resulting from these activities.

Chairs: I think we are ready to move forward.

Best,
Adrian

-Original Message-
From: I-D-Announce  On Behalf Of
internet-dra...@ietf.org
Sent: 25 February 2019 17:20
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: I-D Action: draft-ietf-bess-nsh-bgp-control-plane-06.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   : BGP Control Plane for NSH SFC
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Jim Uttaro
  Luay Jalil
Filename: draft-ietf-bess-nsh-bgp-control-plane-06.txt
Pages   : 55
Date: 2019-02-25

Abstract:
   This document describes the use of BGP as a control plane for
   networks that support Service Function Chaining (SFC).  The document
   introduces a new BGP address family called the SFC AFI/SAFI with two
   route types.  One route type is originated by a node to advertise
   that it hosts a particular instance of a specified service function.
   This route type also provides "instructions" on how to send a packet
   to the hosting node in a way that indicates that the service function
   has to be applied to the packet.  The other route type is used by a
   Controller to advertise the paths of "chains" of service functions,
   and to give a unique designator to each such path so that they can be
   used in conjunction with the Network Service Header.

   This document adopts the SFC architecture described in RFC 7665.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-06
https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-
06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-nsh-bgp-control-plane-06


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/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

_

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

[bess] Shepherd's review of draft-ietf-bess-service-chaining-06

[stephane.litkowski]

Hi,

Here is my review of the document.

Main feeling:

I don't think that the document is ready to be published, especially as 
Standard Track is requested. The document clearly lacks of description of what 
should be implemented (what is optional, mandatory...) and some 
ambiguities/misinterpretation are possible. The description is fine for an 
informational RFC but not for a standard track document.

General comments:

The document uses "service chains" or "service function chains". Wouldn't it be 
good to have a single name used across the document ?

The document tells that a controller is not mandatory but always talks about 
the controller job. It should be clear that the document is focusing on a 
controller based approach as it does not provide a good view on how an 
implementation should work without a controller.

While being Standard Track, the document does not rely on the associated 
normative language.
The usual boilerplate template is missing.

Please make sure that all abbreviations are expanded on first use (VRF,VPN, 
XMPP...)

Please provide references for XMPP, Netconf, YANG.

It would be good to replace "NC" by "Netconf"

Try to avoid as much as possible references using "above" or "below" for 
sections and use clear reference pointers instead (just in case of paragraph 
reshuffling).


Section 1.1:

* Some of the definitions you are providing are already present in 
RFC7665 (like Network Service, Classification...).

* VRF definition is badly indented (it is within the Gateway definition)

Section 2.1:

"The forwarding table in the VRF in
   R-A will direct traffic destined for Network-B into an encapsulation
   tunnel with destination R-1 and a label that identifies the ingress
   (left) interface of SF1 that R-1 should send the packets out on.

* Does this mean that the label can't be a VRF assigned label, so when 
the label comes in, it causes an IP route lookup in the ingress VRF ?


* In the figure, it does not make sense to me for the SFC entry point 
to be on R-A. I agree that it works but this sounds more a waste of resource as 
you can attach directly Net-A to the Ingress VRF on R-1 which then acts as the 
SFC entry point.



"The controller is responsible for configuring the VRFs in each

   routing system, installing the routes in each of the VRFs to

   implement the SFC, and, in the case of virtualized services, may

   instantiate the service instances."

* In the text above, it would be good to add something telling who does 
what when a controller is not used.

Section 2.4:

"SF instances can be deployed as software running on physical

   appliances, or in virtual machines running on a hypervisor.

* In the text above, it would be good to enlarge the possibilities 
rather than limiting to PNF or VMs (for example, what about containers...). It 
would be good to have something generic and not limitative at the end. Giving 
example is fine but you should not limit to these.



A single SF instance can be part of multiple service chains.  In this

   case, the SF instance will have dedicated interfaces (typically

   logical) and forwarding contexts associated with each service chain.

* As this is a standard track document, IMO, you should use a word like 
"SHOULD" or "MUST" in the sentence above.

Section 2.5:
You are using words like "may", but should you use "MAY" instead ?

Section 2.6:

Additionally, in the second

   method, the controller also sends the route-policy containing the

   service chain logical topology to each routing system.
What do you mean by route policy here ?


Section 2.6.1:


Controller creates a VRF in each routing system that is connected

   to a service instance that will be used in the SFC
Using "a VRF" may be limiting, it could create one or multiple depending on the 
architecture of the chain.


Controller configures each VRF to contain the logical interface

   that connects to a SF instance.
Shouldn't it be "configures each logical interface, that connects to a SFI, to 
be attached in the appropriate VRF"


Controller implements route target import and export policies in

   the VRFs using the same route targets for the egress VRFs of a

   service function and the ingress VRFs of the next logically

   connected service function in the SFC.
This text is unclear, please state clearly if egress VRF and next logical 
ingress use the same RT as import and export. Or if egress VRF just imports the 
exported RT from the next logical ingress ?



In this section , you should use a normative language.



Section 2.6.2:

Using Figure 1 for reference, when the gateway R-B advertises a VPN

   route to Network-B
I have an issue with this sentence, it makes me think that R-B advertise a 
route to the B-side which is not the case. I think the sentence is correct but 
it could be misinterpreted. We are advertising the routes learned from Network 
B to the Service VPN.

[bess] WG adoption and IPR poll for draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02

[stephane.litkowski]

This email begins a two-week poll for adoption of 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02
[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 4th March 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-rabadan-sajassi-bess-evpn-ipvpn-interworking/


_

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

Re: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

[stephane.litkowski]

Hi WG,

The document has been updated to fulfil the comments raised by the WG.
The document is now ready to go to the next step.

Brgds,



From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Thursday, January 31, 2019 03:25
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org; 
draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org
Subject: Re: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05


Hi Stephane,

I have addressed all the comments from the people you mentioned in your email 
below as well as some additional comment received after WGLC ended. I will 
check in a new rev. shortly.

Cheers,
Ali

From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Monday, September 3, 2018 at 1:23 AM
To: "bess@ietf.org" , 
"draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" 

Subject: Re: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

The document has a good level of support to progress. However there are several 
comments raised that have not been answered yet.

Authors,

Could you please address the comments that have been raised on the list (from 
Acee, Krysztof, and Luc Andre) ?


Thanks,

Stephane


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Wednesday, August 08, 2018 16:04
To: bess@ietf.org
Subject: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05


Hello working group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-inter-subnet-forwarding-05 [1].



A significant amount of update has been introduced since the previous WGLC. 
Please review the updates and provide your feedback.



This poll runs until *the 22th of August*.





Thank you



Stéphane, Matthew

bess chairs



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



_



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.

_



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.

_

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 

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane

[stephane.litkowski]

Hi,

The WGLC has ended.
A new revision of the draft is required based on the discussions.

Authors,

Please publish the new revision, so we can proceed to the next step.

Brgds,


From: Andrew G. Malis [mailto:agma...@gmail.com]
Sent: Monday, January 28, 2019 15:37
To: John E Drake
Cc: Henderickx, Wim (Nokia - BE/Antwerp); LITKOWSKI Stephane OBS/OINIS; 
bess@ietf.org; bess-cha...@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-nsh-bgp-control-plane

John,

Thanks, much appreciated.

And for Stephane and Matthew, seeing as I just contributed some text, I'm not 
aware of any IPR associated with this draft.

Cheers,
Andy


On Mon, Jan 28, 2019 at 8:07 AM John E Drake 
mailto:jdr...@juniper.net>> wrote:
Andy,

We’ll add it to the next revision.  Thanks for your help.

Yours Irrespectively,

John

From: Andrew G. Malis mailto:agma...@gmail.com>>
Sent: Sunday, January 27, 2019 11:48 AM
To: John E Drake mailto:jdr...@juniper.net>>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) 
mailto:wim.henderi...@nokia.com>>; 
stephane.litkow...@orange.com; 
bess@ietf.org; 
bess-cha...@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-nsh-bgp-control-plane

John,

Thanks for confirming, that makes me very comfortable with the readability of 
your draft, seeing as I was able to get it right the first time. :-)

I'd like to request the addition of the following text (or similar, feel free 
to edit for readability and/or correctness), after which I'll be happy to 
support publication of the draft.


7.8 Support for MPLS-Encapsulated NSH Packets

[I-D.ietf-mpls-sfc-encapsulation] describes how to transport SFC packets using 
the NSH over an MPLS transport network. Signaling MPLS encapsulation of SFC 
packets using the NSH is also supported by this document by using the "BGP 
Tunnel Encapsulation Attribute Sub-TLV" with the codepoint 10 (representing 
"MPLS Label Stack") from the "BGP Tunnel Encapsulation Attribute Sub-TLVs" 
registry defined in [I-D.ietf-idr-tunnel-encaps], and also using the "SFP 
Traversal With MPLS Label Stack TLV" and the "SPI/SI Representation sub-TLV" 
with bit 0 set and bit 1 cleared.


BTW, draft-ietf-mpls-sfc-encapsulation has already been submitted to the IESG 
for publication, so adding the reference won't add any delay to this draft.

Thanks again,
Andy


On Sun, Jan 27, 2019 at 10:19 AM John E Drake 
mailto:jdr...@juniper.net>> wrote:
Andy,

That sounds right.

Yours Irrespectively,

John

From: Andrew G. Malis mailto:agma...@gmail.com>>
Sent: Friday, January 25, 2019 6:32 PM
To: John E Drake mailto:jdr...@juniper.net>>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) 
mailto:wim.henderi...@nokia.com>>; 
stephane.litkow...@orange.com; 
bess@ietf.org; 
bess-cha...@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-nsh-bgp-control-plane

John,

So, in order to support draft-ietf-mpls-sfc-encapsulation, looking at 
draft-ietf-idr-tunnel-encaps, you would use the value 10 from the "BGP Tunnel 
Encapsulation Attribute Sub-TLVs" registry, and also from your draft use the 
SFP Traversal With MPLS Label Stack TLV and the SPI/SI Representation sub-TLV 
with bit 0 set and bit 1 cleared? I just want to make sure I correctly read the 
details.

Thanks,
Andy

On Tue, Jan 22, 2019 at 1:15 PM John E Drake 
mailto:jdr...@juniper.net>> wrote:
Wim,

The subject draft was designed w/ NSH in mind.  We added an MPLS representation 
of the NSH later, which is the subject of the first draft you referenced, below.

The way the subject draft is written, the representation of the NSH  and the 
type of transport tunnel can change on a hop-by-hop basis at the discretion of 
the selected next-hop SFF.  This is through the use of the encapsulation 
attribute, which gives us a very open-ended framework in which to work.

I think the latter two drafts you referenced, below, are actually supported 
already but what needs to be written down is exactly what an SFF needs to 
advertise in the encapsulation attribute in order to support them.

I would be happy to work on this w/ anyone else who is interested.

Yours Irrespectively,

John

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Henderickx, Wim (Nokia - BE/Antwerp)
Sent: Tuesday, January 22, 2019 12:00 PM
To: stephane.litkow...@orange.com; 
bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-nsh-bgp-control-plane

I need to get into more details, but the current draft is written with 
draft-ietf-mpls-sfc-04 dataplane in mind. I believe that the draft can be 
useful with other dataplanes like: draft-ietf-mpls-sfc-encapsulation and 
draft-guichard-spring-nsh-s
So 

Re: [bess] Poll to progress draft-ietf-bess-evpn-bum-procedure-updates without implementation

[stephane.litkowski]

Hi WG,

We haven't received any concern about progressing this document without an 
implementation.
We will proceed accordingly.

Brgds,


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, January 22, 2019 07:19
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org
Subject: [bess] Poll to progress draft-ietf-bess-evpn-bum-procedure-updates 
without implementation

Hi,

We have now cleared the IPR poll for this draft and it is ready to progress.. 
We do not have implementations yet (some are in roadmap).
Based on our implementation policy, we should not progress the draft. However 
we have "draft-ietf-bess-evpn-optimized-ir" which has a normative reference to 
draft-ietf-bess-evpn-bum-procedure-updates. draft-ietf-bess-evpn-optimized-ir 
is already submitted to IESG.

We, chairs, would like to know if the WG agrees to progress 
draft-ietf-bess-evpn-bum-procedure-updates without an implementation to help 
the publication of draft-ietf-bess-evpn-optimized-ir.

Feel free to raise any concern.

This poll runs until January 28th.

Brgds,

Stephane



From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, January 08, 2019 14:29
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-bum-procedure-updates

Hi WG,

This poll is now ended but we are missing some replies for the IPR poll.
We also haven't heard about an implementation. If there is an implementation, 
please let us know.

We will move forward after clearing this.

Brgds,

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, December 17, 2018 13:50
To: bess@ietf.org
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-bum-procedure-updates


Hello Working Group,



This email starts a three weeks Working Group Last Call on  
draft-ietf-bess-evpn-bum-procedure-updates [1]. The poll period is longer than 
usual due to the coming vacation period.



This poll runs until *the 7th of January*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



There is currently no IPR disclosed.



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 implementation as per [2].



Thank you,

Stephane & Matthew



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


_



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.

_



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 

[bess] Poll to progress draft-ietf-bess-evpn-bum-procedure-updates without implementation

[stephane.litkowski]

Hi,

We have now cleared the IPR poll for this draft and it is ready to progress.. 
We do not have implementations yet (some are in roadmap).
Based on our implementation policy, we should not progress the draft. However 
we have "draft-ietf-bess-evpn-optimized-ir" which has a normative reference to 
draft-ietf-bess-evpn-bum-procedure-updates. draft-ietf-bess-evpn-optimized-ir 
is already submitted to IESG.

We, chairs, would like to know if the WG agrees to progress 
draft-ietf-bess-evpn-bum-procedure-updates without an implementation to help 
the publication of draft-ietf-bess-evpn-optimized-ir.

Feel free to raise any concern.

This poll runs until January 28th.

Brgds,

Stephane



From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, January 08, 2019 14:29
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-bum-procedure-updates

Hi WG,

This poll is now ended but we are missing some replies for the IPR poll.
We also haven't heard about an implementation. If there is an implementation, 
please let us know.

We will move forward after clearing this.

Brgds,

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, December 17, 2018 13:50
To: bess@ietf.org
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-bum-procedure-updates


Hello Working Group,



This email starts a three weeks Working Group Last Call on  
draft-ietf-bess-evpn-bum-procedure-updates [1]. The poll period is longer than 
usual due to the coming vacation period.



This poll runs until *the 7th of January*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



There is currently no IPR disclosed.



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 implementation as per [2].



Thank you,

Stephane & Matthew



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


_



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.

_



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.

_

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 

[bess] WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane

[stephane.litkowski]

Hello Working Group,



This email starts a three weeks Working Group Last Call on  
draft-ietf-bess-nsh-bgp-control-plane [1].



This poll runs until *the 4th of February*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



We have several IPRs already disclosed.



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 implementation as per [2].



Thank you,

Stephane & Matthew



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw



_

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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment

[stephane.litkowski]

Hi Ali, Tim

I agree almost agree with Ali. There was a 2 week WGLC to gather comments which 
is now ended. However, as the WGLC conclusion was that an I-D update was 
required, I have let time for additional updates, but we cannot continue 
forever.

From the last set of email, I think that there is still a misunderstanding 
point on question 5 from Tim. As I think it is also very good to encourage 
participation/discussion/education, it will be worth agreeing on this one 
before closing an moving forward.

Tim,

Next time, it would be great that you raise your comments during the WGLC or 
even before (the sooner, the better).



Thanks,


Stephane

From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Friday, January 11, 2019 20:50
To: Yu Tianpeng; jorge.raba...@alcatel-lucent.com
Cc: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-virtual-eth-segment

Hi Stephane,

The WGLC for this draft was ended on Dec/17. Yu sent his 1st batch of editorial 
comments about 3 weeks after WGLC ended on 1/7 and I addressed them. He then 
generated a new set which I addressed them as well. He has now generated the 
third set which are mostly invalid and indicative of lack of understanding of 
RFC 7623 which is prerequisite to this draft. I am rejected this third set not 
because he keeps generating new set but because of invalidity of them which I 
explain in the text below. I want to encourage participation of new incomers 
like Yu but they should also take time to understand both IETF procedures on WG 
calls and also on RFCs related to a draft before keep generating comments.

From: Yu Tianpeng 
Date: Thursday, January 10, 2019 at 10:29 AM
To: Cisco Employee , "jorge.raba...@alcatel-lucent.com" 

Cc: "stephane.litkow...@orange.com" , 
"bess@ietf.org" 
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-virtual-eth-segment


Thanks a lot Ali for the 03 version. This version fixs all comments raised 
before and also some others e.g. df election criteria.

But unfortuatelly I have more comments, sorry abount that...
Comment 5 is a major one, others are mainly wording and typo...
==

1. Related with 5.1 to 5.4, I suggest rename title as below:
5.1 Single vES Failure Handling in multi-homed EVPN
5.2 Single vES Failure Handling in multi-homed PBB-EVPN
5.3 Multiple vES Failure Handling in multi-homed EVPN
5.4 Multiple vES Failure Handling in multi-homed PBB-EVPN
Reasons:
1) procedure described should applies to multi-homed active-active, we should 
not say single-active, suggest use multi-homed instead
2) multiple vES failure can be caused by ENNI port/link failure, and EVC/PW 
failure (even failure of one EVC fails can lead to failure of multiple vES), 
but for EVPN, actually failure procedure are same.
Correspondingly some words in the content might need to be changed if we decide 
to change the title.

REJECTED: The current titles are correct. Please read RFC 7623. If you read it, 
you will see that All-Active multi-homing does NOT require MAC flushing !! The 
sections are about Single-Active vES and NOT single failure in vES.

2. 5.1 need changes from "CMAC" to "MAC". Probablly "Ethernet Segment" to "vES" 
also will be better.

REJECTED: The current text is correct. The first paragraph is about Ethernet 
Segment and not vES. The second paragraph is about vES and EVC !!

3. Some wording changes are needed in 5.1
[Before]
To be precise, there is no
MAC flush per-se if there is only one backup PE for a given ES -
i.e., only an update of the forwarding entries per backup-path
procedure in [RFC 7432].
[After]
To be precise, there is no per MAC basis flush, only an update of the 
forwarding entries and delete the failure vES in MAC nexthop table based on
procedure in the section 8.2 of [RFC 7432].

Or at least we need to fix "per-se", anyhow it seems to be a typo..

“per se” is and adverb.

4. Section 5.3
Router's MAC Extended Community is newly added in version-03. Before my 
understanding was I should always use type 3 ESI (Port MAC address + 
Discriminator) in EAD.
So the correct understanding should be: I can use any type of ESI in AD stage, 
and I need to include Router's MAC Extended Community with port MAC along with 
EAD, but type 3 has to be used in MASS-withdraw based on -03 version
Is my understanding correct?

REJECTED: We are talking about two different things. There is a vESI for vES 
and there is ESI for ES associated with ENNI. Bullet 1 in section 5.3 talks 
about when advertising vES you need to color them and the way to color them is 
to use Router’s MAC EC. vESI can be of any format. Bullet 2 talks about when 
withdrawing ES associated with the ENNI, then you advertise the withdraw 
message with this special ESI.

5. Still section 5.3
For this part I have a concern on the mechanism to be used in PW or when ENNI 
is a LAG.
When system terminate PWs and start EVPN, 

[bess] short WGLC for draft-ietf-bess-service-chaining

[stephane.litkowski]

Hi,

The draft-ietf-bess-service-chaining [1] document failed its WGLC with 
substantial comments received.
The document has been updated beginning of December and we would like to know 
if people are now happy with the content of the new version.

This email starts a poll of 1 week to gather additional comments or 
support/agreement.
This work is an old one and we should close it asap.

The poll runs until *** Friday 18th January 

Brgds,



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-service-chaining/



[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_

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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-bum-procedure-updates

[stephane.litkowski]

Hi WG,

This poll is now ended but we are missing some replies for the IPR poll.
We also haven't heard about an implementation. If there is an implementation, 
please let us know.

We will move forward after clearing this.

Brgds,

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, December 17, 2018 13:50
To: bess@ietf.org
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-bum-procedure-updates


Hello Working Group,



This email starts a three weeks Working Group Last Call on  
draft-ietf-bess-evpn-bum-procedure-updates [1]. The poll period is longer than 
usual due to the coming vacation period.



This poll runs until *the 7th of January*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



There is currently no IPR disclosed.



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 implementation as per [2].



Thank you,

Stephane & Matthew



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


_



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.

_

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

Re: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

[stephane.litkowski]

Hi,

This poll is closed now.
It seems that some discussions are required on the document, however it has 
been confirmed that nothing blocks the early allocation request.
I'm requesting the approval from our AD now.

Brgds,


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, December 11, 2018 16:10
To: bess@ietf.org
Subject: [bess] Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Hi WG,

We have received an early allocation request for the 
draft-ietf-bess-mvpn-evpn-aggregation-label.

Please raise your concerns if you object to this request and if you think that 
the document is not mature enough.
Feel also free to support this request.

We will wait until next Monday (12/17) to gather feedbacks.

Thanks,

Stephane



_



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.

_

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

[bess] BESS Wiki draft

[stephane.litkowski]

Hi WG,

I have started to build a Wiki page for the BESS WG which gives a detailed 
status of the working group work.
https://trac.ietf.org/trac/bess/wiki/WikiStart

It is still a draft and I would be pleased to welcome your feedback on it on 
the shape as well as the content.

The WG document status section is almost empty now, but will be enriched with 
the expected regular reports (next occurrence being mid-January) from the 
editors.


Brgds,

Stephane



_

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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment

[stephane.litkowski]

Hi,

The WGLC poll is now ended.
We have one comment from Mankamana that requires a reply from the authors.

We are also missing an IPR reply from Richard Schnell from Verizon.

We can't proceed before clearing these two points.

Brgds,

Stephane



From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, December 03, 2018 11:43
To: bess@ietf.org
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-virtual-eth-segment


Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-virtual-eth-segment [1]



This poll runs until *the 17th of December*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



There is currently no IPR disclosed.



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 implementation as per [2].



Thank you,

Stephane & Matthew



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-virtual-eth-segment/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw



_



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.

_

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.

--- Begin Message ---
Support.





But I would be happy to see some changes if WG / Author agree to it.



Nits:

1.  Please move abstract to the top. It would be easy for readers.
2.  It might be good to add a line to describe I-SID in terminology section






3.2.
 Scalability




   (R2a) A PE MUST handle thousands or tens of thousands of Single-homed
   vES's on a single physical port (e.g., single ENNI)


Comment: These section provides number “thousands or ten thousands”. As a 
standard document, I think we can avoid using some hard code numbers.

Would it be more appropriate to say “A PE MUST handle multiple Single-homed 
vES’s

on a single physical port (e.g., single ENNI)



   (R2b) A PE MUST handle hundreds of Single-Active vES's on a single
   physical port (e.g., single ENNI)
Comment: Same as above

   (R2c) A PE MAY handle tens or hundreds of All-Active Multi-Homed
   vES's on a single physical port (e.g., single ENNI)
Comment: Same as above






Thanks

Mankamana





From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Monday, December 3, 2018 at 2:43 AM
To: "bess@ietf.org" 
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-virtual-eth-segment



Hello Working Group,



This 

[bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-bum-procedure-updates

[stephane.litkowski]

Hello Working Group,



This email starts a three weeks Working Group Last Call on  
draft-ietf-bess-evpn-bum-procedure-updates [1]. The poll period is longer than 
usual due to the coming vacation period.



This poll runs until *the 7th of January*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



There is currently no IPR disclosed.



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 implementation as per [2].



Thank you,

Stephane & Matthew



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


_

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

Re: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

[stephane.litkowski]

Hi Jingrong,

Speaking as co-chair, what I need to know from this discussion is if there is a 
blocking point for the early allocation.
Yes, of course the draft will require some polishing, clarifications... as 
Jeffrey has mentioned, this is not a WGLC.

Based on your last sentence (and the overall discussion), I don't see any real 
blocking point but I want this to be crystal clear. So please state clearly if 
you object to the early allocation or not and why. What is important to me is 
to ensure that the encoding is stable and does not require any change.


Thanks,

Stephane



From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Xiejingrong
Sent: Thursday, December 13, 2018 03:24
To: Jeffrey (Zhaohui) Zhang; LITKOWSKI Stephane OBS/OINIS; bess@ietf.org
Subject: Re: [bess] Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label


s/inter-area/intra-area/g

From: Xiejingrong
Sent: Thursday, December 13, 2018 10:22 AM
To: 'Jeffrey (Zhaohui) Zhang' ; 
stephane.litkow...@orange.com; bess@ietf.org
Subject: RE: Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Hi Jeffrey,

Let me take the section 2.2.3 for explaination:

   In summary, labels can be allocated and advertised the following
   ways:

   1.  A central authority allocates per-VPN/BD/ES labels from the DCB.
   PEs advertise the labels with an indication that they are from
   the DCB.

   2.  A central authority allocates per-VPN/BD/ES labels from a few
   common context label spaces, and allocate labels from the DCB to
   identify those context label spaces.  PEs advertise the VPN/BD
   labels along with the context-identifying labels.

   3.  A central authority assigns disjoint label blocks from those a //
   few context label spaces to each PE, and allocate labels from the
   DCB to identify the context label spaces.  Each PE allocates
   labels from its assigned label block independently for its
   segmented S-PMSI, along with the context-identifying labels.

   Option 1 is simplest, but it requires that all the PEs set aside a
   common label block for the DCB that is large enough for all the
   VPNs/BDs/ESes combined.  Option 3 is needed only for segmented
   selective tunnels that are set up dynamically.  Multiple options
   could be used in any combination depending on the deployment
   situation.

Option-1 is simplest and I like it very much (anyone who don't like 
simplification?). For Inter-area EVPN deployment scenarios, it is strong and 
simple enough I think.
But when it is not the suitable case, and Option-2 has to be used, I think 
things are becoming complex: You still need a DCB from 'main/default' 
label-space, though this DCB is very small, which maybe only include ONE label. 
And then the ONE label is used as 'context-label'. While for BIER case, BIER 
header itself can act as a 'BIER-Context' naturally. Am I understanding 
correctly ?
For Option-3, I do understand it as two sub-options, Option-3a if there is 
enough number of Labels in the DCB, and Option-3b if there isn't and the ONE 
'DCB' label is used as context-label. Each one is difficult for me to consider 
the development and deployment. One the other hand, the segmented MVPN can use 
the 'UMH' mechanism to select the right upstream-assigned VpnLabel to download 
to forwarding states.

So my summarized comments:
DCB is similar to VNI very much, but the MPLS labels in the "main/default" 
space is very costly due to the 'per-platform' (RFC5331) allocation.
DCB is similar to SRGB very much, but DCB requires 'absolute' unique value 
other than the 'unique' index in SRGB(at least has such mechanism).
Use of context-label from a DCB can be comparable to the use of the 
'BIER-specific' context in case of BIER.
Use of 'dynamic' allocation with DCB mechanism in segmented MVPN deployment may 
add extra complexity.

I suggest this draft to make more clear what the use cases are, what it really 
want to solve, and what it don't.

Thanks.
Jingrong



From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
Sent: Wednesday, December 12, 2018 10:42 PM
To: Xiejingrong mailto:xiejingr...@huawei.com>>; 
stephane.litkow...@orange.com; 
bess@ietf.org
Subject: RE: Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Jingrong,

Please see zzh> below.

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Xiejingrong
Sent: Tuesday, December 11, 2018 8:14 PM
To: stephane.litkow...@orange.com; 
bess@ietf.org
Subject: Re: [bess] Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Objection.

Zzh> Please note that this is not a LC for the draft. This is the poll for 
early allocation for the DCB-flag and an extended community type.

I remember I have raised my concerns, but I didn't find the response.

Zzh> Sorry 

[bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

[stephane.litkowski]

Hi WG,

We have received an early allocation request for the 
draft-ietf-bess-mvpn-evpn-aggregation-label.

Please raise your concerns if you object to this request and if you think that 
the document is not mature enough.
Feel also free to support this request.

We will wait until next Monday (12/17) to gather feedbacks.

Thanks,

Stephane



_

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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[stephane.litkowski]

Hi WG,

The WGLC poll is over. Authors have now to address Jeffrey's comment before 
moving forward.

Brgds,


From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Thursday, November 22, 2018 08:54
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-mvpn-fast-failover


Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-mvpn-fast-failover-04  [1]



This poll runs until *the 6th of December*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



Currently two IPRs have been disclosed 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 implementation as per [2].



Thank you,

Stephane & Matthew



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw




_



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.

_

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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment

[stephane.litkowski]

Done, I have marked the –ietf- document replacing the individual one. The IPR 
is now inherited.

From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Tuesday, December 04, 2018 20:53
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-virtual-eth-segment

Hi Stephane,

It seems like the IPR that I was talking about has already been disclosed in 
April of this year. The disclosure is on 
draft-sajassi-bess-evpn-virtual-eth-segment-03.
 Since the history of its WG draft version doesn’t show the individual draft 
revisions, the IPR doesn’t appear for WG draft version. Can you fix it so that 
the history of the individual drafts appear on the WG draft history?

Regards,
Ali

From: BESS  on behalf of Cisco Employee 

Date: Monday, December 3, 2018 at 10:29 PM
To: "stephane.litkow...@orange.com" , 
"bess@ietf.org" 
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-virtual-eth-segment



There is one IPR related to this draft that I thought it was disclosed but it 
wasn’t. I put request  for it to be disclosed ASAP. The term for it is the same 
as any other Cisco IPR disclosure.
Regarding implementation, this draft has been implemented in Cisco products for 
quite some time.

Regards,
Ali

From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Monday, December 3, 2018 at 2:43 AM
To: "bess@ietf.org" 
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-virtual-eth-segment


Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-virtual-eth-segment [1]



This poll runs until *the 17th of December*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



There is currently no IPR disclosed.



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 implementation as per [2].



Thank you,

Stephane & Matthew



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-virtual-eth-segment/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw



_



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.

_

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

Re: [bess] Wg Adoption and IPR poll for draft-liu-bess-mvpn-yang-07

[stephane.litkowski]

I’m not aware of any IPR

From: Bocci, Matthew (Nokia - GB) [mailto:matthew.bo...@nokia.com]
Sent: Monday, December 03, 2018 15:53
To: bess@ietf.org
Cc: draft-liu-bess-mvpn-y...@ietf.org
Subject: Wg Adoption and IPR poll for draft-liu-bess-mvpn-yang-07

This email begins a two-week poll for adoption of 
draft-liu-bess-mvpn-yang-07.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.

This poll for adoption closes on Monday 17th December 2018.

Regards,
Matthew



_

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

[bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment

[stephane.litkowski]

Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-virtual-eth-segment [1]



This poll runs until *the 17th of December*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



There is currently no IPR disclosed.



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 implementation as per [2].



Thank you,

Stephane & Matthew



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-virtual-eth-segment/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw



_

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

Re: [bess] WG adoption poll for draft-zzhang-bess-mvpn-evpn-aggregation-label-01

[stephane.litkowski]

Hi,

We have now all the IPR replies.

Authors,

Please publish the document as draft-ietf-bess-mvpn-evpn-aggregation-label-00


Thanks !

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, November 13, 2018 13:17
To: bess@ietf.org; lizhen...@huawei.com; Wen Lin
Subject: Re: [bess] WG adoption poll for 
draft-zzhang-bess-mvpn-evpn-aggregation-label-01

We have a good level of support for this document.
The document is adopted as a WG document.

However we are missing IPR replies from: 
lizhen...@huawei.com and 
w...@juniper.net

We must clear this before proceeding.


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, October 30, 2018 09:22
To: bess@ietf.org
Subject: [bess] WG adoption poll for 
draft-zzhang-bess-mvpn-evpn-aggregation-label-01

Hi WG,

This email begins a two-week poll for BESS working group adoption 
draft-zzhang-bess-mvpn-evpn-aggregation-label-01 [1]

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

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.

The poll for working group adoption closes on Tue 13th November.

Regards,
Stéphane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-zzhang-bess-mvpn-evpn-aggregation-label/





[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



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.

_



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.

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre 

[bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

[stephane.litkowski]

Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-mvpn-fast-failover-04  [1]



This poll runs until *the 6th of December*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



Currently two IPRs have been disclosed 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 implementation as per [2].



Thank you,

Stephane & Matthew



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw




_

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

[bess] PLEASE LOOK: minor change to draft-ietf-bess-evpn-df-election-framework-05 => two weeks poll to get feedback

[stephane.litkowski]

Hi Ali,

Thanks a lot for your email.

Speaking as chair, could you please highlight to the working group the 
rationale of the change and associated use case ? Just to give the context…


To WG Folks,

Please review this change with care. There are two points that I would like to 
highlight:


-  We need to ensure that there is no current implementation using the 
value 255. Please raise your voice if you are aware of one.

-  The encoding of the mcast DF election algorithm could now be 
decorrelated from the base DF alg (applicable to Broadcast and Unknown 
traffic). The proposed encoding uses 3 bits for the mcast DF alg. We have to 
ensure that:

o   3 bits is enough

o   There will “never” (at least not mid term) be a requirement for variable 
parameters for mcast DF election (like in DF pref draft).

I will let some time to think about this change and raise your support or 
concerns.
The poll starts now and will end on Dec 5th.
This DF election framework will be an important component of EVPN and we need 
to ensure that we are providing the required level of flexibility to address 
the different use cases.

Thanks !


From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Wednesday, November 21, 2018 00:25
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: minor change to draft-ietf-bess-evpn-df-election-framework-05


Folks,

The authors of  the above draft are purposing a minor change to the draft and 
since the draft is currently under review by IESG, the chair has asked to send 
an email to the WG to solicit inputs and ensuring that there is no objection. 
The proposed change is as follow:

Currently, the above draft defines an eight-bit “DF Alg” field as shown in the 
following figure. The proposed change is to reduce the eight-bit field to a 
five-bit field.

*** OLD Text

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type=0x06 | Sub-Type(0x06)|   DF Alg  |Bitmap |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Bitmap|Reserved   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   o DF Alg (1 octet) - Encodes the DF Election algorithm values
 (between 0 and 255) that the advertising PE desires to use for the
 ES. This document requests IANA to set up a registry called "DF Alg
 Registry" and solicits the following values:

 - Type 0: Default DF Election algorithm, or modulus-based algorithm
   as in [RFC7432].

 - Type 1: HRW algorithm (explained in this document).

 - Types 2-254: Unassigned.

 - Type 255: Reserved for Experimental Use.

***NEW Text

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type=0x06 | Sub-Type(0x06)| RSV |  DF Alg  |Bitmap|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Bitmap|Reserved   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   o DF Alg (5 bits) - Encodes the DF Election algorithm values
 (between 0 and 31) that the advertising PE desires to use for the
 ES. This document requests IANA to set up a registry called "DF Alg
 Registry" and solicits the following values:

 - Type 0: Default DF Election algorithm, or modulus-based algorithm
   as in [RFC7432].

 - Type 1: HRW algorithm (explained in this document).

 - Types 2-30: Unassigned.

 - Type 31: Reserved for Experimental Use.


The remaining 3-bits of that octet (bits 16, 17, and 18 in the above figure) 
will be used by per-mcast-flow-df-election and will be expanded and described 
there and will be discussed in the next IETF as usual at the BESS WG session.

Regards,
Ali & other co-authors

_

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 

[bess] Setting up a regular WG document status update

[stephane.litkowski]

Hi WG,

In order to help the WG documents progressing faster in the WG, we have decided 
to request bi-monthly status update from editors of a WG document.
We would like to get these status report before each IETF but also in between 
two IETF meetings.

The status report should be sent at the following time:

* November: 2 weeks before the IETF meeting

* Mid-January

* March: 2 weeks before the IETF meeting

* Mid-May

* July: 2 weeks before the IETF meeting

* Mid-September

We do not expect a very long text. Just few lines telling:

* What is the current status

* What are the next steps and associated ETAs

* Is there a blocking point worth mentioning

Our goal is really to help document progressing faster and encouraging work in 
between IETF meetings.

Brgds,

Stephane & Matthew,



_

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

Re: [bess] WG adoption poll for draft-zzhang-bess-mvpn-evpn-aggregation-label-01

[stephane.litkowski]

We have a good level of support for this document.
The document is adopted as a WG document.

However we are missing IPR replies from: 
lizhen...@huawei.com and 
w...@juniper.net

We must clear this before proceeding.


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, October 30, 2018 09:22
To: bess@ietf.org
Subject: [bess] WG adoption poll for 
draft-zzhang-bess-mvpn-evpn-aggregation-label-01

Hi WG,

This email begins a two-week poll for BESS working group adoption 
draft-zzhang-bess-mvpn-evpn-aggregation-label-01 [1]

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

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.

The poll for working group adoption closes on Tue 13th November.

Regards,
Stéphane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-zzhang-bess-mvpn-evpn-aggregation-label/





[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



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.

_

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

[bess] WG adoption poll for draft-zzhang-bess-mvpn-evpn-aggregation-label-01

[stephane.litkowski]

Hi WG,

This email begins a two-week poll for BESS working group adoption 
draft-zzhang-bess-mvpn-evpn-aggregation-label-01 [1]

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

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.

The poll for working group adoption closes on Tue 13th November.

Regards,
Stéphane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-zzhang-bess-mvpn-evpn-aggregation-label/





[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_

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

Re: [bess] Comments on L3VPN yang

[stephane.litkowski]

I'm also wondering if the RPF should not sit in the MPLS module as it could be 
used for any types of labels advertised to a neighbor.

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, October 22, 2018 15:25
To: draft-ietf-bess-l3vpn-y...@ietf.org; bess@ietf.org
Subject: [bess] Comments on L3VPN yang

Hi Authors,

Please find some comments on the current model:

-  I don't understand the "advertise-as-vpn" leaf under global-imports, 
what is the use case ?

-  Same question for "bgp-valid-route" leaf

-  Why do you have a long list of protocols within the global-imports ? 
Isn't it the goal of the route-policy referenced earlier ? Moreover I do not 
think that it is a good idea to use the enum type here as protocol names ,when 
referring to, should not change across all routing configurations within a node.

-  Export to global may also require a policy to filter

-  Some description fields are just "."

-  How do you plan the tunnel policy to be used ?

-  Would be great to have RTs configurable for both IPv4/IPv6 without 
redefining the config for each address family.

-  While I think the "forwarding-mode" under interface is a good thing, 
it looks really a Cisco like config statement that other implementations do not 
have. Wouldn't it be better  to have a knob to enable mpls packet processing on 
an interface ; maybe in the MPLS yang model ?

-   What is the goal of the "route-policy" within 
"retain-route-targets" under the BGP peer AFI/SAFI ? I usually two use case 
(auto policy => import RTs are derived from VRF configuration, or keep all), 
what is the use case you want to address here ?

-  What is the "vpn-prefix-limit" within "retain-route-targets" under 
the BGP peer AFI/SAFI ? Is it a generic BGP prefix-limit ? If yes, we need to 
keep it generic within the BGP model.

-  IMO, the label mode should sit within the VRF and not at the BGP 
level. Each VRF may have a different flavor.

-  Why do you define bgp-label-mode and routing-table-limit for ipv4 
unicast and ipv6 unicast ? Does not seem to be L3VPN related..

-  For iBGP PE-CE, notion of independent domain with attr-set usage 
seems to miss in the model

-  Unequal cost path loadbalancing option is missing from the VRF config

-  Do we need a config statement to enable local import/export between 
local VRFs ?

-  I suppose that IGP/BGP configuration in VRF is inherited from core 
routing model.

-  Do you have to enrich routing policy model with ability to 
set/delete/match RTs, SoOs ?

-  Do we have to create/enrich RIB-in/RIB-out/Loc-RIB entries for BGP 
L3VPN prefixes ?

-  What about PIC Edge/PE-CE link protection configuration ?

-  Need notification for the route table limit alert

-  Do we have operational states with number of IPv4 and IPv6 routes 
within the instance ?

-  Do we have everything to support Carrier's of Carrier case ?


Brgds,

Stephane


_



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.

_

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 

Re: [bess] Encoding a 20 bit label in a 24 bit field.

[stephane.litkowski]

Hi,

Does anyone disagree with the additional Jakob's statement proposal ?
" The lower order 4 bits SHOULD be sent as 0 and ignored on receipt."

As an example, in MVPN for PMSI tunnel attribute, we have the following 
statement which does not tell anything about the lower order bits:
" If the MPLS Label field is non-zero, then it contains an MPLS label
   encoded as 3 octets, where the high-order 20 bits contain the label
   value.  Absence of an MPLS Label is indicated by setting the MPLS
   Label field to zero."


Brgds,


-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Tuesday, October 16, 2018 19:30
To: Jakob Heitz (jheitz); Zhuangshunwan; BESS
Subject: Re: [bess] Encoding a 20 bit label in a 24 bit field.


Yes, just the encoding of label value needs to be clear. 

Cheers,
Ali



On 10/15/18, 6:24 PM, "BESS on behalf of Jakob Heitz (jheitz)" 
 wrote:

How about:
The lower order 4 bits SHOULD be sent as 0 and ignored on receipt.

Regards,
Jakob.


-Original Message-
From: Zhuangshunwan  
Sent: Monday, October 15, 2018 6:02 PM
To: Jakob Heitz (jheitz) ; BESS 
Subject: RE: Encoding a 20 bit label in a 24 bit field.

It is good to make this explicit. This ambiguity has led to some 
unnecessary interworking problems.

Should we also need to explicitly define the "bottom of stack" bit in the 
low-order bit of the 3-octet label field?

Thanks,
Shunwan

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jakob Heitz (jheitz)
Sent: Tuesday, October 16, 2018 4:21 AM
To: BESS 
Subject: [bess] Encoding a 20 bit label in a 24 bit field.

We have proposed the following erratum for RFC 7432.

Opinions?

Regards,
Jakob.


-Original Message-
From: RFC Errata System 
Sent: Friday, October 12, 2018 12:37 PM
To: Ali Sajassi (sajassi) ; raggarw...@yahoo.com; 
nabil.n.bi...@verizon.com; aisaa...@bloomberg.net; utt...@att.com; 
jdr...@juniper.net; wim.henderi...@alcatel-lucent.com; db3...@att.com; 
aretana.i...@gmail.com; martin.vigour...@nokia.com; Giles Heron (giheron) 
; nabil.n.bi...@verizon.com
Cc: Krishnamoorthy Arumugham (karumugh) ; 
l2...@ietf.org; rfc-edi...@rfc-editor.org
Subject: [Technical Errata Reported] RFC7432 (5523)

The following errata report has been submitted for RFC7432, "BGP MPLS-Based 
Ethernet VPN".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5523

--
Type: Technical
Reported by: Krishnamoorthy Arumugham 

Section: 7

Original Text
-
Clarifications to following sub-sections:
Section 7.1
Section 7.2
Section 7.5


Corrected Text
--
Section 7.1:
Add below text to the section 7.1 regarding the encoding of MPLS label:

"The value of the 20-bit MPLS label is encoded in the high-order 20 bits of 
the 3 bytes MPLS Label field."

Section 7.2:
Add below text to the section 7.2 regarding the encoding of both the MPLS 
label fields:

"The value of the 20-bit MPLS label is encoded in the high-order 20 bits of 
the 3 bytes MPLS Label field for both MPLS Label1 and MPLS Label2."

Section 7.5:
Add below text to the section 7.5 regarding the encoding of ESI Label 
fields:

"The value of the 20-bit MPLS label is encoded in the high-order 20 bits of 
the ESI Label field."


Notes
-
MPLS label is a 20-bit value and is stored in a 3 bytes field in a packet. 
The 20-bit MPLS label value is generally stored in higher order 20 bits of the 
3 byte label field. The exact encoding to be followed for storing MPLS label 
values are not explicitly mentioned in the RFC 7432 under section 7.1, 7.2 and 
7.5 for different types of EVPN routes. This lead to ambiguity in different 
implementations. Hence a clarification is required.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC7432 (draft-ietf-l2vpn-evpn-11)
--
Title   : BGP MPLS-Based Ethernet VPN
Publication Date: February 2015
Author(s)   : A. Sajassi, Ed., R. Aggarwal, N. Bitar, A. Isaac, J. 
Uttaro, J. Drake, W. Henderickx
Category: PROPOSED STANDARD
Source  : Layer 2 Virtual Private Networks
Area: Routing
Stream  : IETF
Verifying Party : IESG

[bess] Comments on L3VPN yang

[stephane.litkowski]

Hi Authors,

Please find some comments on the current model:

-  I don't understand the "advertise-as-vpn" leaf under global-imports, 
what is the use case ?

-  Same question for "bgp-valid-route" leaf

-  Why do you have a long list of protocols within the global-imports ? 
Isn't it the goal of the route-policy referenced earlier ? Moreover I do not 
think that it is a good idea to use the enum type here as protocol names ,when 
referring to, should not change across all routing configurations within a node.

-  Export to global may also require a policy to filter

-  Some description fields are just "."

-  How do you plan the tunnel policy to be used ?

-  Would be great to have RTs configurable for both IPv4/IPv6 without 
redefining the config for each address family.

-  While I think the "forwarding-mode" under interface is a good thing, 
it looks really a Cisco like config statement that other implementations do not 
have. Wouldn't it be better  to have a knob to enable mpls packet processing on 
an interface ; maybe in the MPLS yang model ?

-   What is the goal of the "route-policy" within 
"retain-route-targets" under the BGP peer AFI/SAFI ? I usually two use case 
(auto policy => import RTs are derived from VRF configuration, or keep all), 
what is the use case you want to address here ?

-  What is the "vpn-prefix-limit" within "retain-route-targets" under 
the BGP peer AFI/SAFI ? Is it a generic BGP prefix-limit ? If yes, we need to 
keep it generic within the BGP model.

-  IMO, the label mode should sit within the VRF and not at the BGP 
level. Each VRF may have a different flavor.

-  Why do you define bgp-label-mode and routing-table-limit for ipv4 
unicast and ipv6 unicast ? Does not seem to be L3VPN related.

-  For iBGP PE-CE, notion of independent domain with attr-set usage 
seems to miss in the model

-  Unequal cost path loadbalancing option is missing from the VRF config

-  Do we need a config statement to enable local import/export between 
local VRFs ?

-  I suppose that IGP/BGP configuration in VRF is inherited from core 
routing model.

-  Do you have to enrich routing policy model with ability to 
set/delete/match RTs, SoOs ?

-  Do we have to create/enrich RIB-in/RIB-out/Loc-RIB entries for BGP 
L3VPN prefixes ?

-  What about PIC Edge/PE-CE link protection configuration ?

-  Need notification for the route table limit alert

-  Do we have operational states with number of IPv4 and IPv6 routes 
within the instance ?

-  Do we have everything to support Carrier's of Carrier case ?


Brgds,

Stephane


_

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

[bess] LxVPN and EVPN yang models

[stephane.litkowski]

Hi Authors,


Speaking as individual, after reading the last versions of your module, I still 
have several concerns about the consistency of the modeling across all models.
There are common components between all the models that could be shared or at 
least modeled in the same way:

-  Model name: L3VPN uses ietf-bgp-l3vpn while others use ietf-evpn or 
ietf-l2vpn

-  Route-target import/export and route-distinguisher:

o   Under bgp-parameters/common/rd-rt/ for EVPN

o   Under bgp-auto-discovery for L2VPN (that could make sense here but it is 
weird in term of config consistency => maybe better to have a 
bgp-auto-discovery Boolean or maybe the discovery-type is enough to know that 
bgp-auto-discovery is used ?)

o   Under ipv4 or ipv6 for l3vpn RTs but rd is at top level. That could make 
sense but again the configuration is slightly different from other AFI/SAFIs. 
Having different imp/exp for IPv4 and IPv6 is a valid use case, but you should 
also allow to have the same config for both without defining per AFI/SAFI 
config.

-  RIB route limits could also be modeled the same way

-  Modelization of route entries in the RIB could be modeled in the 
same way across model

-  Attachment to the NI:

o   I don't understand how EVPN is integrated in L2VPN. It seems that you add a 
pointer (reference) to an EVPN instance which is in a completely different 
tree. That looks really strange and make EVPN instance configuration completely 
different from an L3VPN instance or L2VPN instance. Do you plan to reuse the 
config parameters from L2VPN or do you prefer creating a completely different 
tree ? If you prefer a completely different tree why not creating an EVPN 
ni-type ?


Can't we have one model defining some bgp-vpn containers possibly as a separate 
module that could be reused across all models ?

Happy to hear your feedback.

Brgds,

Stephane


_

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

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

Re: [bess] WG adoption poll for draft-malhotra-bess-evpn-unequal-lb-04

[stephane.litkowski]

Hi,

We have a good level of support for this document.
It is adopted as a WG doc.

Authors,

Please republish the document as  draft-ietf-bess-evpn-unequal-lb-00

Brgds,


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, September 04, 2018 09:29
To: bess@ietf.org
Subject: [bess] WG adoption poll for draft-malhotra-bess-evpn-unequal-lb-04

Hi WG,

This email begins a two-week poll for BESS working group adoption 
draft-malhotra-bess-evpn-unequal-lb-04 [1]

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

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.

The poll for working group adoption closes on Tue 18th September.

Regards,
Stéphane and Matthew

[1] https://datatracker.ietf.org/doc/draft-malhotra-bess-evpn-unequal-lb/






_



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.

_

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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-service-chaining

[stephane.litkowski]

Hi WG,

This WGLC pointed that some discussions are still required on this document and 
some old comments have not been addressed yet.


Authors,

Please address the comments before we can proceed with this document.

Brgds,


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, September 03, 2018 10:30
To: bess@ietf.org
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-service-chaining


Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-service-chaining-05 [1]



This poll runs until *the 17th of September*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



Currently two IPRs have been disclosed 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 implementation as per [2].



Thank you,

Stephane & Matthew



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-service-chaining/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw




[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



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.

_

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

[bess] WGLC, IPR and implementation poll for draft-ietf-bess-service-chaining

[stephane.litkowski]

Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-service-chaining-05 [1]



This poll runs until *the 17th of September*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



Currently two IPRs have been disclosed 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 implementation as per [2].



Thank you,

Stephane & Matthew



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-service-chaining/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw




[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_

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

Re: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

[stephane.litkowski]

The document has a good level of support to progress. However there are several 
comments raised that have not been answered yet.

Authors,

Could you please address the comments that have been raised on the list (from 
Acee, Krysztof, and Luc Andre) ?


Thanks,

Stephane


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Wednesday, August 08, 2018 16:04
To: bess@ietf.org
Subject: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05


Hello working group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-inter-subnet-forwarding-05 [1].



A significant amount of update has been introduced since the previous WGLC. 
Please review the updates and provide your feedback.



This poll runs until *the 22th of August*.





Thank you



Stéphane, Matthew

bess chairs



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



_



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.

_

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.

--- Begin Message ---
Support.


This is an important draft and is implemented;


​


​(1) I echo Acee's comment re: "Router MAC" for readability





(2) The document often refers to two Route-targets (MAC-VRF & IP-VRF) which is 
overly restrictive.


I would propose language more to the effect of MAC/IP must be advertised with 
two sets of RTs




RFC7432:  EVPN route MAY carry one or more Route Target (RT) attributes.​

vs. for example:

   This route MUST be advertised with two route targets - one
   corresponding to the MAC-VRF of the tenant's subnet and another
   corresponding to the tenant's IP-VRF.


Thanks,

Luc André​ Burdet





  _

From: BESS  on behalf of stephane.litkow...@orange.com 

Sent: August 8, 2018 10:03 AM
To: bess@ietf.org
Subject: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05


Hello working group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-inter-subnet-forwarding-05 [1].



A significant amount of update has been introduced since the previous WGLC. 
Please review the updates and provide your feedback.



This poll runs until *the 22th of August*.





Thank you



Stéphane, Matthew

bess chairs



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



_

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 

Re: [bess] WG adoption poll and IPR poll for draft-sajassi-bess-evpn-per-mcast-flow-df-election

[stephane.litkowski]

Hi,

The document has a good level of support and is adopted as a WG document.

Authors, please republish the document as  
draft-ietf-bess-evpn-per-mcast-flow-df-election-00.

Thanks,


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Wednesday, August 08, 2018 15:38
To: bess@ietf.org
Subject: [bess] WG adoption poll and IPR poll for 
draft-sajassi-bess-evpn-per-mcast-flow-df-election

Hi WG,

This email begins a two-week poll for BESS working group adoption of 
draft-sajassi-bess-evpn-per-mcast-flow-df-election-01 [1]

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

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.

The poll for working group adoption closes on Wed 22th Aug.

Regards,
Stéphane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-per-mcast-flow-df-election/




_



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.

_

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

[bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

[stephane.litkowski]

Hello working group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-inter-subnet-forwarding-05 [1].



A significant amount of update has been introduced since the previous WGLC. 
Please review the updates and provide your feedback.



This poll runs until *the 22th of August*.





Thank you



Stéphane, Matthew

bess chairs



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



_

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

[bess] WG adoption poll and IPR poll for draft-sajassi-bess-evpn-per-mcast-flow-df-election

[stephane.litkowski]

Hi WG,

This email begins a two-week poll for BESS working group adoption of 
draft-sajassi-bess-evpn-per-mcast-flow-df-election-01 [1]

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

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.

The poll for working group adoption closes on Wed 22th Aug.

Regards,
Stéphane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-per-mcast-flow-df-election/




_

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

[bess] Full agenda for IETF 102

[stephane.litkowski]

Hi WG,

Based the slot requests that we have received, our 2h slot is already full and 
we may have to shrink one or two requested slots to ensure that we have to time 
to address all the topics.
If you have requested a slot and if you are able to shrink your slot request, 
please advise us. Otherwise, we will have to arbitrate between the requests to 
ensure the timing of our session.

Thanks in advance.

Best regards,

Stephane


_

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

Re: [bess] New Version Notification for draft-rosen-bess-secure-l3vpn-00.txt

[stephane.litkowski]

Hi Ron,

I have read quickly the document.
I think the use case of having secure L3VPNs is valid and we already have all 
(or most of) the technology building blocks to do it.
Now the draft takes a complete upside down approach comparing to our well known 
L3VPNs which are provider provisioned VPNs as you propose to build them at the 
CE side.
This could be a valid approach but isn't it a niche use case ?

Customer sites connected over the Internet is for sure a use case to handle, 
and we already to it today by establishing an IPSec tunnel towards an SP-PE, 
the tunnel ends in the customer VRF.
Customer data must not be exposed: also a valid use case. We have some 
customers doing IPSec transport within MPLS VPN for some specific traffic. On 
the other hand, from an SP point of view, when core links are not fully 
trusted, MACSEC or IPSec are also options.

I'm less convinced by the routing that should not be exposed. I agree that this 
is a possibility and a valid use case but I do not think that this is a big 
deal for most of customers (even those requiring more security). The good thing 
of MPLS VPN is the routing complexity is almost pushed to the SP and the 
customer has few things to do and they are happy with that.

The last case of the multitenancy on the customer side is also valid, but I 
also think that it is a niche use case. 

My point is that the draft is currently focusing on one scenario which in my 
opinion addresses a niche use case while there may be intermediate scenarios 
(like no multitenancy and/or no need of routing protection) that could be more 
widely applicable.

Brgds,
 
Stephane


-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Ron Bonica
Sent: Monday, June 11, 2018 21:56
To: bess@ietf.org
Subject: [bess] FW: New Version Notification for 
draft-rosen-bess-secure-l3vpn-00.txt

Folks,

Please review and comment on this draft.

  Ron


-Original Message-
From: internet-dra...@ietf.org  
Sent: Monday, June 11, 2018 3:49 PM
To: Ron Bonica ; Eric Rosen ; Eric 
Rosen 
Subject: New Version Notification for draft-rosen-bess-secure-l3vpn-00.txt


A new version of I-D, draft-rosen-bess-secure-l3vpn-00.txt
has been successfully submitted by Eric C. Rosen and posted to the IETF 
repository.

Name:   draft-rosen-bess-secure-l3vpn
Revision:   00
Title:  Augmenting RFC 4364 Technology to Provide Secure Layer L3VPNs 
over Public Infrastructure
Document date:  2018-06-11
Group:  Individual Submission
Pages:  19
URL: https://tools.ietf.org/html/draft-rosen-bess-secure-l3vpn-00   
Status: https://datatracker.ietf.org/doc/draft-rosen-bess-secure-l3vpn/
Htmlized:  https://tools.ietf.org/html/draft-rosen-bess-secure-l3vpn-00 
Htmlized:  https://datatracker.ietf.org/doc/html/draft-rosen-bess-secure-l3vpn  
   


Abstract:
   The Layer 3 Virtual Private Network (VPN) technology described in RFC
   4364 is focused on the scenario in which a network Service Provider
   (SP) maintains a secure backbone network and offers VPN service over
   that network to its customers.  Customers access the SP's network by
   attaching "Customer Edge" (CE) routers to "Provider Edge" (PE)
   routers, and exchanging cleartext IP packets.  PE routers generally
   serve multiple customers, and prevent unauthorized communication
   among customers.  Customer data sent across the backbone (from one PE
   to another) is encapsulated in MPLS, using an MPLS label to associate
   a given packet with a given customer.  The labeled packets are then
   sent across the backbone network in the clear, using MPLS transport.
   However, many customers want a VPN service that is secure enough to
   run over the public Internet, and which does not require them to send
   cleartext IP packets to a service provider.  Often they want to
   connect directly to edge nodes of the public Internet, which does not
   provide MPLS support.  Each customer may itself have multiple tenants
   who are not allowed to intercommunicate with each other freely.  In
   this case, the customer many need to provide a VPN service for the
   tenants.  This document describes a way in which this can be achieved
   using the technology of RFC 4364.  The functionality assigned therein
   to a PE router can be placed instead in Customer Premises Equipment.
   This functionality can be augmented by transmitting MPLS packets
   through IPsec Security Associations.  The BGP control plane sessions
   can also be protected by IPsec.  This allows a customer to use RFC
   4364 technology to provide VPN service to its internal departments,
   while sending only IPsec-protected packets to the Internet or other
   backbone network, and eliminating the need for MPLS transport in the
   backbone.


  


Please note that it may take a couple of minutes from the 

Re: [bess] WG adoption and IPR poll for draft-sajassi-bess-evpn-fast-df-recovery-02

[stephane.litkowski]

Hi WG,

The document has a significant amount of support and we have closed the IPR 
poll.
The document is adopted by the WG.

Authors,

Please republish the document as draft-ietf-bess-evpn-fast-recovery-00.

Thanks !


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, May 14, 2018 11:48
To: bess@ietf.org
Subject: [bess] WG adoption and IPR poll for 
draft-sajassi-bess-evpn-fast-df-recovery-02

Hi WG,

This email begins a two-week poll for BESS working group adoption of 
draft-sajassi-bess-evpn-fast-df-recovery-02 [1].

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

If you are 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.

The poll for working group adoption closes on Monday 28th May.

Regards,
Stéphane and Matthew

[1] https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-fast-df-recovery/



[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



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.

_

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

Re: [bess] Shepherd's review of draft-ietf-bess-df-election-framework

[stephane.litkowski]

Ok thanks a lot for all the edits. The text is really good now.

Let me know when the next revision is ready, I will then push the button to 
send it to IESG.

Brgds,


From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com]
Sent: Thursday, May 24, 2018 14:15
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org; 
draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org
Subject: Re: Shepherd's review of draft-ietf-bess-df-election-framework

Thank you Stephane. We’ll fix it for the next version.

Jorge

From: "stephane.litkow...@orange.com" 
Date: Thursday, May 24, 2018 at 2:03 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" , 
"bess@ietf.org" , 
"draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org" 

Subject: RE: Shepherd's review of draft-ietf-bess-df-election-framework

One small comment:

“this document
   elects a DF per . This means that unlike [RFC 
7432],”

s/RFC 7432/RFC7432/

This creates a Nits


From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com]
Sent: Wednesday, May 23, 2018 21:36
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org; 
draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org
Subject: Re: Shepherd's review of draft-ietf-bess-df-election-framework

Stephane,

We have addressed all your comments in rev 02 (just posted). Please see below 
with [S](Satya & Jorge).

Thank you for your thorough review!
Satya & Jorge


From: "stephane.litkow...@orange.com" 
Date: Tuesday, April 24, 2018 at 11:04 AM
To: "bess@ietf.org" , 
"draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org" 

Subject: Shepherd's review of draft-ietf-bess-df-election-framework
Resent-From: 
Resent-To: , , 
, , , 

Resent-Date: Tuesday, April 24, 2018 at 11:04 AM

Hi,

Here is my review of the document:


General comments:
-

-  The document requires sometimes to be more generic as it describes a 
flexible framework for DF election rather than focusing on default election or 
HRW. See detailed comments.

-  The new FSM description is not enough clear in the text and AC-DF 
description provides updates to this FSM which are not aligned with the initial 
FSM description (events, states…).

-  It is not really clear if the document updates RFC7432 in some 
aspects (see detailed comments).

ID-Nits:
--


Miscellaneous warnings:

  



  == The document seems to lack the recommended RFC 2119 boilerplate, even if

 it appears to use RFC 2119 keywords -- however, there's a paragraph with

 a matching beginning. Boilerplate error?
[S]The document includes the new text in RFC8174.





 (The document does seem to have the reference to RFC 2119 which the

 ID-Checklist requires).

  -- The document date (April 12, 2018) is 12 days in the past.  Is this

 intentional?





  Checking references for intended status: Proposed Standard

  



 (See RFCs 3967 and 4897 for information about using normative references

 to lower-maturity documents in RFCs)



  == Missing Reference: 'RFC 7432' is mentioned on line 248, but not defined
[S]fixed





  == Unused Reference: 'RFC7153' is defined on line 1034, but no explicit

 reference was found in the text
[S]fixed





  == Unused Reference: 'RFC4271' is defined on line 1046, but no explicit

 reference was found in the text
[S]fixed





  -- Possible downref: Non-RFC (?) normative reference: ref. 'HRW1999'
[S]it's not an I.D




Detailed comments:
--

Section 2.1.

Using a linking word like “However” before “The described default DF election 
algorithm has some undesirable properties” would be suitable IMO to emphasis 
the contrast with the initial expectations of this algorithm mentioned in the 
previous paragraph.
[S]ok, done.


“This document describes those issues…”
Maybe using “some of those issues” or “some known issues” is more accurate, I 
do not think that the document points all the issues.
[S]ok, done.



“These mechanisms do involve changes to the default
   DF Election algorithm, however they do not require any protocol
   changes to the EVPN Route exchange and have minimal changes to their
   content per se.”
Don’t you consider that adding a community is a protocol change ?
[S]ok, changed to:
These mechanisms do involve
   changes to the default DF Election algorithm, but they do not require
   any changes to 

Re: [bess] Shepherd's review of draft-ietf-bess-df-election-framework

[stephane.litkowski]

One small comment:

“this document
   elects a DF per . This means that unlike [RFC 
7432],”

s/RFC 7432/RFC7432/

This creates a Nits


From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com]
Sent: Wednesday, May 23, 2018 21:36
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org; 
draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org
Subject: Re: Shepherd's review of draft-ietf-bess-df-election-framework

Stephane,

We have addressed all your comments in rev 02 (just posted). Please see below 
with [S](Satya & Jorge).

Thank you for your thorough review!
Satya & Jorge


From: "stephane.litkow...@orange.com" 
Date: Tuesday, April 24, 2018 at 11:04 AM
To: "bess@ietf.org" , 
"draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org" 

Subject: Shepherd's review of draft-ietf-bess-df-election-framework
Resent-From: 
Resent-To: , , 
, , , 

Resent-Date: Tuesday, April 24, 2018 at 11:04 AM

Hi,

Here is my review of the document:


General comments:
-

-  The document requires sometimes to be more generic as it describes a 
flexible framework for DF election rather than focusing on default election or 
HRW. See detailed comments.

-  The new FSM description is not enough clear in the text and AC-DF 
description provides updates to this FSM which are not aligned with the initial 
FSM description (events, states…).

-  It is not really clear if the document updates RFC7432 in some 
aspects (see detailed comments).

ID-Nits:
--


Miscellaneous warnings:

  



  == The document seems to lack the recommended RFC 2119 boilerplate, even if

 it appears to use RFC 2119 keywords -- however, there's a paragraph with

 a matching beginning. Boilerplate error?
[S]The document includes the new text in RFC8174.





 (The document does seem to have the reference to RFC 2119 which the

 ID-Checklist requires).

  -- The document date (April 12, 2018) is 12 days in the past.  Is this

 intentional?





  Checking references for intended status: Proposed Standard

  



 (See RFCs 3967 and 4897 for information about using normative references

 to lower-maturity documents in RFCs)



  == Missing Reference: 'RFC 7432' is mentioned on line 248, but not defined
[S]fixed





  == Unused Reference: 'RFC7153' is defined on line 1034, but no explicit

 reference was found in the text
[S]fixed





  == Unused Reference: 'RFC4271' is defined on line 1046, but no explicit

 reference was found in the text
[S]fixed





  -- Possible downref: Non-RFC (?) normative reference: ref. 'HRW1999'
[S]it's not an I.D




Detailed comments:
--

Section 2.1.

Using a linking word like “However” before “The described default DF election 
algorithm has some undesirable properties” would be suitable IMO to emphasis 
the contrast with the initial expectations of this algorithm mentioned in the 
previous paragraph.
[S]ok, done.


“This document describes those issues…”
Maybe using “some of those issues” or “some known issues” is more accurate, I 
do not think that the document points all the issues.
[S]ok, done.



“These mechanisms do involve changes to the default
   DF Election algorithm, however they do not require any protocol
   changes to the EVPN Route exchange and have minimal changes to their
   content per se.”
Don’t you consider that adding a community is a protocol change ?
[S]ok, changed to:
These mechanisms do involve
   changes to the default DF Election algorithm, but they do not require
   any changes to the EVPN Route exchange and have minimal changes to
   their content per se.


I think this introduction should emphasis that there is a need for a flexible 
DF election as a single algorithm may not fit everyone’s requirement.
[S]added:
   In addition, there is a need to extend the DF Election procedures so
   that new algorithms and capabilities are possible. A single algorithm
   (the default DF Election algorithm) may not meet the requirements in
   all the use-cases.


Section 2.2


“In this particular case, in fact one of the PEs does not

  get elected all as the DF, so it does…”

[SLI] I do not understand completely this sentence (maybe an English issue on 
my side). Do you mean “get elected at all” ?
[S]fixed now







“So PE1, PE2 and PE3 are also the DFs for

  v1, v2 and v3 respectively.”

[SLI] Maybe the word “also” can be removed.
[S]fixed



“This need not be

   the case as there can be a v6 peering and 

[bess] WG adoption and IPR poll for draft-sajassi-bess-evpn-fast-df-recovery-02

[stephane.litkowski]

Hi WG,

This email begins a two-week poll for BESS working group adoption of 
draft-sajassi-bess-evpn-fast-df-recovery-02 [1].

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

If you are 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.

The poll for working group adoption closes on Monday 28th May.

Regards,
Stéphane and Matthew

[1] https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-fast-df-recovery/



[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_

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

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-bgp-vpls-control-flags-04

[stephane.litkowski]

Hi,

This WGLC is considered as closed. We will proceed to the next step.

Brgds,


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, April 23, 2018 17:01
To: bess@ietf.org
Subject: [bess] WG Last Call and IPR Poll for 
draft-ietf-bess-bgp-vpls-control-flags-04

Hi WG,

This email begins a two-week working group last call for 
draft-ietf-bess-bgp-vpls-control-flags-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 is one IPR declaration against this document 
(https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-bess-bgp-vpls-control-flags).

If you are 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 7th May.

Regards,

Matthew and Stéphane

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-vpls-control-flags/


_



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.

_

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

Re: [bess] WG adoption and IPR poll on draft-liu-bess-mvpn-yang-05

[stephane.litkowski]

Hi,

Just to let you know that this poll has been closed.


From: Zhuangshunwan [mailto:zhuangshun...@huawei.com]
Sent: Tuesday, April 24, 2018 12:55
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org
Subject: RE: WG adoption and IPR poll on draft-liu-bess-mvpn-yang-05

Support adoption.

Thanks
Shunwan


发件人: BESS [mailto:bess-boun...@ietf.org] 代表 
stephane.litkow...@orange.com
发送时间: 2018年4月18日 21:28
收件人: bess@ietf.org
主题: Re: [bess] WG adoption and IPR poll on draft-liu-bess-mvpn-yang-05

Hi WG,

This is a gentle reminder that this poll is currently running.
We have not received any feedback yet, while it sounds mandatory for BESS to 
have a YANG model for mVPNs.

Please reply to this poll with support or not support.

Brgds,


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, April 09, 2018 16:23
To: bess@ietf.org
Subject: [bess] WG adoption and IPR poll on draft-liu-bess-mvpn-yang-05

This email begins a two-week poll for BESS working group adoption of 
draft-liu-bess-mvpn-yang -05 [1].

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

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.

The poll for working group adoption closes on Monday 23rd April.

Regards,
Stéphane and Matthew

[1] https://datatracker.ietf.org/doc/draft-liu-bess-mvpn-yang/


_



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.

_



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.

_

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 

[bess] Shepherd's review of draft-ietf-bess-df-election-framework

[stephane.litkowski]

Hi,

Here is my review of the document:


General comments:
-

-  The document requires sometimes to be more generic as it describes a 
flexible framework for DF election rather than focusing on default election or 
HRW. See detailed comments.

-  The new FSM description is not enough clear in the text and AC-DF 
description provides updates to this FSM which are not aligned with the initial 
FSM description (events, states...).

-  It is not really clear if the document updates RFC7432 in some 
aspects (see detailed comments).

ID-Nits:
--


Miscellaneous warnings:

  



  == The document seems to lack the recommended RFC 2119 boilerplate, even if

 it appears to use RFC 2119 keywords -- however, there's a paragraph with

 a matching beginning. Boilerplate error?



 (The document does seem to have the reference to RFC 2119 which the

 ID-Checklist requires).

  -- The document date (April 12, 2018) is 12 days in the past.  Is this

 intentional?





  Checking references for intended status: Proposed Standard

  



 (See RFCs 3967 and 4897 for information about using normative references

 to lower-maturity documents in RFCs)



  == Missing Reference: 'RFC 7432' is mentioned on line 248, but not defined



  == Unused Reference: 'RFC7153' is defined on line 1034, but no explicit

 reference was found in the text



  == Unused Reference: 'RFC4271' is defined on line 1046, but no explicit

 reference was found in the text



  -- Possible downref: Non-RFC (?) normative reference: ref. 'HRW1999'


Detailed comments:
--

Section 2.1.

Using a linking word like "However" before "The described default DF election 
algorithm has some undesirable properties" would be suitable IMO to emphasis 
the contrast with the initial expectations of this algorithm mentioned in the 
previous paragraph.

"This document describes those issues..."
Maybe using "some of those issues" or "some known issues" is more accurate, I 
do not think that the document points all the issues.


"These mechanisms do involve changes to the default
   DF Election algorithm, however they do not require any protocol
   changes to the EVPN Route exchange and have minimal changes to their
   content per se."
Don't you consider that adding a community is a protocol change ?


I think this introduction should emphasis that there is a need for a flexible 
DF election as a single algorithm may not fit everyone's requirement.


Section 2.2


"In this particular case, in fact one of the PEs does not

  get elected all as the DF, so it does..."

[SLI] I do not understand completely this sentence (maybe an English issue on 
my side). Do you mean "get elected at all" ?





"So PE1, PE2 and PE3 are also the DFs for

  v1, v2 and v3 respectively."

[SLI] Maybe the word "also" can be removed.



"This need not be

   the case as there can be a v6 peering and supporting the EVPN

   address-family."

[SLI] "This need not be the case as the EVPN address-family can be carried over 
a v6 peering"





What does the two last paragraph bring in term of information ? It sounds 
redundant with the third point.





Section 2.2.2

"there is no procedure defined in EVPN 
[RFC7432] to trigger

   the DF re- election based on the ACS change on the DF."

s/re- election/re-election/



"This document modifies the default DF Election procedure so that the

   ACS may be taken into account as a variable in the DF election, and

   therefore EVPN can provide protection against logical failures."



That's not completely true that the document modifies the default DF election.

I think it was true when the AC-DF was a single document but in the framework 
of this document the sense is a bit different as the AC-DF may influence any DF 
election type not only the default one.



I would propose to remove this paragraph as section 2.3 clarifies what the 
document is proposing.

Or modify for example as below:

"This document proposes an optional modification of the DF Election procedure 
so that the

   ACS may be taken into account as a variable in the DF election, and

   therefore EVPN can provide protection against logical failures."





Section 2.3:

I think section 2.3 requires some enhancements to better explain the DF 
election framework and not only focusing on the HRW and the AC-DF.





OLD

"In order to address those issues, this document

   describes a new DF Election algorithm and a new capability that can

   influence the DF Election result:"



NEW PROPOSAL:

"In order to address those issues, this document

   introduces a new DF Election framework. This DF election framework allows 
the PEs to agree on a DF election type to use as well as the 

[bess] WG Last Call and IPR Poll for draft-ietf-bess-bgp-vpls-control-flags-04

[stephane.litkowski]

Hi WG,

This email begins a two-week working group last call for 
draft-ietf-bess-bgp-vpls-control-flags-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 is one IPR declaration against this document 
(https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-bess-bgp-vpls-control-flags).

If you are 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 7th May.

Regards,

Matthew and Stéphane

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-vpls-control-flags/


_

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

Re: [bess] WG adoption and IPR poll on draft-liu-bess-mvpn-yang-05

[stephane.litkowski]

Hi,

Unfortunately we haven't received any positive or negative feedback on this 
draft.
As there is no established consensus, the draft cannot be adopted as a WG item.

However, the BESS WG needs a YANG model for mvpn as for other VPN services, so 
I'm a bit surprised that there was no support (even from the authors).
We would like to hear:

-  From the authors, are you willing to continue the work on the 
document ? or do we need to find a new design team for an mVPN yang model ?

-  From the WG, is there something wrong with the draft as it is today ?


Thanks,


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Wednesday, April 18, 2018 15:28
To: bess@ietf.org
Subject: Re: [bess] WG adoption and IPR poll on draft-liu-bess-mvpn-yang-05

Hi WG,

This is a gentle reminder that this poll is currently running.
We have not received any feedback yet, while it sounds mandatory for BESS to 
have a YANG model for mVPNs.

Please reply to this poll with support or not support.

Brgds,


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, April 09, 2018 16:23
To: bess@ietf.org
Subject: [bess] WG adoption and IPR poll on draft-liu-bess-mvpn-yang-05

This email begins a two-week poll for BESS working group adoption of 
draft-liu-bess-mvpn-yang -05 [1].

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

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.

The poll for working group adoption closes on Monday 23rd April.

Regards,
Stéphane and Matthew

[1] https://datatracker.ietf.org/doc/draft-liu-bess-mvpn-yang/


_



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.

_



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.

_

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.

Re: [bess] WG adoption and IPR poll on draft-liu-bess-mvpn-yang-05

[stephane.litkowski]

Hi WG,

This is a gentle reminder that this poll is currently running.
We have not received any feedback yet, while it sounds mandatory for BESS to 
have a YANG model for mVPNs.

Please reply to this poll with support or not support.

Brgds,


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, April 09, 2018 16:23
To: bess@ietf.org
Subject: [bess] WG adoption and IPR poll on draft-liu-bess-mvpn-yang-05

This email begins a two-week poll for BESS working group adoption of 
draft-liu-bess-mvpn-yang -05 [1].

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

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.

The poll for working group adoption closes on Monday 23rd April.

Regards,
Stéphane and Matthew

[1] https://datatracker.ietf.org/doc/draft-liu-bess-mvpn-yang/


_



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.

_

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

Re: [bess] Short WGLC, IPR poll, implementation policy relax poll on draft-ietf-bess-mvpn-expl-track-08

[stephane.litkowski]

Hi WG,

No additional comments/concern were raised during this short WGLC. No concern 
was also raised to progress this document without having implementations.
I'll do the write-up asap then the draft will progress to the next step.

Brgds,


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, April 09, 2018 16:33
To: bess@ietf.org
Subject: [bess] Short WGLC, IPR poll, implementation policy relax poll on 
draft-ietf-bess-mvpn-expl-track-08


Hello working group,



This email starts a one week Working Group Last Call on 
draft-ietf-bess-mvpn-expl-track-08 [1]. As the document has already passed a 
WGLC and some issues were fixed as part of the shepherd's review, this WGLC 
poll is shorter than regular ones.



This poll runs until *the 16th of April*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



Currently one IPR has been disclosed against this Document: 
https://datatracker.ietf..org/ipr/2807/.



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 implementation. As the document should be 
referred as the normative reference in draft-ietf-bier-mvpn,  we are requesting 
if you disagree/agree to progress the document without an implementation so the 
BIER document can progress as well.





Thank you



Matthew, Stéphane

bess chairs



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/




_



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.

_

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

Re: [bess] REMINDER: Poll to park almost dead WG documents

[stephane.litkowski]

Hi WG,

During this polling, we have received a single feedback on a document with the 
willingness of progressing it (draft-ietf-l3vpn-end-system). Unfortunately, we 
cannot consider that we have a rough consensus from the WG to go forward.
As a consequence, all the WG documents listed below will be marked as parked:


-  draft-ietf-bess-mvpn-pe-ce

-  draft-ietf-bess-virtual-pe

-  draft-ietf-bess-end-system-requirements

-  draft-ietf-bess-evpn-trill

-  draft-ietf-l3vpn-end-system

Please note that if a rough consensus comes in in future for one or more of 
these documents, nothing will prevent to reactivate them.

Brgds,

Stephane & Matthew,


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, April 03, 2018 10:00
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org
Subject: [bess] REMINDER: Poll to park almost dead WG documents

Hi,

This is just a reminder for this on-going polling.
In one week, these documents will be parked if we do not see a consensus on 
progressing them.

Brgds,


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Thursday, March 22, 2018 11:09
To: bess@ietf.org
Subject: [bess] Poll to park almost dead WG documents

Hi WG,

During our meeting in London we have started to get a status on some WG 
documents that have expired.
It looks that some documents does not have support and editor anymore.

This email starts a two weeks poll to hear from you:

-  If you would like to see the documents progressing or not

-  If you volunteer to take over the work on one or more of these 
documents

Please provide your feedback on a per document basis to the list by replying to 
this email.

* The poll ends April 9th *

Please note that by default the document will be parked. To get them alive 
again, we need a  significant amount of support as well as one or more 
volunteer to take over the work. Without those conditions being cleared, a 
document will be parked.

We absolutely need your feedback as we do not want to park a work which has 
still an interest for the working group.

Here is the list of documents we are polling for:

-  draft-ietf-bess-mvpn-pe-ce

-  draft-ietf-bess-virtual-pe

-  draft-ietf-bess-end-system-requirements

-  draft-ietf-bess-evpn-trill

-  draft-ietf-l3vpn-end-system


Thanks for your help,

Best Regards,

Stephane & Matthew

_



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.

_



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.

_

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. 

Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

[stephane.litkowski]

Hi WG,

We have seen a very good support to make this draft progressing.
Unfortunately we are still waiting for some IPR answers (mostly contributors). 
I have advised the required people to answer. In the meantime I will start the 
shepherd's review.

Brgds,


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, March 26, 2018 16:21
To: bess@ietf.org
Subject: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework


Hello working group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-df-election-framework-00 [1]



This poll runs until *the 9th of April*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



Currently no IPR has been disclosed 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 implementation.



Thank you



Matthew, Stéphane

bess chairs



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/



_



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.

_

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

[bess] Short WGLC, IPR poll, implementation policy relax poll on draft-ietf-bess-mvpn-expl-track-08

[stephane.litkowski]

Hello working group,



This email starts a one week Working Group Last Call on 
draft-ietf-bess-mvpn-expl-track-08 [1]. As the document has already passed a 
WGLC and some issues were fixed as part of the shepherd's review, this WGLC 
poll is shorter than regular ones.



This poll runs until *the 16th of April*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



Currently one IPR has been disclosed against this Document: 
https://datatracker.ietf.org/ipr/2807/.



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 implementation. As the document should be 
referred as the normative reference in draft-ietf-bier-mvpn,  we are requesting 
if you disagree/agree to progress the document without an implementation so the 
BIER document can progress as well.





Thank you



Matthew, Stéphane

bess chairs



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/




_

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

[bess] WG adoption and IPR poll on draft-liu-bess-mvpn-yang-05

[stephane.litkowski]

This email begins a two-week poll for BESS working group adoption of 
draft-liu-bess-mvpn-yang -05 [1].

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

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.

The poll for working group adoption closes on Monday 23rd April.

Regards,
Stéphane and Matthew

[1] https://datatracker.ietf.org/doc/draft-liu-bess-mvpn-yang/


_

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

[bess] REMINDER: Poll to park almost dead WG documents

[stephane.litkowski]

Hi,

This is just a reminder for this on-going polling.
In one week, these documents will be parked if we do not see a consensus on 
progressing them.

Brgds,


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Thursday, March 22, 2018 11:09
To: bess@ietf.org
Subject: [bess] Poll to park almost dead WG documents

Hi WG,

During our meeting in London we have started to get a status on some WG 
documents that have expired.
It looks that some documents does not have support and editor anymore.

This email starts a two weeks poll to hear from you:

-  If you would like to see the documents progressing or not

-  If you volunteer to take over the work on one or more of these 
documents

Please provide your feedback on a per document basis to the list by replying to 
this email.

* The poll ends April 9th *

Please note that by default the document will be parked. To get them alive 
again, we need a  significant amount of support as well as one or more 
volunteer to take over the work. Without those conditions being cleared, a 
document will be parked.

We absolutely need your feedback as we do not want to park a work which has 
still an interest for the working group.

Here is the list of documents we are polling for:

-  draft-ietf-bess-mvpn-pe-ce

-  draft-ietf-bess-virtual-pe

-  draft-ietf-bess-end-system-requirements

-  draft-ietf-bess-evpn-trill

-  draft-ietf-l3vpn-end-system


Thanks for your help,

Best Regards,

Stephane & Matthew

_



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.

_

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

Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

[stephane.litkowski]

Hi Ali,

Thanks, it looks good

Brgds,


From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Monday, April 02, 2018 20:47
To: LITKOWSKI Stephane OBS/OINIS; Rabadan, Jorge (Nokia - US/Mountain View); 
bess@ietf.org
Subject: Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework


Hi Stephane,

How about modifying the sentence to:

“ HRW and AC-DF mechanisms are independent of each other. Therefore, a PE MAY 
support either HRW or AC-DF independently or MAY support both of them together. 
A PE MAY also support AC-DF capability along with existing DF election 
mechanism per [RFC7432].”

Basically, what we are saying is that these two mechanisms are independent of 
each other and they don’t have to be implemented together. If an operator wants 
compliancy with this document, then it needs to specify if they want full 
compliancy (which is implementation of both mechanisms) or partial compliancy 
(which is implementation of one of the mechanisms).

Regards,
Ali

From: "stephane.litkow...@orange.com" 
>
Date: Wednesday, March 28, 2018 at 11:50 PM
To: Cisco Employee >, "Rabadan, 
Jorge (Nokia - US/Mountain View)" 
>, 
"bess@ietf.org" >
Subject: RE: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

Hi Ali,

This paragraph points that HRW and AC-DF may be USED independently, but this 
does say that a vendor OS may implement HRW or AC-DF or both.
I see two issues if it is not clarified:

  *   When an operator pushes a RFP requesting support of this draft, both HRW 
and AC-DF support are defacto required
  *   From a WG standpoint, to progress further the document we need an 
implementation that supports fully the draft so both HRW and AC-DF.

My point is really on the implementation side, not on the usage.


Brgds,


From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Wednesday, March 28, 2018 18:44
To: LITKOWSKI Stephane OBS/OINIS; Rabadan, Jorge (Nokia - US/Mountain View); 
bess@ietf.org
Subject: Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework


Hi Stephane,

In section 2.3, it says that:

Both, HRW and AC-DF MAY be used independently or simultaneously.
 The AC-DF capability MAY be used with the default DF Election
 algorithm too.
Do you want further clarification? If so, please suggest text.

Thanks,
Ali

From: BESS > on behalf of 
"stephane.litkow...@orange.com" 
>
Date: Wednesday, March 28, 2018 at 12:50 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
>, 
"bess@ietf.org" >
Subject: Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

Hi Jorge,

More inline

From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com]
Sent: Wednesday, March 28, 2018 00:38
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org
Subject: Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

Hi Stephane,

Please see in-line.
Thanks.
Jorge

From: BESS > on behalf of 
"stephane.litkow...@orange.com" 
>
Date: Tuesday, March 27, 2018 at 8:48 AM
To: "bess@ietf.org" >
Subject: Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

Hi Authors,

Speaking as a WG member, I have two comments:

-  As I have pointed during the BESS meeting, it would be good to have 
a clear definition of what is a DF type vs a capability.
[JORGE] yes, we can clarify this in the next rev along with any other comments 
made during this LC.


-  I think it would be good to have the draft telling that the 
implementation of HRW and AC-DF are optionals.
[JORGE] Is that necessary? Since the draft is not updating RFC7432, aren’t 
those options implicitly optional for RFC7432 implementations?
[SLI] I was more thinking about people implementing this draft (future RFC). 
Should they implement both HRW and AC-DF ? I don’t think so.


Brgds,

Stephane

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, March 26, 2018 16:21
To: bess@ietf.org
Subject: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework


Hello working group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-df-election-framework-00 [1]



This poll runs until *the 9th 

Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

[stephane.litkowski]

Hi Ali,

This paragraph points that HRW and AC-DF may be USED independently, but this 
does say that a vendor OS may implement HRW or AC-DF or both.
I see two issues if it is not clarified:

-  When an operator pushes a RFP requesting support of this draft, both 
HRW and AC-DF support are defacto required

-  From a WG standpoint, to progress further the document we need an 
implementation that supports fully the draft so both HRW and AC-DF.

My point is really on the implementation side, not on the usage.


Brgds,


From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Wednesday, March 28, 2018 18:44
To: LITKOWSKI Stephane OBS/OINIS; Rabadan, Jorge (Nokia - US/Mountain View); 
bess@ietf.org
Subject: Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework


Hi Stephane,

In section 2.3, it says that:

Both, HRW and AC-DF MAY be used independently or simultaneously.
 The AC-DF capability MAY be used with the default DF Election
 algorithm too.
Do you want further clarification? If so, please suggest text.

Thanks,
Ali

From: BESS > on behalf of 
"stephane.litkow...@orange.com" 
>
Date: Wednesday, March 28, 2018 at 12:50 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
>, 
"bess@ietf.org" >
Subject: Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

Hi Jorge,

More inline

From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com]
Sent: Wednesday, March 28, 2018 00:38
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org
Subject: Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

Hi Stephane,

Please see in-line.
Thanks.
Jorge

From: BESS > on behalf of 
"stephane.litkow...@orange.com" 
>
Date: Tuesday, March 27, 2018 at 8:48 AM
To: "bess@ietf.org" >
Subject: Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

Hi Authors,

Speaking as a WG member, I have two comments:

-  As I have pointed during the BESS meeting, it would be good to have 
a clear definition of what is a DF type vs a capability.
[JORGE] yes, we can clarify this in the next rev along with any other comments 
made during this LC.


-  I think it would be good to have the draft telling that the 
implementation of HRW and AC-DF are optionals.
[JORGE] Is that necessary? Since the draft is not updating RFC7432, aren’t 
those options implicitly optional for RFC7432 implementations?
[SLI] I was more thinking about people implementing this draft (future RFC). 
Should they implement both HRW and AC-DF ? I don’t think so.


Brgds,

Stephane

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, March 26, 2018 16:21
To: bess@ietf.org
Subject: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework


Hello working group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-df-election-framework-00 [1]



This poll runs until *the 9th of April*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



Currently no IPR has been disclosed 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 implementation.



Thank you



Matthew, Stéphane

bess chairs



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/



_



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.

Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

[stephane.litkowski]

Hi Jorge,

More inline

From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com]
Sent: Wednesday, March 28, 2018 00:38
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org
Subject: Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

Hi Stephane,

Please see in-line.
Thanks.
Jorge

From: BESS > on behalf of 
"stephane.litkow...@orange.com" 
>
Date: Tuesday, March 27, 2018 at 8:48 AM
To: "bess@ietf.org" >
Subject: Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

Hi Authors,

Speaking as a WG member, I have two comments:

-  As I have pointed during the BESS meeting, it would be good to have 
a clear definition of what is a DF type vs a capability.
[JORGE] yes, we can clarify this in the next rev along with any other comments 
made during this LC.


-  I think it would be good to have the draft telling that the 
implementation of HRW and AC-DF are optionals.
[JORGE] Is that necessary? Since the draft is not updating RFC7432, aren’t 
those options implicitly optional for RFC7432 implementations?
[SLI] I was more thinking about people implementing this draft (future RFC). 
Should they implement both HRW and AC-DF ? I don’t think so.


Brgds,

Stephane

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, March 26, 2018 16:21
To: bess@ietf.org
Subject: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework


Hello working group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-df-election-framework-00 [1]



This poll runs until *the 9th of April*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



Currently no IPR has been disclosed 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 implementation.



Thank you



Matthew, Stéphane

bess chairs



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/



_



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.

_



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.

_

Ce message et ses pieces jointes peuvent contenir des 

Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

[stephane.litkowski]

Hi Authors,

Speaking as a WG member, I have two comments:

-  As I have pointed during the BESS meeting, it would be good to have 
a clear definition of what is a DF type vs a capability.

-  I think it would be good to have the draft telling that the 
implementation of HRW and AC-DF are optionals.

Brgds,

Stephane

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, March 26, 2018 16:21
To: bess@ietf.org
Subject: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework


Hello working group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-df-election-framework-00 [1]



This poll runs until *the 9th of April*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



Currently no IPR has been disclosed 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 implementation.



Thank you



Matthew, Stéphane

bess chairs



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/



_



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.

_

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

[bess] WGLC on draft-ietf-bess-evpn-df-election-framework

[stephane.litkowski]

Hello working group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-df-election-framework-00 [1]



This poll runs until *the 9th of April*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



Currently no IPR has been disclosed 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 implementation.



Thank you



Matthew, Stéphane

bess chairs



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/



_

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

[bess] Poll to park almost dead WG documents

[stephane.litkowski]

Hi WG,

During our meeting in London we have started to get a status on some WG 
documents that have expired.
It looks that some documents does not have support and editor anymore.

This email starts a two weeks poll to hear from you:

-  If you would like to see the documents progressing or not

-  If you volunteer to take over the work on one or more of these 
documents

Please provide your feedback on a per document basis to the list by replying to 
this email.

* The poll ends April 9th *

Please note that by default the document will be parked. To get them alive 
again, we need a  significant amount of support as well as one or more 
volunteer to take over the work. Without those conditions being cleared, a 
document will be parked.

We absolutely need your feedback as we do not want to park a work which has 
still an interest for the working group.

Here is the list of documents we are polling for:

-  draft-ietf-bess-mvpn-pe-ce

-  draft-ietf-bess-virtual-pe

-  draft-ietf-bess-end-system-requirements

-  draft-ietf-bess-evpn-trill

-  draft-ietf-l3vpn-end-system


Thanks for your help,

Best Regards,

Stephane & Matthew

_

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

Re: [bess] Call for adoption: draft-zzhang-bess-mvpn-msdp-sa-interoperation-01

[stephane.litkowski]

Hi,

Based on the (late) feedback we have received on the list, it looks that the 
draft has a pretty good level of support.
The document is adopted as a Working Group item.

Authors,

Could you please republish the document as 
draft-ietf-bess-mvpn-msdp-sa-interoperation ?

Thanks


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, February 26, 2018 08:01
To: bess@ietf.org
Subject: [bess] Call for adoption: 
draft-zzhang-bess-mvpn-msdp-sa-interoperation-01


Hello working group,



This email starts a two-week call for adoption on

draft-zzhang-bess-mvpn-msdp-sa-interoperation-01 [1] as a BESS Working Group 
Document.



Please state on the list if you support the adoption or not (in both cases, 
please also state the reasons).



This poll runs until *the 19th of March*.



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. The Document won't progress without answers from all the 
Authors and Contributors.



Currently no IPR has been disclosed 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.



Thank you



(Martin), Matthew, Stéphane

bess chairs



[1] 
https://datatracker.ietf.org/doc/draft-zzhang-bess-mvpn-msdp-sa-interoperation/


_



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.

_

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

Re: [bess] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

[stephane.litkowski]

Hi Daniel,

You may need to introduce new hardware as well for SRTE to handle the number of 
labels to push.
If your hardware is flexible (network processors), there is a chance that it 
can also handle NSH.

Now if you want just to use SR policies to perform a kind of service chaining, 
is there something really specific to develop ? Can’t you do this today with 
the “existing” SRTE machinery and SIDs that are available: you need Node-SID 
for transport compression, and a SID to forward to the VNF (similar to the EPE 
SID).

Brgds,

Stephane


From: Bernier, Daniel [mailto:daniel.bern...@bell.ca]
Sent: Wednesday, March 21, 2018 00:53
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; LITKOWSKI Stephane OBS/OINIS; 
LINGALA, AVINASH; Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian 
Farrel
Cc: mpls; SPRING WG List; bess@ietf.org; s...@ietf.org
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


+1 to Jim and Avinash



Same challenge on our side.



Our network is built upon a MPLS data plane. My current "network appliances" 
are connected to MPLS devices and service instantiation done through static 
pseudowires. It will be easier for me to introduce SRTE policy capabilities 
through software upgrades instead of certifying and introducing new hardware to 
enable a newer encap.



And by the time we get to leverage contextual metadata between functions, most 
probably, these will have also evolved (micro-services, hw/sw disaggregation) 
and new ways of conveying that metadata will have been proposed.



Thanks,



PS: I am also wondering why it is so badly seen to look at alternatives to NSH 
SFC while at the same time we introduce new WG to discuss DC routing (RIFT, 
LSVR, ...). If we accept multiplicity in that space, and I think we should, 
then we should allow it in chain composition and programming.



Cheers,



Daniel Bernier




From: mpls > on behalf of 
mohamed.boucad...@orange.com 
>
Sent: Tuesday, March 20, 2018 7:59 AM
To: UTTARO, JAMES; LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; Henderickx, 
Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; bess@ietf.org; 
s...@ietf.org
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Jim,

You said that you “simply need SR to realize the chain”, but actually if you 
want a path to be steered relying upon some information conveyed in the packet 
and to invoke specific SFs, then you need to define the structure of such 
information and its meaning.

That is another piece of specification work to be yet done if you want it to be 
part of SR information itself.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : mardi 20 mars 2018 11:30
À : LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; BOUCADAIR Mohamed IMT/OLN; 
Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; 
bess@ietf.org
Objet : RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

I guess I am not being clear.

The issue as I see it is that I do not require NSH to realize the creation of 
simple chains. I simply need SR to realize the chain. Why is the IETF forcing 
me to adopt technology that I do not need, while at the same time reducing the 
number of vendors that I may use in my network as this encap will have to be 
supported by traditional OEMs and others looking to get into the business.

TBC I am not against NSH it addresses use cases where dynamic complex chains 
are required. The reality of my world is that I have lots of simpler chains i.e 
FW, LB  and do not need the additional OPEX and CAPEX  costs associated with 
deploying NSH.

Jim Uttaro

From: stephane.litkow...@orange.com 
[mailto:stephane.litkow...@orange.com]
Sent: Tuesday, March 20, 2018 6:25 AM
To: LINGALA, AVINASH >; BOUCADAIR Mohamed 
IMT/OLN >; 
UTTARO, JAMES >; Henderickx, Wim (Nokia - 
BE/Antwerp) >; Robert 
Raszuk >; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
bess@ietf.org
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

> Same approach that IETF took for EVPN  with various encap options like MPLS, 
> VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport 
underneath: MPLS, VXLAN, GRE,UDP,…

In your 

Re: [bess] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

[stephane.litkowski]

For simple service chains, policy routing works fine as well (this was what was 
used before bess-service-chaining has come). It becomes a nightmare when the 
service chains are complex.

From: Henderickx, Wim (Nokia - BE/Antwerp) [mailto:wim.henderi...@nokia.com]
Sent: Tuesday, March 20, 2018 11:35
To: UTTARO, JAMES; LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; BOUCADAIR 
Mohamed IMT/OLN; Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org; bess@ietf.org
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Jim whats wrong with this draft:
https://tools.ietf.org/html/draft-ietf-bess-service-chaining-04

It provides simple service chaining using MPLS techniques


From: "UTTARO, JAMES" >
Date: Tuesday, 20 March 2018 at 11:30
To: Stephane Litkowski 
>, 
"LINGALA, AVINASH" >, "mohamed. 
boucadair" >, 
"Henderickx, Wim (Nokia - BE/Antwerp)" 
>, Robert Raszuk 
>, Adrian Farrel 
>
Cc: mpls >, SPRING WG List 
>, 
"s...@ietf.org" >, 
"bess@ietf.org" >
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

I guess I am not being clear.

The issue as I see it is that I do not require NSH to realize the creation of 
simple chains. I simply need SR to realize the chain. Why is the IETF forcing 
me to adopt technology that I do not need, while at the same time reducing the 
number of vendors that I may use in my network as this encap will have to be 
supported by traditional OEMs and others looking to get into the business.

TBC I am not against NSH it addresses use cases where dynamic complex chains 
are required. The reality of my world is that I have lots of simpler chains i.e 
FW, LB  and do not need the additional OPEX and CAPEX  costs associated with 
deploying NSH.

Jim Uttaro

From: stephane.litkow...@orange.com 
[mailto:stephane.litkow...@orange.com]
Sent: Tuesday, March 20, 2018 6:25 AM
To: LINGALA, AVINASH >; BOUCADAIR Mohamed 
IMT/OLN >; 
UTTARO, JAMES >; Henderickx, Wim (Nokia - 
BE/Antwerp) >; Robert 
Raszuk >; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
bess@ietf.org
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

> Same approach that IETF took for EVPN  with various encap options like MPLS, 
> VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport 
underneath: MPLS, VXLAN, GRE,UDP,…

In your example EVPN provides the service, then you pick the transport you want.
Here SFC/NSH may provide the service (chaining), then you pick also the 
transport you want.


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of LINGALA, AVINASH
Sent: Tuesday, March 20, 2018 10:06
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; Henderickx, Wim (Nokia - 
BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org; 
bess@ietf.org
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


I support this effort and I agree with Jim.  As an operator we would like to 
see various encapsulation options for SFC. This would help an operator to pick 
the suitable encapsulation option for their networks.

Same approach that IETF took for EVPN  with various encap options like MPLS, 
VXLAN, GENEVE,..

​
Thanks,
Avinash Lingala


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com
Sent: Monday, March 19, 2018 10:25 AM
To: UTTARO, JAMES >; Henderickx, Wim 
(Nokia - BE/Antwerp) 
>; Robert Raszuk 
>; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; bess@ietf.org; 
s...@ietf.org
Subject: Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-,

This is really a matter of taste.

Jim, whatever 

Re: [bess] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

[stephane.litkowski]

> Same approach that IETF took for EVPN  with various encap options like MPLS, 
> VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport 
underneath: MPLS, VXLAN, GRE,UDP,…

In your example EVPN provides the service, then you pick the transport you want.
Here SFC/NSH may provide the service (chaining), then you pick also the 
transport you want.


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of LINGALA, AVINASH
Sent: Tuesday, March 20, 2018 10:06
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; Henderickx, Wim (Nokia - 
BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org; bess@ietf.org
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


I support this effort and I agree with Jim.  As an operator we would like to 
see various encapsulation options for SFC. This would help an operator to pick 
the suitable encapsulation option for their networks.

Same approach that IETF took for EVPN  with various encap options like MPLS, 
VXLAN, GENEVE,..

​
Thanks,
Avinash Lingala


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com
Sent: Monday, March 19, 2018 10:25 AM
To: UTTARO, JAMES >; Henderickx, Wim 
(Nokia - BE/Antwerp) 
>; Robert Raszuk 
>; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; bess@ietf.org; 
s...@ietf.org
Subject: Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-,

This is really a matter of taste.

Jim, whatever scheme we use for identifying service chains, there are 
requirements/constraints/new practices/new OAM procedures that need to be 
supported/honored for service chaining purposes.

Those are not simple nor complex in MPLS vs. NSH over MPLS. I’m wrong?

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 14:10
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; 
bess@ietf.org
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Med,

When I say simply, I am speaking as an operator. The 
operations, systems, tools, institutional knowledge etc… in this space is 
around MPLS. There is a simpler path to creating simple chains by using MPLS 
instead of introducing a new encap.

Thanks,
Jim Uttaro

From: mohamed.boucad...@orange.com 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 10:03 AM
To: UTTARO, JAMES >; Henderickx, Wim 
(Nokia - BE/Antwerp) 
>; Robert Raszuk 
>; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
bess@ietf.org
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-,

I’m afraid that you cannot ‘simply’ re-use MPLS for chaining purposes without 
any code upgrade.


NSH does provide the simple functionality you need; that is the information to 
identify a chain + avoid infinite loops. This is known as: MD Type 0x2 with 
length is 0x2.

Of course you can encode that information using another channel, but still code 
change is needed.

Please note that NSH is not at the same level as “GENEVE, VXLAN”.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 13:48
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; 
bess@ietf.org
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Med,

We run an MPLS network so there is no NSH deployed anywhere. I 
want to create simple chains that we can make available to our WAN customers 
and I want to keep it simple from a technology and operations POV.. At this 
point I do not see the need to introduce NSH for what we need to do. I can 
simply re-use MPLS.

Not sure why NSH is the winner here there are folks who advocate for GENEVE, 
NSH, VXLAN etc… If IETF is pushing for one encap than it would be helpful to 
define the set of requirements/criteria and compare the encaps.

Thanks,
Jim Uttaro

From: mohamed.boucad...@orange.com 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 9:22 AM
To: UTTARO, JAMES