from:"thomas.morin"

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

2018-09-05 Thread thomas.morin

Hi Stéphane, all,

On 03/09/2018 10:30, stephane.litkow...@orange.com wrote:

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.

I'm not aware of any such undisclosed IPR.

We are also polling for any existing implementation as per [2].

The OpenStack networking-bagpipe [1] project has an implementation of
the API from the OpenStack networking-sfc [2] project based on the
specifications in this draft.

Best,

-Thomas

[1]
https://docs.openstack.org/networking-bagpipe/latest/user/applications.html#service-chaining-sfc

[2] https://docs.openstack.org/networking-sfc/latest

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] AD Review of draft-ietf-bess-evpn-overlay-08

2017-12-05 Thread thomas.morin

All,

Martin Vigoureux, 2017-12-05 11:34:
> 
> Alvaro: [...]
> > 
> > What about Geneve (draft-ietf-nvo3-geneve)?  The nvo3 WG is
> > focusing on
> > Geneve as the Standard encapsulation, but this document doesn’t
> > even mention it.
> 
> Indeed. But The decision by NVO3 to work on Geneve is fairly recent.
> I have indicated in the BESS report that we'll likely be working
> closeer 
> with NVO3 from now on. An individual draft on the applicability of
> EVPN 
> to NVO3 networks is targeting NVO3 WG. Conversely, an individual
> draft 
> on EVPN extensions for Geneve is targeting BESS. We have agreed that 
> we'll do cross reviews at the important milestones of these docs.

Perhaps draft-ietf-bess-evpn-overlay could hint on such a Geneve
work for EVPN; something like: "Adapting the EVPN control plane to the
Geneve encapsulation is out of the scope of this document, and is
expected to be covered in a separate document based on the same
architectural principles" 


> 
> > (2) Document Status
> > 
> > 
> > Why is this a Standards Track document?  The Abstract/Introduction
> > say
> > that “this document describes how Ethernet VPN (EVPN) can be used
> > as an
> > NVO solution and explores applicability of EVPN functions and
> > procedures.”  -- if it’s just a description (as the text clearly
> > is),
> > and not a technical specification, then why it is not
> > Informational?
> > I can see how we could call it an Applicability Statement (rfc2026)
> > and
> > still publish it in the Standards Track.  If we want to go that
> > way, we
> > would need some minor updates to make it clear that this is an
> > Applicability Statement and is not intended to stand in for a
> > Technical
> > Specification.  I am not clear on the process as it related to
> > possible
> > DownRefs (see below), but I’m willing to Last Call an Applicability
> > Statement in the Standards Track…if that is what you want.
> 
> Maybe the authors should s/describes/specifies/ to better reflect
> the 
> content of the document.
> On the other hand, rfc2026 says "A Technical Specification is any 
> description of a protocol, service, procedure, convention, or
> format."
> It seems to match as well.

I agree that "specifies" is a better wording for the content of this
document which does specify detailed procedures combining existing
mechanisms.  It certainly needs to be Standard Track.



(more comments/answers below)


> > 
> > M2. From 5.1.3 (Constructing EVPN BGP Routes):  as long as they use
> > the
> > same EVPN multi-homing procedures (section 8.3.1, Split Horizon)…”.
> > Is
> > Split Horizon an example, or the only multi-homing procedure that
> > should
> > be considered?  Please be clear.

(Related to this sentence, but not related to your question:)

I recently realized that I'm unclear on this point: the way the MPLS
label fields are decoded is not the same for a VXLAN or NVGRE encap
(where the whole 3 bytes are used) than for an MPLS encap (where only
the topmost 20 bits of the 3 bytes are used). This means that, although
the encoding is unambiguous when one encap is used (or when VXLAN and
NVGRE would be used at the same time), it becomes ambiguous when a mix
is used, for instance MPLS and VXLAN, unless the dataplane MPLS label
to use is equal to the VNI after a 4-bit left shifting.

If I'm not wrong "...routes MAY be advertised with multiple
encapsulation types" needs to be restricted to the cases that work.

[...]
> > 
> > M8. References
> > 
> > 
> > M8.1. TUNNEL-ENCAP (aka ) should be
> > Normative, which btw is marked to Obsolete rfc5512; I mention this
> > because both are listed in several parts, so you should take
> > rfc5512 out.

This was debated on a while ago, and this is somehow the conclusion of
the discussion:

https://mailarchive.ietf.org/arch/msg/bess/z1J2VD9rtCQC7NHnmi_4tz_bR_w

Copy-paste:

We'll also add idr-tunnel-encaps a Informative reference. With respect
to Tunnel Encap Extended Community (which is the only part of
idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draft
itself references RFC 5512.

During the course of WG LC and RFC editorship of evpn-overlay draft, if
we see that idr-tunnel-encap is progressing fast, then we can drop the
reference to RFC 5512 and make the reference to idr-tunnel-encap
Normative. Otherwise, we'll keep both references with RFC 5512 as
Normative and idr-tunnel-encap as Informative.


The question probably is whether or not idr-tunnel-encap progress is
sufficient.


> > 
> > 
> > M8.2. These should also be Normative: RFC7348, NVGRE, VXLAN-GPE,
> > RFC4023
> > 

My process fu is weakening, but if this specification is standard track
(and I believe it should be), I believe it can't normatively depend on
Informative specs and some of the above are in this category.

-Thomas
(as document shep)

_

Ce message et ses pieces jointes peuvent contenir

Re: [bess] New bess Co-Chair

2017-12-01 Thread thomas.morin

Alvaro Retana, 2017-12-01 11:16:
> I am sad to report that Thomas Morin has decided not to continue as
> bess Co-Chair due to the demands of his job.  Thomas: thank you for
> all the effort you have put into the WG, we all look forward to your
> continued contributions to the IETF!

Thank you Alvaro.

It has been an honor and a pleasure for me to co-chair l3vpn & bess,
trying to accompany the working group contributions and maybe
contribute a bit to driving it into useful directions. The great
experience of co-chairing with Martin was unarguably a plus in this
journey.

> In consultation with Martin and the other ADs, we have asked
> Stephane Litkowski to take on the role of bess Co-Chair. [...]
> Welcome Stephane!

Welcome Stephane! :)
Be aware that co-chairing bess comes with the risk of being possibly
misrepresented [1].

And to all, many thanks for being great BESS contributors ; don't
celebrate too fast though: I'll still possibly be around lurking for
that little-thing-in-this-obscure-extended-community or the other thing
on which there can be something to nitpick about !  ;)

Bess regards,

-Thomas

[1] https://twitter.com/LlanOldDog/status/643796807852630016

_

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] Re : WGLC for draft-ietf-idr-tunnel-encaps-07

2017-10-09 Thread thomas.morin

Support.

-Thomas


John Scudder, 2017-10-06 14:39:
> [resending with corrected draft alias in cc, sorry about that]
> 
> Hi All,
> 
> A working group last call has been requested for draft-ietf-idr-
> tunnel-encaps-07. Please reply to the list with your comments. As
> usual note we cannot advance the draft without participation from the
> group. Please get your comments in before October 20, 2017.
> 
> We previously had a WGLC for version -04, https://www.ietf.org/mail-a
> rchive/web/idr/current/msg18151.html, which failed to achieve
> consensus largely due to lack of participation. Since then there have
> been several revisions to the document and active discussion, so I
> hope we'll have better engagement this time and will be able to
> conclude this WGLC. I especially hope we can proceed forward since
> drafts in both OSPF and BESS normatively reference this draft, for
> this reason I've cc'd both the OSPF and BESS mailing lists.
> 
> The authors have already confirmed IPR during the previous last call,
> so we won't require that again. Of course, if there have been any
> changes to IPR status since -04, please do make the necessary
> disclosures.
> 
> https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-07
> 
> Thanks,
> 
> --John
> ___
> 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] RtgDir review: draft-ietf-bess-evpn-etree-12

2017-08-16 Thread thomas.morin

Hi Ravi,

Many thanks for this review.

One question below...


Ravi Singh, 2017-08-16 06:56:
> The only major comments pertain to
> a.   Sections 5.2/8.1: which appear like an overkill and could be
> considered for dropping from text.
[...]

Can you expand on why you this this is overkill ?

Thank you,

-Thomas



_

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-rabadan-bess-evpn-pref-df / adopted !

2017-06-21 Thread thomas.morin


Hi everyone,

We have a new working group document!

Can authors please repost as draft-ietf-bess-evpn-pref-df-00 ?

Thanks,

Thomas & Martin


2017-06-06, Thomas Morin:

Hello working group,

This email starts a two-week call for adoption on
draft-rabadan-bess-evpn-pref-df-02 [1] as a 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 20th 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 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.


If you are not listed as an Author or 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 & Thomas
bess chairs

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


_

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 Last Call for draft-ietf-bess-evpn-optimized-ir

2017-06-16 Thread thomas.morin


Hello Working Group,

This email starts a Working Group Last Call on 
draft-ietf-bess-evpn-optimized-ir-01 [1] which is considered mature and 
ready for a final working group review.


Please read this document if you haven't read the most recent version 
yet, and send your comments to the list, no later than *30th of June*.
Note that this is *not only* a call for comments on the document; it is 
also a call for support (or not) to publish this document as a Standard 
Track RFC.


*Coincidentally*, we are also polling for knowledge of any IPR that 
applies to draft-ietf-bess-evpn-optimized-ir, 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 a document Author or Contributor of the draft 
please respond to this email and indicate whether or not you are aware 
of any relevant IPR.


Note that, as of today, no IPR has been disclosed against this document 
or its earlier versions.


We are **also polling for knowledge of implementations** of part or all 
of what this document specifies. This information is expected as per [2].

Please inform the mailing list, or the chairs, or only one of the chairs.

Thank you,
T

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-optimized-ir/
[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] Call for adoption: draft-rabadan-bess-evpn-pref-df

2017-06-06 Thread thomas.morin


Hello working group,

This email starts a two-week call for adoption on
draft-rabadan-bess-evpn-pref-df-02 [1] as a 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 20th 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 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.


If you are not listed as an Author or 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 & Thomas
bess chairs

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

_

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] MIBDoc review of draft-ietf-bess-mvpn-mib-02.txt

2017-06-01 Thread thomas.morin


Ok, thanks for the update and for progressing this work!

-Thomas

2017-06-01, Hiroshi Tsunoda:

Hi Thomas, Glenn

Sorry, this is my fault.

I think Glenn is waiting for the new revision because
the last revision posted in March does not have essential
improvement.

I am going to make a major update MVPN-MIB document
in this weekend and will post the new revision at the beginning
of the next week hopefully.

Thanks in advance,

-- tsuno









2017-06-01 11:16 GMT+02:00  :

Hi Glenn,

Thanks for the reviews on the other mvpn-related MIB
(draft-ietf-bess-l2l3-vpn-mcast-mib-03).

We would like to have an idea of what is the progress around this draft.
Do you know when you could do a review of the revision posted in early March
?

Thanks in advance,

-Thomas


2017-03-01, Hiroshi Tsunoda:


Dear Glenn,

I posted a new revision MVPN-MIB document.
This revision addresses mainly editorial parts of your comments.
Although so many TBDs have remained, I hope that this becomes
the re-starting point to finalize this document.

URL:
https://www.ietf.org/id/draft-ietf-bess-mvpn-mib-03.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-mib/
Htmlized:
https://tools.ietf.org/html/draft-ietf-bess-mvpn-mib-03
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-mib-03

Please see some notes below.


1.  Abstract:
1.1 Please give the full expansion of MPLS/BGP



Fixed.


1.2 "In particular, it describes managed objects to configure and/or
  monitor Multicast in MPLS/BGP IP VPNs (MVPN) on a router."
 Is this for any router or, a "Provider Edge" router ?
 Please fix accordingly.



This point will be fixed in the next revision.


2.  Introduction
2.1 PE - appears first time. Please give the full expansion.



Fixed.


2.2 Is the protocol for "exchanging VPN multicast" or
  "exchanging VPN multicast states"? Please fix appropriately.



"exchanging VPN multicast states" is correct. Fixed.


2.3 The expression "standard MIB" in the following is confusing:
 "This document defines a standard MIB for MVPN-specific
 objects that are generic to both PIM-MVPN and BGP-MVPN."
 Is there any special significance in the "standard" above?
 If no, then please drop the word.



Fixed. I dropped the word "standard".


 Are the objects "generic" to PIM-MVPN and BGP-MVPN or "common"
 to  PIM-MVPN and BGP-MVPN ? Please change accordingly.



This point will be fixed in the next revision.


2.4 Please give the full expansion of the abbreviations occuring
  for the first time in the document. (MPLS, L3VPN).



Fixed.


2.5 The terminology section is a bit terse. Explaining the terms
 that are used, with reference to the protocol documents will
 improve readability.
 e.g.
  - MVPN, PE, PMSI/tunnels,
  - C-multicast routing exchange protocol (PIM or BGP),
C-multicast states
  - I-PMSI, S-PMSI, provider tunnels



Partially fixed. I will give more detailed explanation in the next
revision.


3.  MVPN MIB.
 This gives the overview of the MVPN MIB.
 The MIB module aims to provide "configuring and/or monitoring"

3.1 In
  "This MIB enables configuring and/or monitoring of MVPNs on PE
  devices: the whole multicast VPN machinery."
 "the whole multicast VPN machinery" is very difficult to define.
 Please use precisely defined terms.
3.2 In "To represent them,"
 "them" seems ambiguous, please clarify.



These points will be fixed in the next revision.


3.3 The diagram needs some explanation.
 What do the boxes represent? Tables ? The labels are meant to be
 table names ? The table names do not match the labels.
 What do the arrows signify? Please explain.



Partially fixed. Each box represents a table defined in this document.
I fixed the labels in the boxes.

More detailed explanation will be added in the next revision.


3.4 The short explanation of the tables could be augmented with some
 information on what they represent and an idea of how they will
 be used. ( RFC 4382 provides a good example).



These points will be fixed in the next revision.


MIB definitions:
4. MIB syntax checking:
smilint -s -e -l 5 mibs/MCAST-VPN-MIB 2>MCAST-VPN-MIB.txt



I fixed the most of the warnings except for "index-exceeds-too-large".
I think the restructuring of the MIB module may be required in order to
fix "index-exceeds-too-large".  Thus, I will need more time to work on
this.


5. IMPORTS clause
 MIB modules from which items are imported must be cited and included
in the normative references.
The conventional style is
  mplsStdMIB
 FROM MPLS-TC-STD-MIB-- [RFC3811]



Fixed.


6. Please update the MODULE-IDENTITY. (There are no syntantic errors.)
6.1 'ORGANIZATION "IETF Layer-3 Virtual Private
   Networks Working Group."'
 needs to be fixed to
 'ORGANIZATION "IETF BESS Working Group."'
 or

Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-mib-02.txt

2017-06-01 Thread thomas.morin


Hi Glenn,

Thanks for the reviews on the other mvpn-related MIB 
(draft-ietf-bess-l2l3-vpn-mcast-mib-03).


We would like to have an idea of what is the progress around this draft.
Do you know when you could do a review of the revision posted in early 
March ?


Thanks in advance,

-Thomas


2017-03-01, Hiroshi Tsunoda:

Dear Glenn,

I posted a new revision MVPN-MIB document.
This revision addresses mainly editorial parts of your comments.
Although so many TBDs have remained, I hope that this becomes
the re-starting point to finalize this document.

URL:
https://www.ietf.org/id/draft-ietf-bess-mvpn-mib-03.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-mib/
Htmlized:
https://tools.ietf.org/html/draft-ietf-bess-mvpn-mib-03
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-mib-03

Please see some notes below.


1.  Abstract:
1.1 Please give the full expansion of MPLS/BGP


Fixed.


1.2 "In particular, it describes managed objects to configure and/or
 monitor Multicast in MPLS/BGP IP VPNs (MVPN) on a router."
Is this for any router or, a "Provider Edge" router ?
Please fix accordingly.


This point will be fixed in the next revision.


2.  Introduction
2.1 PE - appears first time. Please give the full expansion.


Fixed.


2.2 Is the protocol for "exchanging VPN multicast" or
 "exchanging VPN multicast states"? Please fix appropriately.


"exchanging VPN multicast states" is correct. Fixed.


2.3 The expression "standard MIB" in the following is confusing:
"This document defines a standard MIB for MVPN-specific
objects that are generic to both PIM-MVPN and BGP-MVPN."
Is there any special significance in the "standard" above?
If no, then please drop the word.


Fixed. I dropped the word "standard".


Are the objects "generic" to PIM-MVPN and BGP-MVPN or "common"
to  PIM-MVPN and BGP-MVPN ? Please change accordingly.


This point will be fixed in the next revision.


2.4 Please give the full expansion of the abbreviations occuring
 for the first time in the document. (MPLS, L3VPN).


Fixed.


2.5 The terminology section is a bit terse. Explaining the terms
that are used, with reference to the protocol documents will
improve readability.
e.g.
 - MVPN, PE, PMSI/tunnels,
 - C-multicast routing exchange protocol (PIM or BGP),
   C-multicast states
 - I-PMSI, S-PMSI, provider tunnels


Partially fixed. I will give more detailed explanation in the next revision.


3.  MVPN MIB.
This gives the overview of the MVPN MIB.
The MIB module aims to provide "configuring and/or monitoring"

3.1 In
 "This MIB enables configuring and/or monitoring of MVPNs on PE
 devices: the whole multicast VPN machinery."
"the whole multicast VPN machinery" is very difficult to define.
Please use precisely defined terms.
3.2 In "To represent them,"
"them" seems ambiguous, please clarify.


These points will be fixed in the next revision.


3.3 The diagram needs some explanation.
What do the boxes represent? Tables ? The labels are meant to be
table names ? The table names do not match the labels.
What do the arrows signify? Please explain.


Partially fixed. Each box represents a table defined in this document.
I fixed the labels in the boxes.

More detailed explanation will be added in the next revision.


3.4 The short explanation of the tables could be augmented with some
information on what they represent and an idea of how they will
be used. ( RFC 4382 provides a good example).


These points will be fixed in the next revision.


MIB definitions:
4. MIB syntax checking:
   smilint -s -e -l 5 mibs/MCAST-VPN-MIB 2>MCAST-VPN-MIB.txt


I fixed the most of the warnings except for "index-exceeds-too-large".
I think the restructuring of the MIB module may be required in order to
fix "index-exceeds-too-large".  Thus, I will need more time to work on this.


5. IMPORTS clause
MIB modules from which items are imported must be cited and included
   in the normative references.
   The conventional style is
 mplsStdMIB
FROM MPLS-TC-STD-MIB-- [RFC3811]


Fixed.


6. Please update the MODULE-IDENTITY. (There are no syntantic errors.)
6.1 'ORGANIZATION "IETF Layer-3 Virtual Private
  Networks Working Group."'
needs to be fixed to
'ORGANIZATION "IETF BESS Working Group."'
or something more appropriate.


Fixed.


6.2 CONTACT-INFO
Following the conventions (including indentation style) will
improve the readability. (e.g. RFC4382, RFC5132).


Fixed.


6.2 REVISION clause: follow the convention of RFC4131 sec 4.5
  REVISION"200212132358Z"  -- December 13, 2002
  DESCRIPTION "Initial version, published as RFC ."
   -- RFC Ed.: replace  with actual RFC number & remove this note:


Fixed.


6.3 OID assignment: follow the convention of RFC4131 sec 4.5
replace
  ::= { experimental 99 } --

[bess] Poll for adoption: draft-boutros-bess-vxlan-evpn-01

2016-06-20 Thread thomas.morin


Hello working group,

This email starts a two-week poll on adopting
draft-boutros-bess-vxlan-evpn-01 [1] as a Working Group Document.

Please state on the list if you support adoption or not (in both cases, 
please also state the reasons).


This poll runs until *July 4th*.

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 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.

No IPR has been disclosed against this Document.

If you are not listed as an author or 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 & Thomas
bess chairs

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

_

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 Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-overlay

2016-06-13 Thread thomas.morin


Hello Working Group,

(Please read carefully, this e-mail contains new elements compared to WG 
LCs we were doing in a still recent past.)


This email starts a Working Group Last Call on
draft-ietf-bess-evpn-overlay [1].

* Please read the document if you haven't read the most recent
version yet, and send your comments to the list, no later than
*27th of June*.

Note that this is *not only* a call for comments on the document, but 
also a call for support (or not) publishing this document as a Proposed 
Standard RFC.


* We are also polling for knowledge of any undisclosed IPR that applies 
to draft-ietf-bess-evpn-overlay-04, to ensure that IPR has been 
disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 
and 5378 for more details) prior to moving forward.

If you are listed as a document Author or 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 are also polling for knowledge of implementations of part or all of 
what this document specifies. This information is expected as per [2]. 
Please inform the mailing list, the chairs, or only one of the chairs.


* Finally, if you want to volunteer to be Document Shepherd for this 
document, please let us know.


Thank you,

Thomas/Martin


[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay
[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] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

2016-05-18 Thread thomas.morin


Hi John,

John.
When the tunnel encaps draft was first published it did not carry 
forward the RFC 5512 extended community and it did not propose to 
obsolete RFC 5512.  There was discussion of using the attribute 
defined in the tunnel encaps draft instead of the extended community 
and we decided to continue to use the extended community.  So, in that 
sense we are misaligned with the tunnel encaps draft.


As you confirm below, the last sentence is only true in the past tense.

Subsequently, however, the tunnel encaps draft decided to carry 
forward the extended community and to obsolete RFC 5512, so we were 
effectively covered by a grandfather clause.




Yes, precisely: given the content of the two drafts, there is no 
misalignment anymore.


Given the overlay draft’s tardiness, I don’t think that’s acceptable 
and would prefer to continue to refer to RFC 5512.




I do not think that the additional publication delay is a sound 
rationale for normatively refer to a spec that is known to become obsolete.
If it helps, the draft can keep an informative ref to RFC5512 and remind 
that it does not rely on anything specifically introduced by 
draft-ietf-idr-tunnel-encaps and not existing already in RFC5512.


-Thomas


2016-05-06, John E Drake:


However, even though I agreed yesterday to refer to the tunnel encaps 
draft instead of RFC 5512 we have an issue with doing this, viz, the 
overlay draft makes a normative reference to RFC 5512.  If we change 
the normative reference to the tunnel encaps draft we cannot publish 
the overlay draft until after the tunnel encaps draft has been published.


Given the overlay draft’s tardiness, I don’t think that’s acceptable 
and would prefer to continue to refer to RFC 5512.


Yours Irrespectively,

John

*From:*thomas.mo...@orange.com [mailto:thomas.mo...@orange.com]
*Sent:* Thursday, May 05, 2016 5:47 PM
*To:* IDR; BESS; draft-ietf-bess-evpn-over...@tools.ietf.org; Ali 
Sajassi (sajassi); Rabadan, Jorge (Nokia - US); 
draft-ietf-idr-tunnel-en...@tools.ietf.org; John E Drake
*Subject:* RE: [Idr] draft-ietf-bess-evpn-overlay vs. 
draft-ietf-idr-tunnel-encaps


Hi John,

I have a hard time reconciliating the fact that yesterday you were 
fine with having bess-evpn-overlay refer to idr-tunnel-encap instead 
of RFC5512, with the fact that you consider (below) the two docs "not 
aligned" for unicast.


Can you be more explicit in where the "misalignment" lies?

-Thomas

 John E Drake a écrit 

Thomas,

The overlay draft preceded the tunnel encaps draft and it was designed 
to handle a very specific problem, marrying the EVPN control plane to 
the VXLAN data plane draft and modulo the correction to section 9 it 
is internally consistent.


The tunnel encaps draft solves a more general problem and the WG 
decided a long time ago that the overlay draft was not going to be 
updated to use the mechanisms it details for unicast, so the overlay 
draft is already explicitly not in alignment with it.


This, plus the fact that the tunnel encaps draft explicitly puts the 
PMSI out of scope, leads me to the conclusion that the overlay draft 
should not be tweaked to be in alignment with a future solution for 
encoding VNIs for multicast.


Yours Irrespectively,

John

*From:*thomas.mo...@orange.com  
[mailto:thomas.mo...@orange.com]

*Sent:* Thursday, May 05, 2016 8:32 AM
*To:* John E Drake; IDR; BESS; 
draft-ietf-bess-evpn-over...@tools.ietf.org 
; Ali Sajassi 
(sajassi); Rabadan, Jorge (Nokia - US); 
draft-ietf-idr-tunnel-en...@tools.ietf.org 

*Subject:* RE: [Idr] draft-ietf-bess-evpn-overlay vs. 
draft-ietf-idr-tunnel-encaps


Thanks for the clarification on the intent around 
draft-ietf-bess-evpn-overlay. Then indeed section 9 needs some tidying 
up.


The issue that I think remain is that it would be much cleaner to 
explain how to use PMSI with overlay encaps in a spec not specific to 
E-VPN and in a way more consistent to what is done for unicast.


It seems if course that draft-ietf-idr-tunnel-encap should be the 
place, but that document currently explicitly makes PMSIs out of scope.


Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ?

-Thomas


 Rabadan, Jorge (Nokia - US) a écrit 

Fully agree John. That's what I meant, sorry if I didn't make myself 
clear. Section 9 needs clean up, yes.


Thanks,
Jorge

_
From: EXT John E Drake >
Sent: Wednesday, May 4, 2016 23:34
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. 
draft-ietf-idr-tunnel-encaps
To: IDR >, Ali Sajassi (sajassi) 
>, Rabadan, Jorge (Nokia 
- US) >, BESS >,

Re: [bess] WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

2016-05-09 Thread thomas.morin

Hi Jorge, all,

While looking at pending shepherd write-ups, I noticed that
draft-ietf-bess-evpn-etree is also asking for the same sub-type (0x04) [1].

Hopefully there will be a nice way to sort this out, but the lesson is
that we collectively fail to get the benefits that a First Come First
Server policy offers.

Best,

-Thomas

[1] https://tools.ietf.org/html/draft-ietf-bess-evpn-etree-04#section-8

Thomas Morin:

Hi Jorge, all,

Jorge:
11) IANA considerations: the authors have agreed to request the value
‘4’ for the Extended Community Sub-Type, since there are existing
implementations using that value.

Note that given the FCFS policy of this part of the registry [1], you
could ask for this value now without waiting and risking the value to
be assigned to something else.

The online form is: http://www.iana.org/form/protocol-assignment

Once this is done the text is the IANA section in the draft would
become "IANA has allocated Type 0x06/Sub-Type 0x04 for the 'EVPN Layer
2 attributes extended community' defined in section 3.1".

Best,

-Thomas

[1]
http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#evpn

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

Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

2016-05-05 Thread thomas.morin

Thanks for the clarification on the intent around draft-ietf-bess-evpn-overlay. 
Then indeed section 9 needs some tidying up.

The issue that I think remain is that it would be much cleaner to explain how 
to use PMSI with overlay encaps in a spec not specific to E-VPN and in a way 
more consistent to what is done for unicast.

It seems if course that draft-ietf-idr-tunnel-encap should be the place, but 
that document currently explicitly makes PMSIs out of scope.

Shouldn't this part of draft-ietf-idr-tunnel-encap be revisited ?

-Thomas


 Rabadan, Jorge (Nokia - US) a écrit 

Fully agree John. That's what I meant, sorry if I didn't make myself clear. 
Section 9 needs clean up, yes.

Thanks,
Jorge

_
From: EXT John E Drake >
Sent: Wednesday, May 4, 2016 23:34
Subject: RE: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps
To: IDR >, Ali Sajassi (sajassi) 
>, Rabadan, Jorge (Nokia - US) 
>, 
BESS >, 
>,
 EXT - thomas.mo...@orange.com 
>


Jorge,

We put the VNI value in the MPLS label field of the PMSI attribute for all 
service types, and we put a value in the Ethernet Tag field following the rules 
for each service type as described in 5.1.3 
(https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-5.1.3).

You're right that we need to clean up section 9.

Yours Irrespectively,

John

> -Original Message-
> From: Rabadan, Jorge (Nokia - US) [mailto:jorge.raba...@nokia.com]
> Sent: Wednesday, May 04, 2016 3:53 PM
> To: John E Drake; EXT - 
> thomas.mo...@orange.com; BESS; IDR; 
> draft-ietf-bess-evpn-
> over...@tools.ietf.org; Ali Sajassi (sajassi)
> Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. 
> draft-ietf-idr-tunnel-encaps
>
> Hi John,
>
> About this:
>
> [JD] For the IMET route the MPLS label field is carried in the PMSI 
> attribute. I think we need
> to ask everyone whether they used the Ethernet Tag or the PMSI attribute to 
> carry the VNI
>
>
> In case it helps, I’ve seen a few implementations running and they all encode 
> the VNI in the
> MPLS label field in the PTA. And a couple of them, encode the VNI in the 
> ethernet-tag, in
> addition to the MPLS label in the PTA. In any case, I think section 9 
> contradicts section 5.1.3
> and should be clarified.
>
> "5.1.3 Constructing EVPN BGP Routes
> 
> the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, and 
> **Inclusive
> Multicast Ethernet Tag** routes is used to carry the VNI or VSID."
>
> Thanks.
> Jorge
>
>
>
>
>
> On 5/4/16, 8:34 PM, "EXT John E Drake" 
> > wrote:
>
> >Thomas and Jorge,
> >
> >Snipped, comments inline.
> >
> >Yours Irrespectively,
> >
> >John
> >
> >> >
> >> >draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP
> >> >Encapsulation extended to encode the tunnel encap to use for BUM
> >> >traffic, but contrary to other E-VPN routes, relies on the Ethernet
> >> >Tag field of the NLRI to encode the VNI/VSID.
> >>
> >> [JORGE] This is certainly a leftover from an old version where the
> >> VNI/VSID was encoded in the ethernet tag for all the routes. The VNI
> >> should be encoded in the Label field in all the routes. This has to be 
> >> corrected.
> >>
> >> In fact, section 5.1.3 says:
> >>
> >> 5.1.3 Constructing EVPN BGP Routes
> >>
> >> 
> >>
> >> Accordingly, and
> >> specifically to support the option of locally assigned VNIs, the MPLS
> >> label field in the MAC Advertisement, Ethernet AD per EVI, and
> >> Inclusive Multicast Ethernet Tag routes is used to carry the VNI or
> >> VSID. For the balance of this memo, the MPLS label field will be
> >> referred to as the VNI/VSID field. The VNI/VSID field is used for
> >> both local and global VNIs/VSIDs, and for either case the entire 24-
> >> bit field is used to encode the VNI/VSID value.
> >>
> >> 
> >
> >
> >[JD] For the IMET route the MPLS label field is carried in the PMSI 
> >attribute. I think we
> need to ask everyone whether they
> >used the Ethernet Tag or the PMSI attribute to carry the VNI
> >
> >
> >> >>
> >> >> There are minor things that could be improved in
> >> >> draft-ietf-bess-evpn-overlay wrt. consistency with
> >> >> draft-ietf-idr-tunnel-encaps :
> >> >>
> >> >> * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it
> >> >> would be better that draft-ietf-bess-evpn-overlay refers to
> >> >> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512.
> >>
> >> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keeps

Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree

2016-03-29 Thread thomas.morin


Hi everyone,

This WG Last Call is now closed and the document will move to the next 
steps toward publication.


The modification mentioned below will be incorporated in next release.

Best,

-Thomas



2016-03-15, Ali Sajassi (sajassi):


Jeffrey,



On 2/1/16, 2:41 PM, "Jeffrey (Zhaohui) Zhang"  wrote:


Ali,

One more question about PBB-EVPN.

For the regular EVPN, section 3.3.2 talks about a situation where the
only traffic is BUM. There is no need for mac learning in that situation.

For PBB-EVPN, I assume this is also possible. With this, there is no need
to advertise per-ES B-mac addresses - a single pair of global root/leaf
B-mac addresses are enough.

Perhaps this can be mentioned for parity/completeness. Of course, this is
not a big deal and either way it's fine - but I do want to ask to confirm
my understanding.


We’ll do.

Cheers,
Ali



Jeffrey


-Original Message-
From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Monday, February 01, 2016 2:04 AM
To: Jeffrey (Zhaohui) Zhang ; EXT -
thomas.mo...@orange.com ; BESS ;
draft-ietf-bess-evpn-et...@tools.ietf.org
Subject: Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree

Hi Jeffrey,

Thanks for the review. Your comments helps tighten the draft some more.
I
have updated the draft and will publish it next (rev04). Majority of the
comments were editorial in nature for better clarifications. Since the
existing draft (rev03) reflects the consensus regarding our several
rounds
of discussions where we have taken care of the technical items, it is
consistent with our expectation of not seeing any major issue during the
LC. Please refer to my replies in line.

Cheers,
Ali


On 1/27/16, 5:26 PM, "BESS on behalf of Jeffrey (Zhaohui) Zhang"
 wrote:


I was involved in relevant discussions, and have reviewed once more for
this LC.

I support the publication, but with the following questions/comments.

2.1 Scenario 1: Leaf OR Root site(s) per PE

   ... If the number of EVIs is very large
   (e.g., more than 32K or 64K), then RT type 0 as defined in [RFC4360]
   SHOULD be used; otherwise, RT type 2 is sufficient.

RFC 7153 should be referenced for "Type 2".



Done.



Additionally, why is 32K mentioned? I can understand the 64k part.


Removed 32K since the example is clear enough with 64K



   ... the MPLS-encapsulated frames MUST be tagged with an
   indication of whether they originated from a Leaf AC or not.

Perhaps change the last line to "indication if they originated from a
Leaf AC"? Packets from a root AC are not tagged with a leaf indication.


OK. Better yet. It should say ³indication when they originated from a
leaf
AC².



   Other mechanisms for identifying whether an egress AC is a root or
   leaf is beyond the scope of this document.

Should "egress" be "ingress" in the above paragraph? Or simply removed?


Nice catch! It is ³ingress². It is now corrected.



   ... This Leaf MPLS label is advertised to other PE devices,
   using a new EVPN Extended Community called E-TREE Extended Community
   (section 5.1) along with an Ethernet A-D per ES route with ESI of
   zero and a set of Route Targets (RTs) corresponding to all the leaf
   ACs on the PE.

Perhaps change the last sentence to "... corresponding to all EVIs that
have leaf sites on the PE."


The second to last sentence of section 3.2.1 says the same thing. I
changed this sentence and removed the 2nd to last sentence.



3.2.3 BUM traffic originated from a multi-homed site on a leaf AC

   In this scenario, it is assumed that a multi-homed Ethernet Segment
   (ES) can have a mixed of both leaf and root ACs with each AC
   designating a subnet (e.g., a VLAN).

I understand that different VLANs on the same ES could be roots or
leaves. I suppose it's more important to say that for the same vlan,
different PEs on the same ES must have the same root/leaf designation.


That¹s given.



Perhaps the first sentence could be reworded as the following to

capture

the above point:

   While different ACs (VLANs) on the same ES could have different
   root/leaf designation (some being roots and some being leaves),
   the same VLAN does have the same root/leaf designation on all
   PEs on the same ES.


That¹s fine. It makes it more clear.



For the following:

   ... the PEs with Leaf sites perform MAC learning in the
   data-path over their Ethernet Segments, and advertise reachability

in

   EVPN MAC Advertisement routes which are imported only by PEs with at
   least one Root site in the EVI. A PE with only Leaf sites will not
   import these routes. PEs with Root and/or Leaf sites may use the
   Ethernet A-D routes for aliasing (in the case of multi-homed
   segments) and for mass MAC withdrawal per [RFC 7432].

The above seems to contradict with the recommendation in Section 2.2.

If

the context is the scenario described in section

Re: [bess] AD Review of draft-ietf-bess-multicast-damping-03 / -04

2016-03-21 Thread thomas.morin


Hi Alvaro,

We've posted -04 last week, based on the discussion we had.
Please tell us if you think this is ready to move forward.

Best,

-Thomas

2016-03-09, Alvaro Retana (aretana):
On 2/24/16, 11:58 AM, "Thomas Morin" > wrote:


Thomas:

Hi!

There are several places where we're still not in sync.  Please se below.

Maybe talking in person would be good.

Thanks!

Alvaro.




2016-02-23, Alvaro Retana (aretana):

The Abstract says that the procedures are "inspired from
BGP unicast route damping".  It seems to me that the intent is in
fact to adopt the algorithm from RFC2439.  However, the text is
not explicit/clear about that.

Saying so would I think actually be a misleading simplification,
the reader may miss the facts:
- that the proposal is to keep advertising a dampened multicast
VPN state up (in RFC2439, a dampened route stops being advertised)
- that the document is not BGP-specific but also specifies a
mechanism for the PIM FSM
- that only exponential decay is borrowed from RFC2439


This last sentence is what I meant above by "adopt the algorithm from 
RFC2439".  In other words, your proposal is to dampen the multicast 
state using the exponential decay algorithm defined in RFC2439, right?


In your response to my detailed comments there are statements that 
confuse me a little…  I put some more comments/questions below.




 1. As you all know, the history behind BGP damping has not been
without it being considered useless and even having
recommendations (from RIPE, for example) not to use it.


A few things are important to have in mind:
- the application context here is not the Internet
- multicast state propagates in a very different fashion
- the damping algorithm techniques is not the same
- the side-effects of damping unicast and damping multicast as
proposed here are fundamentally different: here damping causes no
impact on the service

Overall, I would say that the weaknesses of RFC2439 and the
recommendations in RFC7196 were well known by co-authors and that
we came to the conclusion that this multicast VPN would not suffer
from similar weaknesses.


How did you arrive at the default and maximum values?


By simulating with simple parameters and choosing conservative
low-risk values.
Considering that, by design, whatever the parameters, multicast
streams will be delivered unchanged and that the only thing you
tradeoff against is less dynamicity and a possibly slightly
increased bandwidth use, the default and maximum values do not
have to be perfectly tuned.


Please include this type of information (above) in the document. 
 Given the history of dampening in general, understanding the 
differences considered will go a long way and avoid more questions. ;-)




It concerns me that there are no known implementations (from the
Shepherd's report).

This concern is valid.
See below...


Because of that, I think this document would be better suited as
an Experimental RFC, with the explicit purpose of gaining
experience with the values and determine the impact in live
deployments (which then could support a standard version).
 Please consider changing the intended Status.

Let me go back to why this proposal started: some lab testing was
done showing that it was easy, in the lab, to create significant
overload on PE and RRs BGP stacks by flapping multicast state at
the edge.  Having a standard track to provide the appropriate
tooling against this DoS risk seems to me as making sense.  I
think that the proposed procedures are not close enough to the
solution and problem addressed by RFC2439 to say that RFC2439's
history is an argument to pass through an Experimental RFC first.


You might be right in this last point (the history of RFC2439 
shouldn't affect this document), specially given the explanation you 
gave earlier (where you talked about multicast being different, not 
intended for the Internet, etc.).


However, the rest of your answer (in that last paragraph) points only 
at experience in seeing the problem and testing the solution "in the 
lab".  Not outside the lab.  In other words, the motivation and 
problem both came from lab tests.  Augmented by the fact that there 
are no implementations it renews my proposal to make this document 
Experimental — as I said before, with the explicit purpose of gaining 
experience: is the problem observed in deployed networks, are the 
conditions there the same/similar as in the lab, are the parameters 
adequate.


Note that I don't think that an RFC has to be in the Standards Track 
to prove useful.



…




 1. Are you adopting the exponential decay algorithm from
RFC2439?  That seems to be what's happening because you are
not explicitly defining a new

Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02

2016-03-10 Thread thomas.morin


FYI, the disclosure has been made March 8th:
https://datatracker.ietf.org/ipr/2765/

-Thomas


Le 07/03/2016 13:35, Martin Vigoureux a écrit :

Hello Dhananjaya,
thanks for the notice.

WG,
I'll let this poll run for at least a week after the disclosure is made.
For those who have already stated their position please do not 
hesitate to communicate a revised position, if desired, in light of 
this upcoming IPR disclosure.


For the rest, please do comment on the list, as I'd like to read more 
comments/opinions from non-authors.


Martin

Le 07/03/2016 10:05, EXT Dhananjaya Rao (dhrao) a écrit :


Hello Martin, WG,

It came to our notice recently that there was an old IPR filing on an
earlier related draft that had not been submitted to the IETF. An IPR
statement has now been submitted and is in progress. This was an
inadvertent oversight, and we apologize for the late disclosure.

Regards,
-Dhananjaya



On 2/22/16, 8:58 AM, "BESS on behalf of Martin Vigoureux"
 wrote:


Hello working group,

This email starts a two-week poll on adopting
draft-fm-bess-service-chaining-02 [1] as a working group Document.

Please state on the list if you support adoption or not (in both cases,
please also state the reasons).

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

Note that IPR has been disclosed against an earlier version of this
document:
https://datatracker.ietf.org/ipr/2284/

Yet, we are *coincidentally* also polling for knowledge of any other
IPR that applies to this draft, 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 a document author or contributor please
respond to this email and indicate whether or not you are aware of any
relevant IPR.

The draft will not be adopted until a response has been received from
each author and contributor.

If you are not listed as an author or 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 & Thomas
bess chairs

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

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






___
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] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02

2016-02-05 Thread thomas.morin

Hello working group,

This email starts a two-week poll on adopting draft-snr-bess-evpn-proxy-arp-nd 
[1] as a working group item.

Please send comments to the list and state if you support adoption or not (in 
the later case, please also state the reasons).

This poll runs until **February 19th**.

*Coincidentally*, we are also polling for knowledge of any IPR that applies to 
this draft, 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 a document author or contributor please respond to 
this email and indicate whether or not you are aware of any relevant IPR.

The draft will not be adopted until a response has been received from each 
author and contributor.

If you are not listed as an author or 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 & Thomas
bess chairs

[1] https://tools.ietf.org/html/draft-snr-bess-evpn-proxy-arp-nd-02

_

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-hao-bess-inter-nvo3-vpn-optionc

2015-11-20 Thread thomas.morin


2015-11-20, John E Drake:

That presupposes that the group likes either of the two proposed solutions in 
your draft.


John, I think Lucy's "two solutions" was referring to 
draft-hao-bess-inter-nvo3-vpn-optionc solution and the 3-label Optionc 
MPLS/MPLS/UDP solution described by Wim.


-Thomas






-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Lucy yong
Sent: Friday, November 20, 2015 11:49 AM
To: EXT - thomas.mo...@orange.com; Henderickx, Wim (Wim);
bess@ietf.org
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Share my 2 cent.

Cloud providers want to tunnel its customer traffic through DC (AS)BR.
Option C is a way to realize it. Both solutions summarized by Thomas have no
change on WAN VPN side and seamlessly work with WAN VPN option C.
However, to support either solution, DC has to do some enhancement on DC
BR or ToR switch, etc, which dictates to different implementations within a
DC. Option C pro and con remains regardless what implementation is used in
a DC.

Two solutions should not coexist in one DC (does not make a sense), but it
does not matter if one DC operator prefers to use one solution and another
DC prefers to use another solution. Since there are many cloud providers
today, it is worth for the WG to document both solutions and point out the
implementation requirements on impacted components. Then, up to
vendors and operators to select a solution for their DC.

It does not make a sense for us to vote which solution is better here because
a better solution for a DC depends on many factors.


Lucy





-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of
thomas.mo...@orange.com
Sent: Friday, November 20, 2015 3:02 AM
To: Henderickx, Wim (Wim); bess@ietf.org
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

2015-11-19, Henderickx, Wim (Wim):

WH> I vote for a an evolution of switches/TORs that have proper
support for this. I hope some HW vendors of TOR chips shime in, but I
am told the MPLS solution is possible in the next generation chips
they are working on.


Well, it looks like the key questions are:
- when would ToR chips support MPLS/MPLS/UDP ?  (the generation that has
been released recently but not present in most shipping ToRs yet, the next
one ?)
- do we want an interim VXLAN-based solution ? (that will involve at best a
performance penalty with existing chips, and at worse impossible to
implement -- we haven't seen clear information in this thread)

-Thomas



Zhuangshunwan  :


Hi Diego,

Thanks for your comments. Pls see inline with [Vincent].

Vincent

*发件人:*BESS [mailto:bess-boun...@ietf.org] *代表 *Diego Garcia

del Rio

*发送时间:*2015年11月18日14:25 *收件人:*bess@ietf.org *主题

:*Re: [bess]

draft-hao-bess-inter-nvo3-vpn-optionc

Some comments from my side, I think the draft makes quite a few
assumptions on specific implementation details that are way too
general to be considered widely available. Most of the TOR devices
today already pay a double-pass penalty when doing routing of
traffic in/out of vxlan-type tunnels. Only the newest generation can
route into tunnels without additional passes. And are definitively
limited in being able to arbitrary select UDP ports on a per tunnel
basis. In fact, most are even limited at using more than one VNID
per "service" of sorts. [Vincent]: Yes, the new generation BCM
chipset has already supported VXLAN routing without additional
passes. For OVS/TOR, VXLAN encapsulation is more popular than
MPLSoGRE/UDP, and has better performance. The IP-addressed based
implementation which would, I assume, imply assigning one or more
CIDRs to a loopback interface on the ASBR-d is also quite arbitrary
and does not seem like a technically "clean" solution. (besides
burning tons of IPs). As a side-note, most PE-grade routers i've
worked with were quite limited in terms of IP addresses used for
tunnel termination and it wasn't that just a simple pool can be
used. [Vincent]: I think the larger VTEP IP address range on ASBR-d
has no limitations.
For the hardware on ASBR-d, it has capability to terminate multiple
VXLAN tunnels with arbitrary destination VTEP IP addresses. Wim's
mentions on cases where the Application itself, hosted in a
datacenter, would be part of the option-C interconnect, was
dismissed without much discussion so far, while, if we look in
detail at the type of users which will even consider a complex
topology like model-C its most likely users and operators very
familiar with MPLS VPNs in the WAN. Those type of operators will
most likely be very interested in deploying MPLS or WAN-grade
applications (i.e., virtual-routers or other
VNFs) in the DC and thus its highly likely that the interconnect
would not terminate at the NVE itself but rather the TS (the virtual
machine). Also, the use of UDP ports at random would imply quite
complex logic on the ASBR-d IMHO. Im not saying its impossible, but
since the received packet now not only has to be received on a
random

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

2015-11-20 Thread thomas.morin


2015-11-20, Haoweiguo:

WH> ok now we have not discussed the constraints some HW vendors have
with respect to global VNIDs. To make this work all VNID/Labels need
to be globally unique. Hm

> [weiguo2]:  In SDN scenario, a virtual

network normally is represented by a global VN ID or MPLS VPN Label
to simplify network management. I think it's not strange to allocate
global unique MPLS VPN Label or VN ID for a virtual network now.


In an option C scenario you have to take into account what is done in 
the WAN. Globally-assigned labels are not an option there at all.


-Thomas




The alternative approach, put forward by Wim, consist in using existing
Option-C with a variant of the 3-label variant relying on an
MPLS/MPLS/UDP-or-GRE encap (instead of the 3-label MPLS stack).  This
approach would not necessitate new standardized procedures, would
require less changes on ASBRs. However it is not supported today by
vswitches or ToRs (unless the bottom MPLS label is passed to the VM,
which I think would restrict the application to a subset of the
scenarios for which Option C is interesting). Having it supported in
vswitches may be a simple matter of writing the software, but ToR
support seems to require evolution in chipsets ; whether such a support
is likely to appear hasn't been discussed in the thread.

All in all, it seems there is no solution to cover an Option C scenario
with today's generation ToRs, and the question for tomorrow's generation
ToRs hasn't been really discussed.

Based on the above, I would think the question boils down to whether it
is desirable to specify an Option C variant usable with vswitches as
they are today and possibly usable with a performance hit with today's
ToRs chipsets, at the expense of a required evolution on ASBRs.  The
alternative requiring some evolution on vswitches and waiting for future
ToRs chipsets.

WH> I vote for a an evolution of switches/TORs that have proper support for 
this.
I hope some HW vendors of TOR chips shime in, but I am told the MPLS solution 
is possible in the next generation chips they are working on.
[weiguo2]:  I think it's better not to change current TOR hardware to realize 
option-C interconnection. No TOR hardware modification solution must be 
provided. But for future case, we can propose extra hardware requirements for 
TORs.
The other options requires baggage forever on the ASBR elements that does not 
bring value and it is better to avoid this and build an architecture which is 
future proof and more cost effective. My 2 cents


-Thomas




Zhuangshunwan  :


Hi Diego,

Thanks for your comments. Pls see inline with [Vincent].

Vincent

*发件人:*BESS [mailto:bess-boun...@ietf.org] *代表 *Diego Garcia del Rio
*发送时间:*2015年11月18日14:25
*收件人:*bess@ietf.org
*主题:*Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Some comments from my side,
I think the draft makes quite a few assumptions on specific
implementation details that are way too general to be considered
widely available.
Most of the TOR devices today already pay a double-pass penalty when
doing routing of traffic in/out of vxlan-type tunnels. Only the newest
generation can route into tunnels without additional passes. And are
definitively limited in being able to arbitrary select UDP ports on a
per tunnel basis. In fact, most are even limited at using more than
one VNID per "service" of sorts.
[Vincent]: Yes, the new generation BCM chipset has already supported
VXLAN routing without additional passes. For OVS/TOR, VXLAN
encapsulation is more popular than MPLSoGRE/UDP, and has better
performance.
The IP-addressed based implementation which would, I assume, imply
assigning one or more CIDRs to a loopback interface on the ASBR-d is
also quite arbitrary and does not seem like a technically "clean"
solution. (besides burning tons of IPs). As a side-note, most PE-grade
routers i've worked with were quite limited in terms of IP addresses
used for tunnel termination and it wasn't that just a simple pool can
be used.
[Vincent]: I think the larger VTEP IP address range on ASBR-d has no
limitations. For the hardware on ASBR-d, it has capability to
terminate multiple VXLAN tunnels with arbitrary destination VTEP IP
addresses.
Wim's mentions on cases where the Application itself, hosted in a
datacenter, would be part of the option-C interconnect, was dismissed
without much discussion so far, while, if we look in detail at the
type of users which will even consider a complex topology like model-C
its most likely users and operators very familiar with MPLS VPNs in
the WAN. Those type of operators will most likely be very interested
in deploying MPLS or WAN-grade applications (i.e., virtual-routers or
other VNFs) in the DC and thus its highly likely that the interconnect
would not terminate at the NVE itself but rather the TS (the virtual
machine).
Also, the use of UDP ports at random would imply quite complex logic
on the ASBR-d IMHO. Im not saying its impossible, but since the
received packet now

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

2015-11-17 Thread thomas.morin


Hi Wim, WG,

2015-11-16, Henderickx, Wim (Wim):


2015-11-13, Henderickx, Wim (Wim):
Thomas, we can discuss forever and someone need to describe 
requirements, but the current proposal I cannot agree to for the 
reasons explained.


TM> Well, although discussing forever is certainly not the goal, the 
reasons for rejecting a proposal need to be thoroughly understood.
WH> my point is what is the real driver for supporting a plain VXLAN 
data-plane here, the use cases I have seen in this txt is always where 
an application behind a NVE/TOR is demanding option c, but none of the 
NVE/TOR elements.




My understanding is that the applications  are contexts where overlays 
are present is when workloads (VMs or baremetal) need to be 
interconnected with VPNs. In these contexts, there can be reasons to 
want Option C to reduce the state on ASBRs.


In these context, its not the workload (VM or baremetal) that would 
typically handle VRFs, but really the vswitch or ToR.




2015-11-13, Henderickx, Wim (Wim):

TM> The right trade-off to make may in fact depend on whether you prefer:
(a) a new dataplane stitching behavior on DC ASBRs (the behavior 
specified in this draft)
or (b) an evolution of the encaps on the vswitches and ToRs to 
support MPLS/MPLS/(UDP or GRE)


WH> b depends on the use case


I don't get what you mean by "b depends on the use case".
WH> see my above comment. If the real use case is an application 
behind NVE/TOR requiring model C, than all the discussion on impact on 
NVE/TOR is void. As such I want to have a discussion on the real 
driver/requirement for option c interworking with an IP based Fabric.


Although I can agree than detailing requirements can always help, I 
don't think one can assume a certain application to dismiss the proposal.





I wrote the above based on the idea that the encap used in 
MPLS/MPLS/(UDP or GRE), which hence has to be supported on the ToRs 
and vswitches.
Another possibility would be service-label/middle-label/Ethernet 
assuming an L2 adjacency between vswitches/ToRs and ASBRs, but this 
certainly does not match your typical DC architecture. Or perhaps had 
you something else in mind ?


WH> see above. The draft right now also requires changes in existing 
TOR/NVE so for me all this discussion/debate is void.


No, the spec as it is can be implemented in its VXLAN variant with 
existing vswitches (e.g. OVS allows to choose the VXLAN destination 
port, ditto for the linux kernel stack).


(ToR is certainly another story, most of them not having a flexible 
enough VXLAN dataplane nor support for any MPLS-over-IP.)




WH> and depending on implementation you don’t need to change any of 
the TOR/vswitches.


Does this mean that for some implementations you may not need to 
change any of the TOR/vswitches, but that for some others you may ?


WH> any proposal on the table requires changes, so for me this is not 
a valid discussion


See above, the proposal in the draft does not necessarily need changes 
in vswitches.




Let me take a practical example : while I can quite easily see how to 
implement the procedures in draft-hao-bess-inter-nvo3-vpn-optionc 
based on current vswitch implementations of VXLAN, the lack of 
MPLS/MPLS/(UDP, GRE) support in commonplace vswitches seems to me as 
making that alternate solution you suggest harder to implement.


WH> I would disagree to this. Tell me which switch/TOR handles 
multiple UDP ports for VXLAN ?


I mentioned _v_switches, and many do support a variable destination port 
for VXLAN, which is sufficient to implement what the draft proposes.


-Thomas













From: Thomas Morin 
Organization: Orange
Date: Friday 13 November 2015 at 09:57
To: Wim Henderickx 
Cc: "bess@ietf.org" 
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim,

I agree on the analysis that this proposal is restricted to 
implementations that supports the chosen encap with non-IANA ports 
(which may be hard to achieve for instance on hardware 
implementations, as you suggest), or to context where managing 
multiple IPs would be operationally viable.


However, it does not seem obvious to me how the alternative you 
propose [relying on 3-label option C with an MPLS/MPLS/(UDP|GRE) 
encap] addresses the issue of whether the encap behavior is 
supported or not (e.g. your typical ToR chipset possibly may not 
support this kind of encap, and even software-based switches may not 
be ready to support that today).


My take is that having different options to adapt to various 
implementations constraints we may have would have value.


(+ one question below on VXLAN...)

-Thomas


2015-11-12, Henderickx, Wim (Wim):
On VXLAN/NVGRE, do you challenge the fact that they would be used 
with a dummy MAC address that would be replaced by the right MAC 
by a sender based on an ARP request when needed ?


Is the above the issue you had in mind about VXLAN and NVGRE ?

Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02' and draft-ietf-idr-tunnel-encaps-00

2015-11-13 Thread thomas.morin


John,

(Cc'ing IDR.)

2015-11-13, John E Drake:


I spoke with Eric and Ali and we would like to change both the
overlay  draft and the tunnel encaps drafts as follows.

For the overlay draft, replace this text in section 5.1.3:

"If the BGP Encapsulation extended community is not present, then
thedefault MPLS encapsulation or a statically configured encapsulation is

> assumed."


With the following:

"Note that the MPLS encapsulation tunnel type is needed in order to
distinguish between an advertising node that only supports non-MPLS
encapsulations and one that supports MPLS and non-MPLS
encapsulations. An advertising node that only supports MPLS
encapsulation does not need to advertise any encapsulation tunnel
types; i.e., if the BGP Encapsulation extended community is not
present, then either MPLS encapsulation or a statically configured
encapsulation is assumed."


Having more text to explain things in the overlay draft does not hurt.




For the tunnel encaps draft, replace this text in section 5:

"If the Tunnel Encapsulation attribute contains several TLVs (i.e.,
ifit specifies several tunnels), router R may choose any one of those

> tunnels, based upon local policy. If any of tunnels' TLVs contain the
> Color sub-TLV and/or the Protocol Type sub-TLV defined in [RFC5512], the

choice of tunnel may be influenced by these sub-TLVs."

With the following:

"If the Tunnel Encapsulation attribute contains several TLVs (i.e.,
ifit specifies several tunnels), router R may choose any one of those
tunnels, based upon local policy. If any of tunnels' TLVs contain the
Color sub-TLV and/or the Protocol Type sub-TLV defined in [RFC5512], the
choice of tunnel may be influenced by these sub-TLVs. Note that if none
of the TLVs specifies the MPLS tunnel type, a Label Switched Path SHOULD
NOT be used unless none of the TLVs specifies a feasible tunnel."


I think that the above will technically work.

*However* it would be a pity to *not* have the very useful clear-text 
explanation of the reason for the 'MPLS' type (what you propose to add 
above in the overlay draft) in  draft-ietf-idr-tunnel-encaps-00... why 
provide the smooth explanation for only one of the specs to which this 
'MPLS' type applies ?




We hope this is satisfactory.


Close, but not quite there yet :)

Best,

-Thomas







-Original Message-
From: Thomas Morin [mailto:thomas.mo...@orange.com]
Sent: Thursday, November 12, 2015 10:08 AM
To: John E Drake; bess@ietf.org
Cc: Eric Rosen
Subject: Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'

Hi John,

2015-11-12, John E Drake:


Why do you think it should be documented in Eric's draft rather than in the

EVPN Overlay draft?

The issue applies beyond the context of E-VPN overlay specs, and exist in
any context where different kinds of MPLS(/x) encaps can be mixed (E-VPN
non-overlay, IP VPNs), which is addressed by Eric's draft.

Best,

-Thomas





_

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-hao-bess-inter-nvo3-vpn-optionc

2015-11-13 Thread thomas.morin


Hi Wim,

2015-11-13, Henderickx, Wim (Wim):
Thomas, we need a solution that is implementable and will scale in 
control/data-plane. As such the solution I outline is standardised 
today and does not need new extensions in control/data-plane. Hence 
informational draft and can be implemented if there is market demand.


The above argument would fully make sense to me if support 
MPLS/MPLS/(UDP or GRE) was common place in ToRs or vswitches.


With respect to MAC you need to address both directions and does not 
make sense to manage this if it is not required/doe snot add value.


On VXLAN and the Ethernet header: it looks to me that addressing both 
direction is just a matter of documenting in the draft (if not already 
there) what is the expected behavior for VXLAN/NVGRE. But VXLAN and 
NVGRE are not the only encaps proposed in the specs anyway.


Compared to 3-label option C, my understanding is that the added-value 
is to not require the support of an MPLS/MPLS/(UDP or GRE) encap in ToRs 
and vswitches.


The right trade-off to make may in fact depend on whether you prefer:
(a) a new dataplane stitching behavior on DC ASBRs (the behavior 
specified in this draft)
or (b) an evolution of the encaps on the vswitches and ToRs to support 
MPLS/MPLS/(UDP or GRE)


Note that the 3-label option C approach with an MPLS/MPLS/(UDP or GRE) 
encap also requires the introduction of a control plane in the DC 
(possibly in an 'SDN' controller) to learn and advertise the middle MPLS 
label.  Whether one consider that the best path to a working solution 
may also depend on the context.


Best,

-Thomas




From: Thomas Morin >

Organization: Orange
Date: Friday 13 November 2015 at 09:57
To: Wim Henderickx >
Cc: "bess@ietf.org " >

Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim,

I agree on the analysis that this proposal is restricted to 
implementations that supports the chosen encap with non-IANA ports 
(which may be hard to achieve for instance on hardware 
implementations, as you suggest), or to context where managing 
multiple IPs would be operationally viable.


However, it does not seem obvious to me how the alternative you 
propose [relying on 3-label option C with an MPLS/MPLS/(UDP|GRE) 
encap] addresses the issue of whether the encap behavior is supported 
or not (e.g. your typical ToR chipset possibly may not support this 
kind of encap,  and even software-based switches may not be ready to 
support that today).


My take is that having different options to adapt to various 
implementations constraints we may have would have value.


(+ one question below on VXLAN...)

-Thomas


2015-11-12, Henderickx, Wim (Wim):
On VXLAN/NVGRE, do you challenge the fact that they would be used 
with a dummy MAC address that would be replaced by the right MAC by 
a sender based on an ARP request when needed ?


Is the above the issue you had in mind about VXLAN and NVGRE ?

WH> yes


I you don't mind me asking : why do you challenge that ?





_

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] One question about 'draft-ietf-bess-evpn-overlay-02' and draft-ietf-idr-tunnel-encaps-00

2015-11-13 Thread thomas.morin

Lucy,

The tunnel encap also describe how to use the extended community, in section 6.

Best,

-Thomas

 Lucy yong a écrit 

Hi Gunter,

Thank you to point to the right section. This overlay draft suggests to use 
Encapsulation extended community to indicate the type of data plane 
encapsulation to be used for all EVC routes. But the tunnel encap draft 
proposes to use tunnel encapsulation attribute + sub-TLVs to indicate the type 
of data plane encapsulation to be used for a prefix. Why do we want to have two 
solutions for the same space?

Since this overlay draft is not RFC yet, it is good for the community to make a 
decision on it, which keeps simple for the implementation. It is not hard to 
modify the draft to use tunnel encapsulation attribute indicating the type of 
data plane encapsulation for all EVC routes.

Regards,
Lucy

From: Gunter Van De Velde [mailto:guntervandeveld...@icloud.com]
Sent: Friday, November 13, 2015 1:46 PM
To: Lucy yong
Cc: thomas.mo...@orange.com; John E Drake; bess@ietf.org; IDR; Ali Sajassi 
(sajassi)
Subject: Re: [Idr] [bess] One question about 'draft-ietf-bess-evpn-overlay-02' 
and draft-ietf-idr-tunnel-encaps-00

Hi Lucy,

Did you take time to read
https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02
Its used pretty intense by DC orchestration platforms nowadays. Section 5.1 
provides more insight.

Brgds,
G/

Sent using CloudMagic 
Email
On Fri, Nov 13, 2015 at 7:12 PM, Lucy yong 
> wrote:

Hi John,

Since the tunnel encap draft goes with encap tunnel attribute and there was no 
deployment of RFC5512, IMO, we should deprecate encapsulation extended 
community to keep a consistent method.

Thus, should the overlay draft states if BGP tunnel encapsulate attribute is 
not present, 

Regards,
Lucy

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
thomas.mo...@orange.com
Sent: Friday, November 13, 2015 10:46 AM
To: John E Drake; bess@ietf.org
Cc: IDR; Ali Sajassi (sajassi); Eric Rosen
Subject: Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02' and 
draft-ietf-idr-tunnel-encaps-00

John,

(Cc'ing IDR.)

2015-11-13, John E Drake:
>
> I spoke with Eric and Ali and we would like to change both the overlay
> draft and the tunnel encaps drafts as follows.
>
> For the overlay draft, replace this text in section 5.1.3:
>
> "If the BGP Encapsulation extended community is not present, then
> thedefault MPLS encapsulation or a statically configured encapsulation
> is
> assumed."
>
> With the following:
>
> "Note that the MPLS encapsulation tunnel type is needed in order to
> distinguish between an advertising node that only supports non-MPLS
> encapsulations and one that supports MPLS and non-MPLS encapsulations.
> An advertising node that only supports MPLS encapsulation does not
> need to advertise any encapsulation tunnel types; i.e., if the BGP
> Encapsulation extended community is not present, then either MPLS
> encapsulation or a statically configured encapsulation is assumed."

Having more text to explain things in the overlay draft does not hurt.

>
> For the tunnel encaps draft, replace this text in section 5:
>
> "If the Tunnel Encapsulation attribute contains several TLVs (i.e.,
> ifit specifies several tunnels), router R may choose any one of those
> tunnels, based upon local policy. If any of tunnels' TLVs contain the  > 
> Color sub-TLV and/or the Protocol Type sub-TLV defined in [RFC5512], the
> choice of tunnel may be influenced by these sub-TLVs."
>
> With the following:
>
> "If the Tunnel Encapsulation attribute contains several TLVs (i.e.,
> ifit specifies several tunnels), router R may choose any one of those
> tunnels, based upon local policy. If any of tunnels' TLVs contain the
> Color sub-TLV and/or the Protocol Type sub-TLV defined in [RFC5512],
> the choice of tunnel may be influenced by these sub-TLVs. Note that if
> none of the TLVs specifies the MPLS tunnel type, a Label Switched Path
> SHOULD NOT be used unless none of the TLVs specifies a feasible tunnel."

I think that the above will technically work.

*However* it would be a pity to *not* have the very useful clear-text 
explanation of the reason for the 'MPLS' type (what you propose to add above in 
the overlay draft) in  draft-ietf-idr-tunnel-encaps-00... why provide the 
smooth explanation for only one of the specs to which this 'MPLS' type applies ?

>
> We hope this is satisfactory.

Close, but not quite there yet :)

Best,

-Thomas

>
>> -Original Message-
>> From: Thomas Morin [mailto:thomas.mo...@orange.com]
>> Sent: Thursday, November 12, 2015 10:08 AM
>> To: John E Drake; bess@ietf.org
>> Cc: Eric Rosen
>> Subject: Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'
>>
>> Hi John,
>>
>> 2015-11-12, John E

[bess] IPR issue resulting in an Extended Poll for adoption: draft-hao-bess-inter-nvo3-vpn-option

2015-11-12 Thread thomas.morin


Hi working group,

IPR [1] has been disclosed on draft-hao-bess-inter-nvo3-vpn-optionc 
during the call for adoption (2015-10-26).


We regret that this disclosure came this late in the process, and we 
have to let the working group comment on this call with full awareness 
of existing IPR.


This call for adoption is thus extended to **November 26th**.

In parallel, we will work to understand whether this disclosure is late 
compared to expectations raised in RFC3979 (we haven't yet determined 
how the set of authors intersect with the set of inventors on the patent).


Best,

-Thomas

[1] https://datatracker.ietf.org/ipr/2700/



22/10/2015, Thomas Morin :

Hello working group,

This email starts a two-week poll on adopting
draft-hao-bess-inter-nvo3-vpn-optionc-03 [1] as a working group item.

Please send comments to the list and state if you support adoption or
not (in the later case, please also state the reasons).

This poll runs until **November 13th**.
(3 weeks to account for the busy IETF week)


*Coincidentally*, we are also polling for knowledge of any IPR that
applies to this draft, 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 a document author or contributor please
respond to this email and indicate whether or not you are aware of any 
relevant IPR.


The draft will not be adopted until a response has been received from
each author and contributor.

If you are not listed as an author or 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 & Thomas
bess chairs

[1] https://tools.ietf.org/html/draft-hao-bess-inter-nvo3-vpn-optionc-03



















___
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] draft-hao-bess-inter-nvo3-vpn-optionc

2015-11-12 Thread thomas.morin


Hi Wim,

Thanks for your feedback.

With my co-chair hat, let met ask a few questions for the sake of well 
understanding the issue you raise.


Henderickx, Wim (Wim):
I don’t support the adoption of this draft as a WG. There is a major 
flaw in this proposal:
Basically the encapsulation of VXLAN/NVGRE is incompatible with MPLS 
IP-VPNs. VXLAN/NVGRE contains a MAC address and IP-VPNs don’t.


This comment only relates to a subset of the encaps proposed in the 
solution, right ?

(e.g. does not apply to MPLS/GRE and MPLS/UDP)

On VXLAN/NVGRE, do you challenge the fact that they would be used with a 
dummy MAC address that would be replaced by the right MAC by a sender 
based on an ARP request when needed ?



The draft [...] introduces a lot of complexity for nothing.


Can you detail what you consider is a lot of complexity ?



If we want to describe a model C VPN interconnect with a IP fabric in 
a DC I recommend to do an informational RFC that describes this using 
VXLAN-GPE, MPLSoGRE or MPLSoUDP encapsulation and retain the E2E MPLS 
label we defined in RFC4364.


My understanding of this draft's value is the fact that it avoids having 
service-label related state (forwarding and BGP state) on the routers at 
the DC-WAN border.  This is one of the typical property of 4364 option 
C.It is not obvious at all to me, based on existing spec, how to get 
the same benefit on the DC-side router in an architecture where the 
DC-side router also terminates the overlay tunnels.


Do you challenge the goal itself (not having service-label related state 
on the overlay tunnels router) or suggest that the same benefit can be 
achieved with less complexity ?


-Thomas

_

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] The BESS WG has adopted draft-hao-bess-inter-nvo3-vpn-optionc (not yet, in fact)

2015-11-02 Thread thomas.morin

Please ignore this bogus automated email: the document is just being 
called for adoption, and no decision will be taken before the call for 
adoption is over.


-Thomas

2015-11-02, IETF Secretariat:


The BESS WG has adopted draft-hao-bess-inter-nvo3-vpn-optionc (entered by
Thomas Morin)

The document is available at
https://datatracker.ietf.org/doc/draft-hao-bess-inter-nvo3-vpn-optionc/


Comment:
This poll runs until **November 13th**.




_

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 adoption: draft-singh-bess-bgp-vpls-control-flags

2015-10-05 Thread thomas.morin


Authors of draft-singh-bess-bgp-vpls-control-flags, working group,

The support base for this proposal is not large.
Before adopting this draft, we would like hear people actually 
experiencing pain related to not solving this issue and hear about 
implementations in actual products.


Let's consider this poll for adoption open until we hear more.

Best,

Thomas/Martin


thomas.mo...@orange.com :

Hello working group,

This email starts a two-week poll on adopting
draft-singh-bess-bgp-vpls-control-flags-01 [1] as a working group item.

Please send comments to the list and state if you support adoption or
not (in the later case, please also state the reasons).

This poll runs until **September 29th**.


*Coincidentally*, we are also polling for knowledge of any IPR that
applies to this draft, 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 a document author or contributor please
respond to this email and indicate whether or not you are aware of any 
relevant IPR.


The draft will not be adopted until a response has been received from
each author and contributor.

If you are not listed as an author or 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 & Thomas
bess chairs

[1] https://tools.ietf.org/html/draft-singh-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] Poll for adoption: draft-morin-bess-mvpn-fast-failover

2015-10-02 Thread thomas.morin


Martin Vigoureux:


*If you are listed as a document author or contributor* please respond 
to this email and indicate whether or not you are aware of any 
relevant IPR.
The draft will not be adopted until a response has been received from 
each author and contributor.
If you are not listed as an author or contributor, then please 
explicitly respond only if you are aware of any IPR that has not yet 
been disclosed in conformance with IETF rules.


Not aware of any such IPR.

Best,

-Thomas

_

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 draft-ietf-bess-ir

2015-09-29 Thread thomas.morin


Hi Eric,


2015-09-28, Eric C Rosen:

 From the draft:

 "This document does not provide any new protocol elements or
procedures"

I think we can agree that it does not specify any new protocol elements.

 > [Thomas] Sections 3, 4.1.1 and 9, at least, introduce what I think
can fairly be considered new procedures.

I don't see anything in section 3 or 4.1.1 that I would call "new
procedures".

However, your point is well-taken about section 9, as RFC6514 does not
really address the use of timers to achieve "make before break"
functionality.  On the other hand, RFC 6513 section 7 does specify the
use of timers when switching a flow from one P-tunnel to another, so the
use of timers is not a new addition.

When we started implementing ingress replication, we found that it
wasn't always very clear how to apply the procedures of RFC6514 when
ingress replication is being used.  The purpose of this draft is to pull
together into one place all the procedures relevant to ingress
replication, and to explain clearly how ingress replication is done
using the procedures of RFC6514.  The focus is on getting it clear
enough to increase the likelihood of multi-vendor interoperability.  We
really tried hard to avoid creating any new IR-specific procedures,
though section 9 may be an exception.


And I fully agree that the specs do fit this intention, but one 
exception is enough to make the assertion wrong.


I would suggest to distinguish intent and strict truth, e.g. by 
replacing the quoted sentence by "To bring the required clarifications, 
this document updates the behavior specified by RFC6514, but does so 
without introducing new protocol elements or any fundamentally new 
procedures". Or something along these lines.




 From the draft:

 "4.1. Advertised P-tunnels The procedures in this section apply
when the P-tunnel to be joined has been advertised in an S-PMSI A-D
route, an Inter-AS I-PMSI A-D route, or an Intra-AS I-PMSI A-D route."

 > For sake of clarity and avoid any misinterpretation, can you please
add ", and the PMSI Tunnel Attribute is of type Ingress Replication"

Well, section 4 is called "How to Join an IR P-tunnel", and the entire
draft is exclusively about IR P-tunnels.  If you think that is not
clear, perhaps the sentence above should just say "when the IR P-tunnel
to be joined has been ..."


Yes, that would be just fine.



 From the draft:

 "Note that if a set of IR P-tunnels is joined in this manner, the
"discard from the wrong PE" procedures of [RFC6513] section 9.1.1 cannot
be applied to that P-tunnel.  Thus duplicate prevention on such IR
P-tunnels requires the use of either Single Forwarder Selection
([RFC6513] section 9.1.2) or native PIM procedures ([RFC6513] section
9.1.3).

[Thomas] I would suggest rewording with "Note that, in the general case,
..."  and "...unless the tunneling technique relies on an IP transport,
which may allow the identification of the PE sourcing the traffic".

It is certainly true in theory that one could use an IP encapsulation in
this way, but in practice it creates a couple of complications:

- I think it presupposes that the IP source address field of the
tunneled packets contains the same IP address that the ingress PE puts
in the Global Administrator field of the VRF Route Import EC that it
attaches to the unicast routes that it distributes.


(I guess it could use a different one and be made to advertise which one 
to expect in a BGP attribute.)



- All the egress PEs need to implement this IP address check in the data
plane forwarding path.


Yes, and this is already true in RFC6513.


While using the IP encapsulation in this way is a possible option, it
has never seemed like a very attractive option, and as far as I know, no
one has implemented it.

To avoid the need for an option like this, I always recommend that if
one wants to use IR by default, one should advertise the IR P-tunnels in
a (C-*,C-*) S-PMSI A-D route rather than in an Intra-AS I-PMSI A-D
route.  One can still use IP tunnels if one wants, but the "discard from
the wrong PE" procedures would be based on the MPLS label that is
carried by the IP payload.


I would tend to agree that the choice made makes sense.

It is however better to not make it look like the only possible design 
choice ("'discard from the wrong PE' procedures of [RFC6513] section 
9.1.1 cannot be applied to that P-tunnel" is ), to avoid misleading 
future readers.


I think that at least "[procedure xyz] cannot be applied to that 
P-tunnel, in the general case," would be better.




Another problem with using the IP header to apply the "discard from the
wrong PE" procedure is that it will not easily generalize to the case of
extranet.  (Still another problem would be that it is just one more
unnecessary option.)

I could add some text explaining this, and explaining why it is not
recommended to use the IP header to apply the "discard from the wrong
PE" procedure.


Yes, this would be useful to document

Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02

2015-09-28 Thread thomas.morin


Hi Alvaro,

[resending, because I had mailer daemon from 
junipernetworks.onmicrosoft.com]


2015-09-24, Alvaro Retana (aretana):
Also, some of the text [...] may not be accesible to the average 
reader,...


As a side note, while what you wrote is true, I would say that it will 
be hard to fix.
Most mVPN-related specs are deemed to remain fairly inaccessible to 
somebody not already familiar with RFC6513/6514, which does not fit any 
conceivable definition of an average reader... ;-)


-Thomas






























_

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] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02

2015-09-28 Thread thomas.morin


Jeffrey, all,

[resending this one too...]

(below)

2015-09-25, Jeffrey (Zhaohui) Zhang:


*From:*Alvaro Retana (aretana) [mailto:aret...@cisco.com]

 5. Section 4. (Security Considerations)  Are there really no security
considerations?

  * Section 3.1. (Control State)   Says that: "To speed up
convergence…PEy MAY advertise a Leaf A-D route even if does
not choose PEx as its Upstream PE…With that, it will receive
traffic from all PEs, but some will arrive with the label
corresponding to its choice of Upstream PE while some will
arrive with a different label, and the traffic in the latter
case will be discarded.”  I’m assuming that all the traffic
(specially the discarded one) belongs to the same VPN, so
there’s no danger of leaking information, right?  It might be
worth including something in the Security Consideration so
that it’s easier for the readers (Security Directorate, for
example) to grasp the context.

Zzh> There is indeed no new issues. The quoted text refers to the 
possible arrival of duplication for the same flow that the receiving 
PEs need to receive, and they will be discarded anyway. There is no 
deliver of duplication to CEs, and certainly there is no leaking. I am 
not sure if that needs to be called out.





I agree on the analysis.
Refering to both RFC6513 and RFC6514 (instead of RFC6514 alone) is the 
only improvement I can think of.


Best,

-Thomas

_

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] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02

2015-09-28 Thread thomas.morin


Hi Alvaro,

2015-09-24, Alvaro Retana (aretana):
Also, some of the text [...] may not be accesible to the average 
reader,...


As a side note, while what you wrote is true, I would say that it will 
be hard to fix.
Most mVPN-related specs are deemed to remain fairly inaccessible to 
somebody not already familiar with RFC6513/6514, which does not fit any 
conceivable definition of an average reader... ;-)


-Thomas


_

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] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02

2015-09-28 Thread thomas.morin


Jeffrey, all,

(below)

2015-09-25, Jeffrey (Zhaohui) Zhang:


*From:*Alvaro Retana (aretana) [mailto:aret...@cisco.com]

 5. Section 4. (Security Considerations)  Are there really no security
considerations?

  * Section 3.1. (Control State)   Says that: "To speed up
convergence…PEy MAY advertise a Leaf A-D route even if does
not choose PEx as its Upstream PE…With that, it will receive
traffic from all PEs, but some will arrive with the label
corresponding to its choice of Upstream PE while some will
arrive with a different label, and the traffic in the latter
case will be discarded.”  I’m assuming that all the traffic
(specially the discarded one) belongs to the same VPN, so
there’s no danger of leaking information, right?  It might be
worth including something in the Security Consideration so
that it’s easier for the readers (Security Directorate, for
example) to grasp the context.

Zzh> There is indeed no new issues. The quoted text refers to the 
possible arrival of duplication for the same flow that the receiving 
PEs need to receive, and they will be discarded anyway. There is no 
deliver of duplication to CEs, and certainly there is no leaking. I am 
not sure if that needs to be called out.





I agree on the analysis.
Refering to both RFC6513 and RFC6514 (instead of RFC6514 alone) is the 
only improvement I can think of.


Best,

-Thomas

_

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] Prague meeting draft minutes and recording

2015-08-03 Thread thomas.morin


Hi everyone,

Here are the draft minutes for our Prague meeting:
https://www.ietf.org/proceedings/93/minutes/minutes-93-bess

Please send us any correction or clarification you think is useful (they 
will become final 2015-08-14).


Thanks to the Meetecho team, the full meeting recording with slides and 
audio is even better than for previous meetings.
This is available at: 
http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF93_BESSchapter=chapter_1


Enjoy!

-Thomas/Martin

_

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] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)

2015-07-29 Thread thomas.morin



Hi Eric,

2015-07-28, Eric C Rosen:

* to allow multicast support in the context of RFC6514/6513,
RFC7117, and RFC7432 with a consistent way of advertising the
encapsulations,I think that  draft-rosen-idr-tunnel-encaps-00
section 2.4 should also consider as a labelled address family an
AFI/SAFI that may be associated to a PMSI Tunnel attribute, in
which case the embedded label is the Label in the PMSI Tunnel
Attribute

* consistently with the above,  1/5 and 25/8 should also be added
as authorized families in section 3


In the particular case where (a) the PMSI Tunnel attribute specifies
Ingress Replication, and (b) the PMSI Tunnel attribute carries an
MPLS label, then I think it might well make sense to include a
Tunnel Encapsulation attribute.  This would allow one to use an
MPLS-in-something-else encapsulation to do ingress replication.


Or even a payload-in-something-else, but yes, we agree: covering ingress 
replication with the BGP Tunnel Encap makes sense (and will actually be 
required by draft-ietf-bess-evpn-overlay).



In other cases, I don't really know what it would mean to have both
a PMSI Tunnel attribute and a Tunnel Encapsulation attribute on the
same route.  Suppose the PMSI Tunnel attribute specifies an
mLDP-created P2MP LSP, and the Tunnel Encapsulation attribute
specifies a VXLAN tunnel. What would that mean?


For sake of simplicity I omitted that aspect in my initial comment, but
yes indeed, not everything does make sense.

I think that in the case where the Tunnel Type is an IP Multicast tree
*without* the PMSI Tunnel Attribute Label field being set, jointly
advertising a BGP Tunnel Encap attribute could be defined, for the
MPLS-in-UDP or VXLAN types, as meaning I will send PMSI traffic as
MPLS-in-UDP or VXLAN (rather than the GRE default).



Another issue is the following.  In MVPN the transmitter specifies
the tunnel type, but the Tunnel Encapsulation attribute is most
useful in scenarios where the receiver needs to specify the tunnel
type.  (Ingress replication is an exception, since it requires both a
multipoint tunnel and a set of unicast tunnels, as is discussed in
draft-ietf-bess-ir.  So in that particular case, it makes sense for
the transmitter to specify the former and the receivers to specify
the latter.)

It's also worth noting that except for ingress replication,  a label
is specified in the PMSI Tunnel attribute only if traffic from
multiple VPNs is going to share the same multicast tunnel; this is
not really analogous to the label that is embedded in the case of
SAFI 4 (Labeled IP Unicast) or SAFI 128 (Labeled VPN-IP
unicast).


A possibility would be to state that if Tunnel Type is an IP Multicast
tree *with* the PMSI Tunnel Attribute Label field set, jointly
advertising a BGP Tunnel Encap attribute could be used to allow
MPLS-in-GRE (or UDP, or VXLAN) and hence allow carrying the multicast
traffic of multiple VPNs in one IP multicast tree.

These proposals would allow to give a meaningful semantic to the BGP
Tunnel Encap attribute with mVPN or E-VPN PMSI routes, independently of
any consideration on how relevant these encapsulations would be.



* draft-ietf-bess-evpn-overlay currently relies on the Tunnel
Encap Extended Community to advertise the use of MPLS-over-GRE or
VXLAN or NVGRE, and section 5.1.3 of that draft specifies that the
VNI to use is the value in the Label field of the route -- this is
I believe /nearly/ inline with draft-rosen-idr-tunnel-encaps, but
the devil is in the details:   if I read correctly
draft-rosen-idr-tunnel-encaps-01 Section 7.2, the behavior
consisting in using the embedded label as the VNI requires
advertising a BGP Tunnel Encap  Attribute with an Embedded Label
Handling Sub-TLV with value 2, or not advertising a BGP Tunnel
Encap at all (nor using the Tunnel Encapsulation ExtendedCommunity
which is made semantically equivalent by section 6) ---  it thus
seems to me that one of the two drafts needs something to allow
proper compatibility


Right now the Tunnel Encaps draft specifies that omitting the
Embedded Label Handling Sub-TLV is equivalent to including an
Embedded Label Handling Sub-TLV with value 1.  The simplest fix would
be to change this so that omitting the Sub-TLV is equivalent to
including a Sub-TLV with value 2.


I think this is a good idea.


Or would this introduce an incompatibility with some other EVPN
draft? ;-)


None that I'm aware of.


With a lesser priority, I have a few other comments as well:

* I think the intent of the MPLS codepoint 10 for tunnel type, as
defined in draft-ietf-bess-evpn-overlay, intends to indicate the
ability to receive plain MPLS in a context where other encaps are
advertised (if you advertise only one non-MPLS encap, it means you
support this encap but not MPLS) -- this I think would be nice to
capture in draft-rosen-idr-tunnel-encaps


I think that makes sense.


Ok.



* about the Remote Endpoint sub-TLV: why allow that an AF of 0
means use next-hop address, but still require

Re: [bess] comments on draft-hao-bess-inter-nvo3-vpn-optionc

2015-07-24 Thread thomas.morin


Hi Weiguo,

Haoweiguo :

Thomas:

Having to configure as many IPs on ASBR-d as there are PEs in the WAN
seems to me as being a very strong drawback. I think that it would be
better to use a combination of one ore more ASBR-d IP address and
multiple destination UDP ports, to reduce the configuration overhead on
ASBR-d related to having multiple addresses. With multiple UDP ports one
IP will be enough for large number of PEs (e.g among the 64k possible
ports, you can easily take a few thousands and cover a deployment with
thousands of PEs).  For an MPLS-over-GRE encap, you could use the GRE
Key field instead. The only encap which I think cannot be addressed this
way and would thus require multiple IP destination addresses would be
NVGRE (because it already uses the GRE Key field).


[weiguo]: For VXLAN encapsulation, the destination UDP port is fixed, so it's 
hard for us to allocate different UDP port for each remote PE.


While an IANA assigned port is available as a default, nothing prevents 
a box from mapping a range of UDP ports so that any port in this range 
is processed as VXLAN.As long as you have a way to let the sender 
know about which port to use, this is fine.  The good news is that 
draft-rosen-idr-tunnel-encaps introduces a way to advertise which port 
to use when the port is other than the standard.



  Because normally remote PEs number is not so large, so the IP addresses on 
ASBR-d won't consume so much.


Networks with thousands of PEs are not uncommon, and this is a number 
high enough to make allocating and configuring all these IPs a 
significant drawback.   By comparison playing with UDP ports is cheap 
and easy.


-Thomas


_

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] comments on draft-hao-bess-inter-nvo3-vpn-optionc

2015-07-23 Thread thomas.morin


Hi,

(Without my chair hat,) I have the following comments to offer on 
draft-hao-bess-inter-nvo3-vpn-optionc-01.


I think the proposal has a merit in that it defines how to do Option C 
in a context where we want one of the AS to use an IP transit rather 
than MPLS, and this is done preserving the scaling advantages of Option 
C over Option B for ASBRs.


I have a few comments though. on things that would deserve to be improved.

The term multi-hop EBGP designates an eBGP session between peers 
separated by multiple IP hops, in an inter-AS Option C context, sessions 
between RRs of the two ASes are multi-hop eBGP, but the session between 
ASBRs to carry RFC3107 routes is *not* multi-hop. However, your draft 
wrongly refers to sessions between PEs as multi-hop EBGP, which I 
found very confusing.  (Section 4, Section 5.1)


Having to configure as many IPs on ASBR-d as there are PEs in the WAN 
seems to me as being a very strong drawback. I think that it would be 
better to use a combination of one ore more ASBR-d IP address and 
multiple destination UDP ports, to reduce the configuration overhead on 
ASBR-d related to having multiple addresses. With multiple UDP ports one 
IP will be enough for large number of PEs (e.g among the 64k possible 
ports, you can easily take a few thousands and cover a deployment with 
thousands of PEs).  For an MPLS-over-GRE encap, you could use the GRE 
Key field instead. The only encap which I think cannot be addressed this 
way and would thus require multiple IP destination addresses would be 
NVGRE (because it already uses the GRE Key field).


Last, to setup the overlay segment of the PE-to-NVE transit path, I 
think that, rather than introducing a new SAFI, it would make sense to 
use a plain IP route to /32 of each WAN PE advertising an IPVPN route, 
associated to a BGP tunnel encap attribute indicating which encap to 
use, with which destination IP address and which UDP Port / GRE key to 
use.  (this combination of BGP Tunnel Encap attribute with a 1/1 
AFI/SAFI is not allowed by RFC5512, but will be allowed assuming 
draft-rosen-idr-tunnel-encaps progresses in IDR).


Best,

-Thomas


_

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] Fwd: Routing Area YANG Coordinators Wiki

2015-07-21 Thread thomas.morin




_

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.

---BeginMessage---
Hi All,
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangCoord
Above is a link to the Routing Area YANG Coordinators area that was established 
earlier this year to help track the YANG models being developed in the iETF 
Routing Area.
There are a number of resources on the wiki pages, but the coordinators would 
like to draw attention specifically to the “Summary of Routing Area YANG Drafts”
(The section with the big red text * == YANG MODEL AUTHORS LOOK HERE == *”

These tables are intended to help summarize and track the YANG drafts in the 
Routing Area.Draft authors and WG Chairs are requested to keep the wiki 
table updated as drafts are created and progressed through the document 
development process.  Instructions for completing a table row for a YANG model 
draft are provided.

Questions on the instructions should be directed to the Routing Area YANG 
Coordinators (Qin Wubill...@huawei.commailto:bill...@huawei.com and David 
Sinicrope david.sinicr...@ericsson.commailto:david.sinicr...@ericsson.com )

Thanks for your help and support keeping this information up to date.

Thanks,
Dave and Qin
___
routing-discussion mailing list
routing-discuss...@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussion
---End Message---
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Please send you presentations for Prague

2015-07-19 Thread thomas.morin


To those who present during our session tomorrow,

It seems some of the slides haven't been sent yet, and we are close to 7pm.
Be ready to see your slot cancelled if you don't send them tonight.

Best,

-Thomas

PS: if you have sent your slides already, but only to one of the chairs, 
please send them again to both chairs (bess-cha...@ietf.org)


15/07/2015 13:29, Martin Vigoureux :

all,

Prague is in few days now, and BESS is on Monday.
Please send your presentation material before Sunday 7pm, local time 
at the latest.
Please make sure it is consistent with the time allocated to it in the 
agenda:

https://www.ietf.org/proceedings/93/agenda/agenda-93-bess

Thank you
MT

___
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] Agenda for our meeting in Prague

2015-07-09 Thread thomas.morin


Hi everyone,

Face to face time is a scarce resource and we had to make choices.

We would like to insist that we think all authors should using the 
mailing-list *more* and *earlier*, to allow dedicating meeting time to 
discussions that will most benefit from happening face to face.


What is, very likely, the final agenda for our meeting is at:
https://www.ietf.org/proceedings/93/agenda/agenda-93-bess
(the slots we added to the draft agenda are highlighted below)

Thanks you for your understanding,

-Thomas  Martin


--- agenda00.txt
+++ agenda01.txt
@@ -10,9 +10,15 @@
 draft-fm-bess-service-chaining-01
 Dhananjaya, 10'

+Heads up on BESS-related work-in-progress
+Chairs, 5'
+

 draft-zzhang-bess-evpn-bum-procedure-updates
 Jeffrey, 15'

+draft-sajassi-bess-evpn-virtual-eth-segment
+Ali, 5'
+

 draft-rabadan-bess-evpn-optimized-ir-01
 Jorge, 10'

@@ -28,3 +34,6 @@

 draft-ietf-bess-evpn-etree
 Ali, 10'

+
+draft-ietf-bess-dci-evpn-overlay-01
+Jorge, 5'



thomas.mo...@orange.com :

Hi everyone,

BESS will meet in roughly two weeks in Prague (Monday 15:20-17:20).

Here is the *draft* agenda:
https://www.ietf.org/proceedings/93/agenda/agenda-93-bess

We won't be able to satisfy all the requests for slots and we have 
already made some choices.
However, note well that this draft agenda is really not final, we 
still have 10-15 non allocated time.

We will post a final agenda before the deadline, hopefully this week.

Best,

-Thomas  Martin



















_

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 agenda for our meeting in Prague

2015-07-07 Thread thomas.morin


Hi everyone,

BESS will meet in roughly two weeks in Prague (Monday 15:20-17:20).

Here is the *draft* agenda:
https://www.ietf.org/proceedings/93/agenda/agenda-93-bess

We won't be able to satisfy all the requests for slots and we have 
already made some choices.
However, note well that this draft agenda is really not final, we still 
have 10-15 non allocated time.

We will post a final agenda before the deadline, hopefully this week.

Best,

-Thomas  Martin

WG Status, 10 min

draft-shah-pals-mpls-l2vpn-yang
Patrice, Himanshu, Robin, 10'
+ 5' on E-VPN Yang

draft-anshuverma-bess-vpls-best-site-id
Anshu Verma, 10'

draft-fm-bess-service-chaining-01
Dhananjaya, 10'

draft-zzhang-bess-evpn-bum-procedure-updates (not published)
Jeffrey, 15'

draft-rabadan-bess-evpn-optimized-ir-01
Jorge, 10'

draft-snr-bess-evpn-proxy-arp-nd-01
Jorge, 10'

E-VPN LSP-Ping
draft-jain-bess-evpn-lsp-ping-00
Parag, 10'

draft-ietf-bess-evpn-vpws
Sami, 5'

draft-ietf-bess-evpn-etree
Ali, 10'




_

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] Status of draft-ietf-l3vpn-acceptown-community

2015-06-25 Thread thomas.morin


Thanks you Pradosh for submitting revision -10.
As far as can tell, it is ok to proceed.

Best,

-Thomas


2015-06-15, Alvaro Retana (aretana):

Pradosh??

Thanks!

Alvaro.

On 5/6/15, 5:41 PM, David Smith (djsmith) djsm...@cisco.com wrote:


Pradosh is working on so I'll defer to him. /dave

-Original Message-
From: Alvaro Retana (aretana)
Sent: Friday, May 01, 2015 3:40 PM
To: draft-ietf-l3vpn-acceptown-community@tools.ietf.org
Cc: bess-cha...@tools.ietf.org
Subject: Re: Status of draft-ietf-l3vpn-acceptown-community

[Took Adrian off.]

Hi!

Any ideas on when we might see the update?

Thanks!

Alvaro.

On 2/8/15, 5:50 PM, Adrian Farrel adr...@olddog.co.uk wrote:


Hi authors,

Good news /bad news :-)

The IESG reviewed your document on Thursday on the telechat and
approved it for publication as an RFC. Well done.

However, there are a few minor bits and pieces that need to be tidied up.
You can see it all in the datatracker at
https://datatracker.ietf.org/doc/draft-ietf-l3vpn-acceptown-community/b
all
ot/

It's a little more than I like to put in an RFC Editor note, so I've
marked the I-D as Revised I-D needed.

As soon as you post a revision, I'll pass it on to the RFC Editor.

Please shout if you have any trouble working out what to do with the
various comments.

Thanks for all the work.

Adrian


___
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] Handshaking among PEs in an EVPN ES based on Paxos algorithm

2015-03-27 Thread thomas.morin


HI Weigo, all,

Let me try to help again...

RFC7432, section 8.5 says:

   If a bridged network is multihomed to more than one PE in an EVPN
   network via switches, then the support of All-Active redundancy mode
   requires the bridged network to be connected to two or more PEs using
   a LAG.

   If a bridged network does not connect to the PEs using a LAG, then
   only one of the links between the bridged network and the PEs must be
   the active link for a given ES, VLAN or ES, VLAN bundle.  In this
   case, the set of Ethernet A-D per ES routes advertised by each PE
   MUST have the Single-Active bit in the flags of the ESI Label
   extended community set to 1.

My understanding was that the above excludes the kind of topology in 
which you exclude a possible loop.


-Thomas



Weiguo :

Hi John,
If you can tolerate indefinite forwarding loop during transiet time, i have no 
problem. If the community think it is a serious problem, i think we must 
propose an applicable solution for it, maybe there are other solutions better 
than handshaking mechanism.

Thanks,
weiguo


From: John E Drake [jdr...@juniper.net]
Sent: Friday, March 27, 2015 23:22
To: Haoweiguo; Rabadan, Jorge (Jorge); Satya Mohanty (satyamoh); EXT - 
thomas.mo...@orange.com; bess@ietf.org
Subject: RE: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

I think we have beaten this topic to death.  For the numerous reason I've 
given, I'm not interested in you proposal.

Yours Irrespectively,

John


-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Haoweiguo
Sent: Friday, March 27, 2015 11:12 AM
To: Rabadan, Jorge (Jorge); Satya Mohanty (satyamoh); EXT -
thomas.mo...@orange.com; bess@ietf.org
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

Hi Jorge,
Let give you another indefinitely forwarding loop case, the picture is as
follows:

CE3CE4
   ||
PE3   PE4



PE1   PE2
  | |
CE1CE2

If PE1 and PE2 are dual DF PE in transiet time, assuing PE3 and PE4 are in
stable state ,PE3 is DF PE, PE4 is non-DF PE, the BUM traffic from CE3 to CE1,
the forwarding loop path is as follows;
CE3---PE3--PE2---CE2CE1PE1PE3--CE3--CE4---PE4

forever..

Do you think the harm is enough?
Thanks,
weiguo

From: Rabadan, Jorge (Jorge) [jorge.raba...@alcatel-lucent.com]
Sent: Friday, March 27, 2015 22:59
To: Haoweiguo; Satya Mohanty (satyamoh); thomas.mo...@orange.com;
bess@ietf.org
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

Hi Weiguo,

OK, thanks for clarifying, that is the part I did not understand in your loop 
:-)

To me a loop means you send a frame and that frame keeps being forwarded
by the same nodes indefinitely till you take a corrective action.
In this case, CE3 might get a few packets during the transient state, but those
packets will have its own MAC SA so CE3 will discard them. I don't think that is
harmful for CE3 in most of the cases. And if it is, you just need to make sure
the timers are long enough and the DF election properly implemented to
avoid the transient DF-DF state.

The handshaking is definitely overkilling IMHO.

Thanks.
Jorge

-Original Message-
From: Haoweiguo haowei...@huawei.com
Date: Friday, March 27, 2015 at 7:29 AM
To: Jorge Rabadan jorge.raba...@alcatel-lucent.com, Satya Mohanty
(satyamoh) satya...@cisco.com, thomas.mo...@orange.com
thomas.mo...@orange.com, bess@ietf.org bess@ietf.org
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm


Hi Jorge,
Sorry, maybe i have not explain clearly, pls allow me to clarify it
more clearly.
In MHN case, assuming CE1 and CE2 are multti-homed to PE1 and PE2, CE2
is single homed to remote PE3. CE1 and CE2 forms one layer 2 network,
so it multi-homed network scenario.
   CE3
 |
PE3


PE1  PE2
  |   |
CE1---CE2

In transiet period, PE1 and PE2 are both DF PE. At this time, CE3 sends
BUM traffic to CE1, the traffic will reach PE1 and PE2, CE1 will
receive two copy of the traffic from CE3, also loop is formed, the form path:

CE3PE3PE2CE2CE1PE1---PE3---CE3

I think the traffic loop is absolutely not allowed. In MHN case, the
loop will formed due to dual-DF PE in transiet period.

Thanks,
weiguo




From: Rabadan, Jorge (Jorge) [jorge.raba...@alcatel-lucent.com]
Sent: Friday, March 27, 2015 20:26
To: Haoweiguo; Satya Mohanty (satyamoh); thomas.mo...@orange.com;
bess@ietf.org
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

Hi Weiguo,

About this:

[weiguo]: Traffic duplication and loop issue both exist in dual DF PE
case. In multi-homed device case, say CE1 is multi-homed to

Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

2015-03-26 Thread thomas.morin


Hi Weiguo,

2015-03-26, Haoweiguo:
 Thomas:

 - RFC7432 may have transient periods where the DF election state is
 not yet synchronized between the two peers:



[weiguo]: Yes, i think RFC 7432 has transient periods of traffic loop


Note well that I didn't write that there can be transient _loops_ .
I tried to capture the exchange you had all, and what I gather is that 
the split-horizon procedure _prevents_loops_, independently of any 
transient period where DF state is not synchronized and which may lead 
to transient _duplicates_.


-Thomas



26/03/2015 20:05, John E Drake :


Weiguo,

I guess I wasn’t clear.  I think you draft, for the reasons I have
detailed, is a non-solution to a non-problem with tremendous control
plane cost.

Yours Irrespectively,

John

*From:*Haoweiguo [mailto:haowei...@huawei.com]
*Sent:* Thursday, March 26, 2015 6:17 PM
*To:* John E Drake; Patrice Brissette (pbrisset)
*Cc:* Ali Sajassi (sajassi); bess@ietf.org
*Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on
Paxos algorithm

Pls see below.

Thanks,

weiguo



*From:*John E Drake [jdr...@juniper.net]
*Sent:* Friday, March 27, 2015 6:00
*To:* Haoweiguo; Patrice Brissette (pbrisset)
*Cc:* Ali Sajassi (sajassi); bess@ietf.org mailto:bess@ietf.org
*Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on
Paxos algorithm

To recap,

We have established that your proposal is untenable because of its
control plane load.

We have established that your proposal is based upon a flawed
understanding of the DF election in RFC 7432.

[weiguo]: In ethernet world, traffic loop is serious than short timer
traffic disruption. If you want to implement  transiet traffic loop
process, i will modify my draft to solve your issue.

If i am the developer, i will prefer short timer traffic disruption
based on current EVPN protocol.

What you are now arguing is that your draft prevents two or more PEs
from being DF simultaneously. This is clearly nonsense.

[weiguo]: I will modify the draft problem statements, and use the same
handshaking solution to solve it.

Furthermore, we have established that having two or more DFs for what
even you admit is a brief transient leads to duplicate traffic, which
is acceptable, but not loops, your assertion to the contrary.

[weiguo]: It is transient loop and traffic duplication issue.

Yours Irrespectively,

John

*From:*Haoweiguo [mailto:haowei...@huawei.com]
*Sent:* Thursday, March 26, 2015 5:37 PM
*To:* John E Drake; Patrice Brissette (pbrisset)
*Cc:* Ali Sajassi (sajassi); bess@ietf.org mailto:bess@ietf.org
*Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on
Paxos algorithm

John,

As your understanding of the EVPN draft, the DF election mechanism has
more serious side effect, it will have short time traffic loop,i.e.,
dual DF PEs will exist for a short time. I think dual DF PEs is
absolutely not tolerated, because native ethernet header has no TTL,
up to several hundred ms traffic loop normally not tolerated in
commertial networks.

As your understanding, the PEs should do as following:

1. Accurate timer sync. NTP accuracy is bad, 1588v2 is good but have
rarely deployment.

Assuming PE1,PE2 and PE3 have consistent timer clock, when PE3 joins
ESI and trigger DF re-election. When reception timer expires:

PE1 upgrades to DF PE.

After reception timer+ ES route transmission timer:

PE2 downloads to non-DF PE.

So in timer clock sync case, dual DF PEs will exist at least
transmission timer.

If NTP is used for timer sync, because it has bad accuracy, dual DF
PEs will exist more longer timer.

So as your understanding for DF election, the drawback is more clear.

Thanks,

weiguo



*From:*John E Drake [jdr...@juniper.net]
*Sent:* Friday, March 27, 2015 4:41
*To:* Haoweiguo; Patrice Brissette (pbrisset)
*Cc:* Ali Sajassi (sajassi); bess@ietf.org mailto:bess@ietf.org
*Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on
Paxos algorithm

Weiguo,

We have already established that your proposal is untenable because of
its control plane load.

What we are now discussing is that your proposal is based upon a
misunderstanding of the algorithm in RFC 7432.  You are assuming that
PE1 will advertise an ES route and then wait for the configured
interval before performing the DF election while PE2 and PE3 will
perform the DF election as soon as they receive the ES route from PE1.
This is not what RFC 7432 says.

Rather, what is says is that the advertisement of the ES route by PE1
and its receipt by PE2 and PE3 causes all three PEs to start the
configured interval timer  - “3. When the timer expires, each PE
builds an ordered list of the IP addresses of all the PE nodes
connected to the Ethernet segment (including itself), in increasing
numeric value.”

Yours Irrespectively,

John

*From:*Haoweiguo [mailto:haowei...@huawei.com]

Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

2015-03-26 Thread thomas.morin


Hi,

Let me attempt at clarifying the exchange between the few of you.

My understanding is that:
- RFC7432 already does a good job of avoiding forwarding loops thanks to 
the split-horizon procedure that does not depend on DF election and has 
no transient state
- RFC7432 may have transient periods where the DF election state is not 
yet synchronized between the two peers:
  * the transient period correspond to BGP route propagation times  
(not to the DF election delay, although the wording in RFC 7432 could be 
made clearer)
  * during this period, if PEs do not block BUM traffic, some traffic 
may be lost
  * during this period, if PEs do not block BUM traffic, some traffic 
may be duplicated, but this is not considered very harmful and hence 
preferred to packet loss


The opinion, as I understand, that has been expressed by some is that 
the reduction of the transient period where duplicates may arise, is not 
worth the cost of an handshaking approach.


HTH,

-Thomas


26/03/2015 20:05, John E Drake :


Weiguo,

I guess I wasn’t clear.  I think you draft, for the reasons I have 
detailed, is a non-solution to a non-problem with tremendous control 
plane cost.


Yours Irrespectively,

John

*From:*Haoweiguo [mailto:haowei...@huawei.com]
*Sent:* Thursday, March 26, 2015 6:17 PM
*To:* John E Drake; Patrice Brissette (pbrisset)
*Cc:* Ali Sajassi (sajassi); bess@ietf.org
*Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on 
Paxos algorithm


Pls see below.

Thanks,

weiguo



*From:*John E Drake [jdr...@juniper.net]
*Sent:* Friday, March 27, 2015 6:00
*To:* Haoweiguo; Patrice Brissette (pbrisset)
*Cc:* Ali Sajassi (sajassi); bess@ietf.org mailto:bess@ietf.org
*Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on 
Paxos algorithm


To recap,

We have established that your proposal is untenable because of its 
control plane load.


We have established that your proposal is based upon a flawed 
understanding of the DF election in RFC 7432.


[weiguo]: In ethernet world, traffic loop is serious than short timer 
traffic disruption. If you want to implement  transiet traffic loop 
process, i will modify my draft to solve your issue.


If i am the developer, i will prefer short timer traffic disruption 
based on current EVPN protocol.


What you are now arguing is that your draft prevents two or more PEs 
from being DF simultaneously. This is clearly nonsense.


[weiguo]: I will modify the draft problem statements, and use the same 
handshaking solution to solve it.


Furthermore, we have established that having two or more DFs for what 
even you admit is a brief transient leads to duplicate traffic, which 
is acceptable, but not loops, your assertion to the contrary.


[weiguo]: It is transient loop and traffic duplication issue.

Yours Irrespectively,

John

*From:*Haoweiguo [mailto:haowei...@huawei.com]
*Sent:* Thursday, March 26, 2015 5:37 PM
*To:* John E Drake; Patrice Brissette (pbrisset)
*Cc:* Ali Sajassi (sajassi); bess@ietf.org mailto:bess@ietf.org
*Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on 
Paxos algorithm


John,

As your understanding of the EVPN draft, the DF election mechanism has 
more serious side effect, it will have short time traffic loop,i.e., 
dual DF PEs will exist for a short time. I think dual DF PEs is 
absolutely not tolerated, because native ethernet header has no TTL, 
up to several hundred ms traffic loop normally not tolerated in 
commertial networks.


As your understanding, the PEs should do as following:

1. Accurate timer sync. NTP accuracy is bad, 1588v2 is good but have 
rarely deployment.


Assuming PE1,PE2 and PE3 have consistent timer clock, when PE3 joins 
ESI and trigger DF re-election. When reception timer expires:


PE1 upgrades to DF PE.

After reception timer+ ES route transmission timer:

PE2 downloads to non-DF PE.

So in timer clock sync case, dual DF PEs will exist at least 
transmission timer.


If NTP is used for timer sync, because it has bad accuracy, dual DF 
PEs will exist more longer timer.


So as your understanding for DF election, the drawback is more clear.

Thanks,

weiguo



*From:*John E Drake [jdr...@juniper.net]
*Sent:* Friday, March 27, 2015 4:41
*To:* Haoweiguo; Patrice Brissette (pbrisset)
*Cc:* Ali Sajassi (sajassi); bess@ietf.org mailto:bess@ietf.org
*Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on 
Paxos algorithm


Weiguo,

We have already established that your proposal is untenable because of 
its control plane load.


What we are now discussing is that your proposal is based upon a 
misunderstanding of the algorithm in RFC 7432.  You are assuming that 
PE1 will advertise an ES route and then wait for the configured 
interval before performing the DF election while PE2 and PE3 will 
perform the DF election as soon as they

47 matches

Mail list logo