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

[Thomas Morin]

Hi Working Group,

First of all many thanks to Rob and Greg who did all the most for the 
last iterations of this drafts.



On 22/11/2018 08:54, stephane.litkow...@orange.com wrote:
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.


Not aware of any such IPR.



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

Some of my co-authors working for router vendors will I expect provide 
information on existing implementations.


Best,

-Thomas

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

Re: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress Replication

[Thomas Morin]

Hi Don,

Fedyk, Don, 2017-12-15 15:34:
> I know I read this part several times.  The draft specifies a
> Multicast tunnel with attribute Ingress replication that you don't
> use for multicast traffic.
> 
> > > > > > 
> 
>For example,
>the PMSI Tunnel attribute may indicate the multicast tunnel is of
>type PIM-SM; whereas, the BGP Encapsulation extended community may
>indicate the encapsulation for that tunnel is of type VxLAN. The
>following tunnel types as defined in [RFC6514] can be used in the
>PMSI tunnel attribute for VXLAN/NVGRE:
> 
>  + 3 - PIM-SSM Tree
>  + 4 - PIM-SM Tree
>  + 5 - BIDIR-PIM Tree
>  + 6 - Ingress Replication
> 
> 
>Except for Ingress Replication, this multicast tunnel is used by
> the
>PE originating the route for sending multicast traffic to other
> PEs,
>and is used by PEs that receive this route for receiving the
> traffic
>originated by hosts connected to the PE that originated the route.
> <<<<<

Honestly, interpreting the above as "The draft specifies a Multicast
tunnel with attribute Ingress replication that you don't use for
multicast traffic" is in my opinion really far fetched, for two
reasons:
- the paragraph does not talk about the advertised routes, but what is
used in the dataplane (the actual dataplane construct corresponding to
the PMSI Tunnel Attribute)
- the paragraph only talks about the traffic flowing from advertiser to
remote PEs, so it does not exclude the other direction of traffic from
being used in the case of ingress replication

So well, it's not the first time that additional text aiming at helping
people understand, rather than add precisions required for interop,
ends up being a source of questions.

Here I would suggest to authors to consider purely removing this
paragraph, not because it would be wrong or ambiguous (as said above, I
don't think it is), but because as far as I can tell it has never meant
to specify anything not already implied by RFC7432, but was here only
to help understand.

Best,

-Thomas




-Original Message-
> From: John E Drake [mailto:jdr...@juniper.net] 
> Sent: Friday, December 15, 2017 9:52 AM
> To: EXT - thomas.mo...@orange.com ; Fedyk,
> Don ; Marco Marzetti 
> Cc: bess@ietf.org
> Subject: RE: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress
> Replication
> 
> Thomas,
> 
> I completely agree w/ your email, below.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> > -Original Message-
> > From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Thomas Morin
> > Sent: Friday, December 15, 2017 5:42 AM
> > To: Fedyk, Don ; Marco Marzetti  > it>
> > Cc: bess@ietf.org
> > Subject: Re: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with
> > Ingress 
> > Replication
> > 
> > Hi Don,
> > 
> > Fedyk, Don, 2017-12-14 20:33:
> > > I think the gray area is that this draft talks about BUM traffic
> > > and 
> > > ingress replication and then has a section on Multicast tunnels 
> > > which excludes ingress replication traffic from the tunnels.
> > 
> > No, ingress replication is not excluded at all:
> > 
> >The following tunnel types as defined in [RFC6514] can be used
> > in
> >the PMSI tunnel attribute for VXLAN/NVGRE:
> > 
> >  + 3 - PIM-SSM Tree
> >  + 4 - PIM-SM Tree
> >  + 5 - BIDIR-PIM Tree
> >  + 6 - Ingress Replication
> > 
> > > If you are using point to point VXLAN/NVGRE  tunnels then
> > > ingress 
> > > replication is default [...]
> > 
> > This formulation surprises me: that some implementations behave as
> > you 
> > describe is possibly true (this seems to be the case of the 
> > implementation that triggered this discussion), but I don't know
> > about 
> > any text in the specs we are discussing that would imply such a
> > 'default'.
> > 
> > You might have implementations that in the absence of any local 
> > configuration for an EVPN instance on which type of tunnel to use
> > for 
> > BUM, will default to ingress replication: this is fine, out of the 
> > scope of what is specified for interop, and not breaking other 
> > implementations (as long, of course, that what is chosen locally
> > is 
> > then advertised as expected in a PMSI Tunnel Attribute).
> > 
> > 
> > > but IMET is being used to identify the NVE IP.I read RFC7432
> > > and
> > > RFC6514 in this area and thought that the PMSI attribute MUST be
> > > set 
>

Re: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress Replication

[Thomas Morin]

Hi Don,

Fedyk, Don, 2017-12-14 20:33:
> I think the gray area is that this draft talks about BUM traffic and
> ingress replication and then has a section on Multicast tunnels which
> excludes ingress replication traffic from the tunnels. 

No, ingress replication is not excluded at all:

   The following tunnel types as defined in [RFC6514] can be used in
   the PMSI tunnel attribute for VXLAN/NVGRE:

 + 3 - PIM-SSM Tree
 + 4 - PIM-SM Tree
 + 5 - BIDIR-PIM Tree
 + 6 - Ingress Replication

> If you are using point to point VXLAN/NVGRE  tunnels then ingress
> replication is default [...]

This formulation surprises me: that some implementations behave as you
describe is possibly true (this seems to be the case of the
implementation that triggered this discussion), but I don't know about
any text in the specs we are discussing that would imply such a
'default'.  

You might have implementations that in the absence of any local
configuration for an EVPN instance on which type of tunnel to use for
BUM, will default to ingress replication: this is fine, out of the
scope of what is specified for interop, and not breaking other
implementations (as long, of course, that what is chosen locally is
then advertised as expected in a PMSI Tunnel Attribute).


> but IMET is being used to identify the NVE IP.I read RFC7432 and
> RFC6514 in this area and thought that the PMSI attribute MUST be set
> when there is an Inclusive Multicast Ethernet tag IMET.  

Yes!  (the text of RFC7432 quoted by Ali reminds us that)

 
> I can see two possible fixes:
> -  Specify that the PMSI attribute MUST be set if there is an
> IMET route and specify correct attribute. 

Given the content of RFC7432 and the fact that this is a normative ref
of draft-ietf-bess-evpn-overlay, I think that we don't need to repeat
this MUST in draft-ietf-bess-evpn-overlay.  That is, unless we
explicitly identify an ambiguous piece of text.

> -  Allow that ingress replication is default when PMSI is
> absent but accept PMSI that specifies ingress replication.
> 

I don't think we should do that. It would overnight make non-compliant
pre-standard implementation of draft-ietf-bess-evpn-overlay, without a
rationale to do so except coping with an implementation that assumed a
bit too much.

Best,

-Thomas


 
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Marco Marzetti
> Sent: Thursday, December 14, 2017 9:21 AM
> To: Thomas Morin 
> Cc: bess@ietf.org
> Subject: Re: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress
> Replication
>  
> Hello,
>  
> I have encountered an implementation that is not attaching any PMSI
> to the IMET.
> The authors think they don't really need it because they only support
> Ingress Replication.
> Such behavior breaks interoperability with other implementations that
> are dropping the NLRI if PMSI is not attached.
>  
> So i looked at draft-ietf-bess-evpn-overlay-10 and noticed that
> there's no clear indication of what the proper behavior is.
> As said i assumed i had to look at RFC7432 and RFC6514 (and i did
> it), but i wasn't 100% sure and i preferred to ask.
>  
> Onestly you already made my day by confirming what i thought.
> My suggestion was to make things more clear, but i admit that it
> could look redundant.
>  
> Thanks
>  
>  
>  
>  
>  
>  
>  
> On Thu, Dec 14, 2017 at 2:39 PM, Thomas Morin  m> wrote:
> > Hi Marco,
> > 
> > Marco Marzetti, 2017-12-14 12:25:
> > > I am writing this email asking you to clarify what's the
> > suggested
> > > behavior when PMSI Tunnel Type is set to "Ingress Replication"
> > (type
> > > 6) as draft-ietf-bess-evpn-overlay-10 only suggests what to do
> > with
> > > multicast tunnel trees.
> > >
> > > I think the originating PE should conform with RFC6514 and
> > RFC7432
> > > (from which you've taken inspiration) and always (RFC2119 MUST)
> > > attach PMSI Tunnel attribute with the Tunnel Type set to Ingress
> > > Replication and Tunnel Identifier set to a routable address of
> > the PE
> > > itself (more specifically NVE's IP address).
> > >
> > > Is that correct?
> > > In that case i suggest to add the following line at the end of
> > > Section 9.
> > > """
> > > For Ingress Replication the PE should follow what's stated in
> > RFC6514
> > > Section 5 .
> > > """
> > 
> > The text of section 9 lists "Ingress Replication" in the list of
> > tunnel
> > types that can be used. My understanding is that, in the absence of
> > 

Re: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress Replication

[Thomas Morin]

Hi Marco,

Marco Marzetti, 2017-12-14 12:25:
> I am writing this email asking you to clarify what's the suggested
> behavior when PMSI Tunnel Type is set to "Ingress Replication" (type
> 6) as draft-ietf-bess-evpn-overlay-10 only suggests what to do with
> multicast tunnel trees.
>
> I think the originating PE should conform with RFC6514 and RFC7432
> (from which you've taken inspiration) and always (RFC2119 MUST)
> attach PMSI Tunnel attribute with the Tunnel Type set to Ingress
> Replication and Tunnel Identifier set to a routable address of the PE
> itself (more specifically NVE's IP address).
> 
> Is that correct?
> In that case i suggest to add the following line at the end of
> Section 9.
> """
> For Ingress Replication the PE should follow what's stated in RFC6514
> Section 5 .
> """

The text of section 9 lists "Ingress Replication" in the list of tunnel
types that can be used. My understanding is that, in the absence of
anything being specifically said for Ingress Replication, an
implementation should follow what is said in RFC7432 and RFC6514. (What
other specs could it follow to implement this supported type ? RFC7432
and RFC6514 are more than an inspiration here, these are specs that the
document refers to explicitly)

So I'm not sure that it is useful or needed to add text.

Can you perhaps expand on why the current text would possibly be
ambiguous, misleading or incomplete...?

-Thomas

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

Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

[Thomas Morin]

Ali,

A few nits, sorry for not answering earlier:
>   
> I added the following paragraph to section 6 for clarification:
> “When a PE advertises multiple supported encapsulations, it MUST
> advertise encapsulations that use the same EVPN procedures including
> procedures associated with split-horizon filtering described in
> section 8.3.1. For example, VxLAN and NvGRE (or MPLS and MPLS over
> GRE) encapsulations use the same EVPN procedures and thus a PE can
> advertise both of them and can support either of them or both of them
> simultaneously. However, a PE MUST NOT advertise VxLAN and MPLS 

You should say "VxLAN/NVGRE" here to be consistent with the rest of the
document that treats VXLAN and NVGRE equally.

> encapsulations together because a) MPLS field of EVPN routes is set 

- s/MPLS field/the MPLS field/
- "(a)" instead of "a)" would be a bit more readable

> to either a MPLS label for a VNI but not both and b) some of EVPN 

- s/a MPLS label/an MPLS label/
- s/for a VNI/or a VNI/
- s/some of EVPN/some EVPN/  (?)

> procedures (such as split-horizon filtering) are different for
> VxLAN/NvGRE and MPLS encapsulations.”

Thanks,

-Thomas


 

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

Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

[Thomas Morin]

Ali Sajassi (sajassi), 2017-12-08 03:01:
> M8.2. These should also be Normative: RFC7348, NVGRE, VXLAN-
> > GPE, RFC4023
> >  
> > [Ali] Please refer to Thomas explanation on this which is copied
> > here for your convenience:
> > “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.”
> 
> My reply:
> It can if we call the Down References out in the IETF Last Call and
> no one opposes.  I think we already processed at least one document
> with a DownRef toVXLAN, so I don’t think that’s a problem.
> In any case, the type of Reference should be decided based on the
> real dependency of the document, not on its status.
> [Ali2] Done. 

I've just updated the shepherd review to list the downward references.

Best,

-Thomas

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

Re: [bess] A question about Tunnel Identifier in PMSI Tunnel Attribute etc.

[Thomas Morin]

Hi Tsuno,

(below)

Hiroshi Tsunoda, 2017-08-08 22:20:
> 
> a) Format and examples of Tunnel Identifier in PMSI Tunnel Attribute
> 
>    L2L3-VPN-MCAST-TC-MIB provides a textual convention
>    (L2L3VpnMcastProviderTunnelId) representing
>    the Tunnel Identifier of a P-tunnel.
> 
>    a-1) I would like to know if there is  any preferred format
>   when a Tunnel Identifier is printed.

For each different type, there is a natural/preferred format, but
there is no format valid across all different types.

When the type is for IP multicast tree, it would be natural to display
it as an IP adress, but when the type is for an LSP, it depends on the
MPLS signaling protocol (mLDP, P2MP RSVP-TE)...

I don't know if there is a better solution than to display a
hexadecimal byte string.

>    a-2) In the case that there is no preferred format,
>   the MIB doctor request us to show some actual
>   examples of the Tunnel Identifier.
>   Is there any good reference to see the actual examples?

Not as far as I know.
I don't think there is any canonical way to display, e.g. the  tuple of an RSVP-TE P2MP LSP
SESSION Object.

> 
> b) Required information to identify a particular P-tunnel
> 
> l2L3VpnMcastPmsiTunnelAttributeTable defined in L2L3-VPN-MCAST-
> MIB
> is a table to provide P-tunnel information.
> Currently the index of this table is composed of
> information objects representing Flags, Tunnel Type,
> MPLS Label, and Tunnel Indentifier in
> delivered in PMSI Tunnel Attribute.
> I think the index must be composed only of minimal
> objects to identify a particular P-tunnel.
> Thus, Tunnel Type and Tunnel Indentifier are required
> for the index as described in Sec. 7.4.1.1 of RFC6513,
> but Flags is not required.
> 
> b-1) How about MPLS Label? Is it required to be included in the
> index?

Doing lookups in this table based on an MPLS label does not look like
something natural to do, given that the label allocated may change over
time. I would be tempted to answer no to your question.

-Thomas



> 2017-07-09 14:11 GMT+02:00 Glenn Mansfield Keeni :
> > L2L3-VPN-MCAST-TC-MIB is almost OK.
> > smilint gives warnings
> > (snip)
> >   L2L3-VPN-MCAST-TC-MIB:112: [5] {type-without-format} warning:
> > type
> >   `L2L3VpnMcastProviderTunnelId' has no format specification
> > This may be avoided by specifying a format in which the
> > L2L3VpnMcastProviderTunnelId should be printed.
> > Is there a preferred format? How will this be printed?
> > One continuous octet string?
> > 
> > (snip)
> > 
> > But before we go on to the next stage could you please confirm that
> > A. The l2L3VpnMcastPmsiTunnelAttributeTable needs all of the
> > following
> >    four MOs as index for its rows
> >  l2L3VpnMcastPmsiTunnelAttributeFlags,
> >  l2L3VpnMcastPmsiTunnelAttributeType,
> >  l2L3VpnMcastPmsiTunnelAttributeLabel,
> >  l2L3VpnMcastPmsiTunnelAttributeId
> >    The l2L3VpnMcastPmsiTunnelAttributeId by itself is inadequate?
> > If yes
> >    please explain it to me. Or point to the text that contains the
> >    explanation.
> > I have been unable to confirm the above from the draft - that is
> > very
> > likely due to my lack of understanding of the l2L3VpnMcast
> > technology.
> 
> ___
> 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

[bess] WG Last Call for draft-ietf-bess-mvpn-expl-track

[Thomas Morin]

Hello Working Group,

This email starts a Working Group Last Call on 
draft-ietf-bess-mvpn-expl-track-02 [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 *24th of July*.
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-mvpn-expl-track, 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, additionally to what was already disclosed ([2]).


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&M

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track
[2] 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-mvpn-expl-track

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

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

[bess] Adoption of draft-sajassi-bess-evpn-igmp-mld-proxy (was Re: Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01 (extended to Feb 23))

[Thomas Morin]

Hi everyone,

draft-sajassi-bess-evpn-igmp-mld-proxy is adopted as a working group 
document with the understanding that Jorge's comments from Feb 9th will 
be addressed in a -01.


Can you authors please post the document as-is as 
draft-ietf-bess-evpn-igmp-mld-proxy and then followup with a revision ?


Many thanks!

-Thomas


2017-02-09, Thomas Morin:

Hi working group,

Given the two IPR disclosures made very recently [1], this call is
extended to close on February 23rd.

-Thomas

[1]
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-sajassi-bess-evpn-igmp-mld-proxy





Hello working group,

This email starts a two-week poll on adopting
draft-sajassi-bess-evpn-igmp-mld-proxy-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 **February 23rd**.[<<<<  updated]

*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://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-igmp-mld-proxy-01


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

[bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01 (extended to Feb 23)

[Thomas Morin]

Hi working group,

Given the two IPR disclosures made very recently [1], this call is 
extended to close on February 23rd.


-Thomas

[1] 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-sajassi-bess-evpn-igmp-mld-proxy





Hello working group,

This email starts a two-week poll on adopting 
draft-sajassi-bess-evpn-igmp-mld-proxy-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 **February 23rd**.[  updated]

*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://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-igmp-mld-proxy-01


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

[bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01

[Thomas Morin]

Hello working group,

This email starts a two-week poll on adopting 
draft-sajassi-bess-evpn-igmp-mld-proxy-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 **February 14th**.

*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://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-igmp-mld-proxy-01


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

[bess] Fwd: Re: Request for Assignment of EVPN Route Types

[Thomas Morin]

--- Begin Message ---
Hi Thomas, Martin,

Ali’s request to IANA also included three route types defined in 
https://tools.ietf.org/html/draft-ietf-bess-evpn-bum-procedure-updates-01:

 + 9  - Per-Region I-PMSI A-D route
 + 10 - S-PMSI A-D route
 + 11 - Leaf A-D route

This is in collaboration with authors of other EVPN drafts that involve EVPN 
route types. We believe it satisfies the following requirement:


   c.  The specifications of these code points must be stable; i.e., if

   there is a change, implementations based on the earlier and later

   specifications must be seamlessly interoperable.

We would like to proceed with an early allocation request.

Thanks.
Jeffrey


On 1/18/17, 6:27 AM, "Thomas Morin" 
mailto:thomas.mo...@orange.com>> wrote:

Hi John,

Thanks for the extra information.

Just to make sure: do we have a common understanding that we need to follow 
RFC7120 for EVPN route types (section 3.1) ?

Assuming so, the first step for asking for early allocation would be 
(separately for each of these drafts) an email from an author/editor to us 
chairs asking for the early allocation (see item 1 in section 3.1 of RFC7120), 
and providing rationale that items (c) of section 2 are met (what you just did 
for type 5 is the info we need).  The answer by chairs or ADs for each of the 
three drafts may end up being different ; i particular because they are not at 
the same stage in the process (e.g. draft-sajassi-bess-evpn-igmp-mld-proxy is 
not even yet a WG document).

Thanks,

-Thomas

2017-01-18, John E Drake:
Thomas,

The email from Ali to IANA is below (I understand that he subsequently amended 
it to include RT-5).  Route types 6, 7, and 8 are defined in:  
https://tools.ietf.org/html/draft-sajassi-bess-evpn-igmp-mld-proxy-01.

Cisco, Juniper, and Nokia have had interoperable implementations of the RT-5 
draft for several years, and all three are currently working on implementations 
of the IGMP Proxy draft mentioned above.

Yours Irrespectively,

John

From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Wednesday, November 9, 2016 2:04 PM
To: iana-questi...@iana.org<mailto:iana-questi...@iana.org>
Cc: John E Drake <mailto:jdr...@juniper.net>; Ali Sajassi 
(sajassi) <mailto:saja...@cisco.com>
Subject: Request for Assignment of EVPN Route Types



Contact Name:
Ali Sajassi

Contact Email:
saja...@cisco.com<mailto:saja...@cisco.com>

Type of Assignment:
EVPN Route Types

Registry:
EVPN Route Types
http://www.iana.org/assignments/evpn/evpn.xhtml#route-types

0x06 - Selective Multicast Ethernet Tag Route
0x07 - IGMP Join Synch Route
0x08 - IGMP Leave Synch Route
0x09 - Per-Region I-PMSI A-D route
0x0A - S-PMSI A-D route
0X0B - Leaf A-D route

Description:
These EVPN route types are defined in the following EVPN drafts and some of 
these drafts are being implemented and thus the immediate need for allocation 
of these code points for the purpose of interoperability:

https://tools.ietf.org/html/draft-sajassi-bess-evpn-igmp-mld-proxy-01
https://www.ietf.org/id/draft-ietf-bess-evpn-bum-procedure-updates-00.txt


Additional Info:
Please refer to the above drafts.


Regards,
Ali



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

[bess] Fwd: Early allocation for EVPN route type 5 - draft-ietf-bess-evpn-prefix-advertisement

[Thomas Morin]

--- Begin Message ---




Dear chairs,
As per RFC7120, and on behalf of my co-authors too, I would like to request an IANA early allocation for an EVPN route type, in particular value 5, as defined in draft-ietf-bess-evpn-prefix-advertisement.
Value 5
Description:   IP Prefix
Reference:    draft-ietf-bess-evpn-prefix-advertisement
 
Thank you!
Jorge



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

[bess] Fwd: Tags changed for draft-ietf-bess-virtual-subnet-fib-reduction

[Thomas Morin]

FYI

-Thomas

--- Begin Message ---

The tags on draft-ietf-bess-virtual-subnet-fib-reduction have been
changed by Thomas Morin:
https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet-fib-reduction/

Tag "Other - see Comment Log" added.



Comment:
One vendor has provided information on intent to implement.
Pending at least an actual implementation this draft is kept on hold.
--- End Message ---
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] early allocation of evpn route type 5 (was Re: FW: New Version Notification for draft-surajk-evpn-access-security-00.txt)

[Thomas Morin]

Hi Jorge,

It sounds a lot like we should register an early allocation for route 
type 5 ?
As the editor of draft-ietf-bess-evpn-prefix-advertisement 
, 
would you be ok to bootstrap the early allocation process [1] ?
This draft looks to me like it would match the requirements for early 
allocations ([2]).


We can consider doing the same for 
draft-ietf-bess-evpn-bum-procedure-updates 
, 
as soon as we're certain enough that the specs are stable.

Opinions are welcome on this.

Best,

-Thomas

[1] https://tools.ietf.org/html/rfc7120#section-3.1
[2] https://tools.ietf.org/html/rfc7120#section-2

Rabadan, Jorge (Nokia - US):

Hi,

Not only route type 5. Types 6 to 11 are also requested in other BESS documents.
Check out draft-ietf-bess-evpn-bum-procedure-updates for instance.
Please do not use those.

Thx
Jorge

On 1/16/17, 3:48 PM, "BESS on behalf of Suraj Kumar"  wrote:

Hi Alexander,
Thanks for your review.
I have noted this .

-Thanks,
Suraj

-Original Message-
From: Alexander Marhold [mailto:alexander.marh...@gmx.at]
Sent: Monday, January 16, 2017 12:16 PM
To: Suraj Kumar ; bess@ietf.org
Subject: AW: [bess] FW: New Version Notification for 
draft-surajk-evpn-access-security-00.txt


Hi !

By checking your draft I think you missed the original type 5 route already 
defined not in the base EVOPN RFC but in other drafts for L3 information when 
writing, therefore should it not be type 6 ?

This draft defines a new route (DHCP Snoop Advertisement route) The
PE uses this route message for exchanging DHCP packet contents as
well as complete bindings with other PE.
##
+ 5 - DHCP Snoop Advertisement route
##
An DHCP Snoop Advertisement route type specific EVPN NLRI consists of
the following:

regards

Alexander Marhold



-Ursprüngliche Nachricht-
Von: BESS [mailto:bess-boun...@ietf.org] Im Auftrag von Suraj Kumar
Gesendet: Montag, 16. Januar 2017 06:25
An: bess@ietf.org
Betreff: [bess] FW: New Version Notification for 
draft-surajk-evpn-access-security-00.txt

Hi,
I have submitted a draft
"The draft defines a new BGP EVPN route message for syncing DHCP
  packet contents as well as snoop entry among PEs in an Ethernet
  Segment (ES).  The snoop entry is required to implement Dynamic ARP
  inspection (DAI), IP Source Guard (IPSG/IPSGv6) and IPv6 Neighbor.
  Discovery Inspection (NDI) access security features."

Please review this and provide your comments.

-Thanks,
Suraj

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Thursday, January 12, 2017 5:37 PM
To: Deepak Kakrania ; Suraj Kumar ; Vijay Kumar 
Dunna ; Vijay Kumar Dunna 
Subject: New Version Notification for
draft-surajk-evpn-access-security-00.txt


A new version of I-D, draft-surajk-evpn-access-security-00.txt
has been successfully submitted by Suraj Kumar and posted to the IETF
repository.

Name:   draft-surajk-evpn-access-security
Revision:   00
Title:  EVPN ACCESS SECURITY
Document date:  2017-01-12
Group:  Individual Submission
Pages:  12
URL:
https://www.ietf.org/internet-drafts/draft-surajk-evpn-access-security-00.tx
t
Status:
https://datatracker.ietf.org/doc/draft-surajk-evpn-access-security/
Htmlized:
https://tools.ietf.org/html/draft-surajk-evpn-access-security-00


Abstract:
The draft defines a new BGP EVPN route message for syncing DHCP
packet contents as well as snoop entry among PEs in an Ethernet
Segment (ES).  The snoop entry is required to implement Dynamic ARP
inspection (DAI), IP Source Guard (IPSG/IPSGv6) and IPv6 Neighbor
Discovery Inspection (NDI) access security features.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

Re: [bess] shepherd review of draft-ietf-bess-evpn-etree

[Thomas Morin]

 
two lookups, then perhaps this hardware ability can be leveraged to 
support the two MAC-VRFs approach with only one lookup (building one 
table, marking MAC entries as Leaf entries if they were learned with 
routes carrying only the Leaf RT?)  --- don't misunderstand me: I'm not 
claiming that this works (I haven't looked closely enough), but simply 
that the text provided is not sufficient to exclude this kind of solution


The "duplicating MAC addresses" alternative is explained better, but 
still, nothing is explained on why this is "not viable". It seems to be 
as something rather belonging to the realm of "having a scalability 
impact", but even looking in this respect we are not talking about a 
change of order of magnitude.




   For this scenario, if for a given EVI, the vast majority of PEs will
   have both Leaf and Root sites attached, even though they may start as
   Root-only or Leaf-only PEs, then a single RT per EVI MAY be used in
   order to alleviate  additional configuration overhead associated with


"to alleviate  additional configuration overhead associated with ..." -> 
"to alleviate the configuration overhead associated with ..." ?



   using two RTs per EVI at the expense of having unwanted MAC addresses
   on the Leaf-only PEs.









From: Thomas Morin <mailto:thomas.mo...@orange.com>>

Organization: Orange
Date: Thursday, December 15, 2016 at 4:12 AM
To: Cisco Employee mailto:saja...@cisco.com>>, Loa 
Andersson mailto:l...@pi.nu>>, "George Swallow -T (swallow 
- MBO PARTNERS INC at Cisco)" <mailto:swal...@cisco.com>>, Eric Rosen <mailto:ero...@juniper.net>>, BESS mailto:bess@ietf.org>>
Cc: Martin Vigoureux <mailto:martin.vigour...@nokia.com>>

Subject: Re: shepherd review of draft-ietf-bess-evpn-etree

Hi Ali,

2016-12-13, Ali Sajassi (sajassi):


2016-12-10, Ali Sajassi (sajassi):
Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, 
impacts lot more sections than just section 2.2 for which you 
suggested some texts. It drastically  impacts section 3.1 (known 
unicast traffic), and it also impacts section 3.2 (BUM traffic) and 
section 5.1.


Can you detail why ?
The understanding that leads me to this suggestion is that the 
2-RT+split-horizon scenario in 2.1, then applied to Root/Leaf PE in a 
2.2.1 would not require new procotol procedures nor changes in the 
text that as I understand provides procedures for 2.2(.2) and 2.3.

2nd try. As my 1st response got truncated for some reason.

The reason that impacts more sections than just sec. 2, is that the 
proposed 2.2.1 would be an alternative option for section 3.1. In 
section 3.1, the root/leaf indication for MAC addresses are done via 
flag-bit defined in section 5.1 and it only uses a single MAC-VRF 
(single bridge table per VLAN) per RFC 7432. If we go with two 
MAC-VRFs (e.g., two bridge tables) per VLAN, then that is an 
alternative way of doing the same thing described in section 3.1. 
This alternative way has big ramifications on the platform as it 
requires duplicating MACs and managing multiple bridge tables per VLAN.


Since 2.1 and the proposed 2.2.1 do not require new protocol 
procedures (they only require split-horizon locally in Leaf MAC-VRFs), 
if you state clearly that the procedures in the document are here to 
address 2.2.2 and 2.3, then you don't need to modify the content of 
the document after section 2 (more exactly, you will need minor update 
like changing the current "This scheme applies to all scenarios 
described in section 2." in section 3 into "This scheme applies to 
scenarios described in 2.2.2 and 2.3".


The "big ramifications" above are then not about section 3, but just 
the (platform specific-drawbacks) of 2.2.2 that we have already 
discussed and that can be covered in 2.2.2.


Maybe what you really want is to allow for scenario 2.2 to operate 
with two RTs which has the benefits of both 2.2.1 and 2.2.2 and non 
of the drawbacks. So, maybe we can clarify the current text to make 
sure that this comes out clearly – ie, a PE can have single MAC–VRF 
can have multiple RTs.


You could mention that, but for me the key things is:
- documenting the motivation for the new procedures
- not arbitrarily /restrict/ 2.2.2 to one RT (but why not document 
identified drawbacks)




Furthermore, it creates a new paradigm for EVPN that was never 
intended for because of creating two MAC-VRFs (and two bridge 
tables) for the same VLAN.


The " created a new paradigm that  was never 
intended for" is a not generally valid, or sufficiently detailed, 
argument: if it was, then you might go as far as challenging the 
whole E-Tree spec on the same kind grounds (and many other new things).


So here is where it seems we have a gap to bridge: I still don't 
understand what in RFC7432 describes an intention of "no

Re: [bess] shepherd review of draft-ietf-bess-evpn-etree

[Thomas Morin]

Hi Ali,

2016-12-13, Ali Sajassi (sajassi):


2016-12-10, Ali Sajassi (sajassi):
Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, 
impacts lot more sections than just section 2.2 for which you 
suggested some texts. It drastically  impacts section 3.1 (known 
unicast traffic), and it also impacts section 3.2 (BUM traffic) and 
section 5.1.


Can you detail why ?
The understanding that leads me to this suggestion is that the 
2-RT+split-horizon scenario in 2.1, then applied to Root/Leaf PE in a 
2.2.1 would not require new procotol procedures nor changes in the 
text that as I understand provides procedures for 2.2(.2) and 2.3.

2nd try. As my 1st response got truncated for some reason.

The reason that impacts more sections than just sec. 2, is that the 
proposed 2.2.1 would be an alternative option for section 3.1. In 
section 3.1, the root/leaf indication for MAC addresses are done via 
flag-bit defined in section 5.1 and it only uses a single MAC-VRF 
(single bridge table per VLAN) per RFC 7432. If we go with two 
MAC-VRFs (e.g., two bridge tables) per VLAN, then that is an 
alternative way of doing the same thing described in section 3.1. This 
alternative way has big ramifications on the platform as it requires 
duplicating MACs and managing multiple bridge tables per VLAN.


Since 2.1 and the proposed 2.2.1 do not require new protocol procedures 
(they only require split-horizon locally in Leaf MAC-VRFs), if you state 
clearly that the procedures in the document are here to address 2.2.2 
and 2.3, then you don't need to modify the content of the document after 
section 2  (more exactly, you will need minor update like changing the 
current "This scheme applies to all scenarios described in section 2." 
in section 3 into "This scheme applies to scenarios described in 2.2.2 
and 2.3".


The "big ramifications" above are then not about section 3, but just the 
(platform specific-drawbacks) of 2.2.2 that we have already discussed 
and that can be covered in 2.2.2.


Maybe what you really want is to allow for scenario 2.2 to operate 
with two RTs which has the benefits of both 2.2.1 and 2.2.2 and non of 
the drawbacks. So, maybe we can clarify the current text to make sure 
that this comes out clearly – ie, a PE can have single MAC–VRF can 
have multiple RTs.


You could mention that, but for me the key things is:
- documenting the motivation for the new procedures
- not arbitrarily /restrict/ 2.2.2 to one RT (but why not document 
identified drawbacks)




Furthermore, it creates a new paradigm for EVPN that was never 
intended for because of creating two MAC-VRFs (and two bridge tables) 
for the same VLAN.


The " created a new paradigm that  was never 
intended for" is a not generally valid, or sufficiently detailed, 
argument: if it was, then you might go as far as challenging the whole 
E-Tree spec on the same kind grounds (and many other new things).


So here is where it seems we have a gap to bridge: I still don't 
understand what in RFC7432 describes an intention of "not supporting 
two MAC-VRFs for the same VLAN".


I tried to explain the relationship between EVI, MAC-VRF, bridge 
table, and VLAN in my previous email per RFC 7432. However, lets park 
this discussion for time being as I think it is secondary.


Ok, feel free to revisit if you think that RFC7432 would preclude 
procedures that end up being described in this draft


I think you agree that if we have a single solution that has all the 
benefits of your proposed 2.2.1 and 2.2.2 and none of the drawbacks, 
it is much more preferable with having two solutions each with its own 
advantages and draw backs, right? If so, then existing text in 2.2 was 
intended to convey that. However, we can clarify it further – e.g, 
make it clear that for PE with root & leaf in the same EVI, we can use 
a single MAC-VRF with two RTs (one for leaf and another for root).


As said above my key concern is having the document clearly spell out 
the motivation for new specs.
If this implies documenting the fact that already existing procedure can 
be used, but have drawbacks, then so be it ; there would be no point in 
hiding that, right ?





The WG LC was completed on 3/29/16 and I am sure it is not your 
intention to have major changes to the doc at this stage where 
multiple vendors have already implemented the draft.


As you know, there are different stages at which people do reviews on 
a doc after WGLC, an which may lead doc editors to introduce 
significant --editorial or technical-- changes in a document. 
Sometimes that leads to documents going back to the working group.


However my root intention as doc shepherd, of course, is not to 
propose a major change, but merely to able to answer the standard 
question of the shepherd review -- on the reviews done, on document 
readiness, and on the document quality -- in a way as positive and 
sincere as possible. In particular questions (3) (4) and (6).


So, hopefully the answers to th

Re: [bess] shepherd review of draft-ietf-bess-evpn-etree

[Thomas Morin]

Hi Ali,

2016-12-10, Ali Sajassi (sajassi):
Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, 
impacts lot more sections than just section 2.2 for which you 
suggested some texts. It drastically  impacts section 3.1 (known 
unicast traffic), and it also impacts section 3.2 (BUM traffic) and 
section 5.1.


Can you detail why ?
The understanding that leads me to this suggestion is that the 
2-RT+split-horizon scenario in 2.1, then applied to Root/Leaf PE in a 
2.2.1 would not require new procotol procedures nor changes in the text 
that as I understand provides procedures for 2.2(.2) and 2.3.


Furthermore, it creates a new paradigm for EVPN that was never 
intended for because of creating two MAC-VRFs (and two bridge tables) 
for the same VLAN.


The " created a new paradigm that  was never 
intended for" is a not generally valid, or sufficiently detailed, 
argument: if it was, then you might go as far as challenging the whole 
E-Tree spec on the same kind grounds (and many other new things).


So here is where it seems we have a gap to bridge: I still don't 
understand what in RFC7432 describes an intention of "not supporting two 
MAC-VRFs for the same VLAN".


The WG LC was completed on 3/29/16 and I am sure it is not your 
intention to have major changes to the doc at this stage where 
multiple vendors have already implemented the draft.


As you know, there are different stages at which people do reviews on a 
doc after WGLC, an which may lead doc editors to introduce significant 
--editorial or technical-- changes in a document. Sometimes that leads 
to documents going back to the working group.


However my root intention as doc shepherd, of course, is not to propose 
a major change, but merely to able to answer the standard question of 
the shepherd review -- on the reviews done, on document readiness, and 
on the document quality -- in a way as positive and sincere as possible. 
In particular questions (3) (4) and (6).



This draft talks about two kinds of traffic filtering: a) ingress 
filtering for known unicast and b) egress filtering for BUM traffic. 
What you are suggesting is an alternate mechanism for ingress filtering.


(well I'm not suggesting the mechanism itself --which section 2.1 
already does-- but simply to document that it can still apply without 
the constraint of avoiding the presence of a Root MAC-VRF and a Leaf 
MAC-VRF on a same PE)


Although having multiple VRFs (and forwarding tables) are fine for 
IP-VPNs because the unknown traffic is always dropped, multiple VRFs 
for the same VLAN is not OK for L2 traffic because of flooding of 
unknown traffic. That’s why in section 6 of RFC 7432, for all service 
interface types, the draft talks about a single MAC-VRF per EVI per PE 
and in case of VLAN-aware mode,  multiple VLANs per MAC-VRF but only a 
single bridge table per VLAN. In other words, the bottom line is that 
there can only be a single bridge table per VLAN in order to avoid 
unnecessary flooding.




When you have two MAC-VRFs per VLAN (one for root ACs and another for 
Leaf ACs), then you either need to duplicate lots of MAC addresses 
between these two VRFs, or do lookup on both of these VRFs. Either 
ways this is not a good option relative to keeping a single VRF table 
for both root and leaf sites and just have a single-bit indication on 
whether a MAC is associated with root or leaf (as currently described 
approach in the draft).  I



In the above, it seems you agree that it can work, and you are able to 
offer reasons why it is not the preferred option, then why not just 
document that it can work and provides these reasons as the motivations 
that lead to proposing a new specs ?


(it seems you have an unfinished last sentence: "I [...]" )






(assuming the previous point is resolved:)

With this mechanism above, isn't it possible to have on a given PE, 
for a single E-TREE EVI, both Leaves and Roots, as long as distinct 
MAC-VRFs are used (one for Leaves and one for Roots) ?   (it seems 
to me that the assymetric import/export RT would do what is needed 
to build an E-TREE, we would just have a particular case where a 
Leaf MAC-VRF and a Root MAC-VRF for a given E-TREE end up on a 
single PE)



That’s not possible because per definition of an EVI, there is only 
a single MAC-VRF per EVI for a PE.


Where can I read such a definition ? (the Terminology section in 
RFC7432 does not say that, unless I'm missing something).

And that seems a completely arbitrary restriction.
(just thinking that a given PE device can be split in two logical 
devices show that it can work)


Section 6 of RFC7432 where it gives definitions for different service 
interface types, it specifies the relationship between MAC-VRF and 
VLAN (bridge table) and how many MAC-VRF (and bridge tables) can be 
per EVI.


This section of RFC7434 discusses many different things for the 
different variants.
Can you provide a specific pointer about "how many MAC-VRFs can be per 
EV

[bess] WGLC on one addition in draft-ietf-bess-evpn-overlay-07

[Thomas Morin]

Hi working group,

draft-ietf-bess-evpn-overlay-07 has just been published with a new 
section on "Unknown Unicast Traffic Designation".


This email starts a one week Last Call, for comments specific to this 
new section, to close on December 8th.


Thanks,

-Thomas



internet-dra...@ietf.org :

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS of the IETF.

 Title   : A Network Virtualization Overlay Solution using EVPN
 Authors : Ali Sajassi
   John Drake
   Nabil Bitar
   R. Shekhar
   James Uttaro
   Wim Henderickx
Filename: draft-ietf-bess-evpn-overlay-07.txt
Pages   : 28
Date: 2016-11-30

Abstract:
This document describes how Ethernet VPN (EVPN) [RFC7432] can be used
as an Network Virtualization Overlay (NVO) solution and explores the
various tunnel encapsulation options over IP  and their impact on the
EVPN control-plane and procedures. In particular, the following
encapsulation options are analyzed: VXLAN, NVGRE, and MPLS over GRE.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-07

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [bess] Comments on draft-ietf-bess-evpn-overlay-05.txt

[Thomas Morin]

Hi Ali,

2016-11-21, Ali Sajassi (sajassi):

I incorporated the two comments below and just published a new rev. I am
looking forward to the assignment of the doc. Shepard and his/her comments
so that we can wrap this up.


Looks good to me.
As far as I know, WG LC comments have been addressed.

Thanks,

-Thomas



On 11/14/16, 6:20 AM, "Thomas Morin"  wrote:


Hi Ali,

2016-11-11, Ali Sajassi (sajassi):

Here are a two comments on the changes in
draft-ietf-bess-evpn-overlay-05:


5.1.3  Constructing EVPN BGP Routes

   In EVPN, an MPLS label identifying forwarding table is distributed
by


"identifying forwarding table" was inserted above in -05
Is the use of a per access circuit MPLS label really precluded ? Why ?


It was added for clarification. To address your concern of not
precluding
ACs, I¹ll change the sentence as below:

from:   "In EVPN, an MPLS label identifying forwarding table is
distributed
by"
to: "In EVPN, an MPLS label typically identifying forwarding table is
distributed by"


This is better, although "for instance" would I think be more appropriate.


Done. Changed it to “for instance”




[...]

9 Support for Multicast

   The E-VPN Inclusive Multicast BGP route is used to discover the
   multicast tunnels among the endpoints associated with a given EVI
   (e.g., given VNI) for VLAN-based service and a given  for
   VLAN-aware bundle service. The Ethernet Tag field of this route is
   set as described in section 5.1.3.


It was agreed in June to strike this sentence, which does not seem to
add any information.
( https://www.ietf.org/mail-archive/web/bess/current/msg01769.html )


John agreed to strike the last sentence and not the whole paragraph.


Indeed John agreed.
(I'm not sure why you mention striking the whole paragraph, I don't
recall anyone asking that, and certainly not me)


And frankly I think it is OK to keep the last sentence and to remind the
reader that the Ethernet Tag field is set per section 5.1.3. We are not
duplicating text here. We are just providing a reference.


Mentioning *only* this field as being set as described in section 5.1.3
can also be a possible source of confusion (are other fields set
according to another section?).

I would suggest one of the following:
- strike the sentence
- say something like "all fields in this route are set as described in
section 5.1.3"


O.K. Done!



Best,

-Thomas




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

Re: [bess] Comments on draft-ietf-bess-evpn-overlay-05.txt

[Thomas Morin]

Hi Ali,

2016-11-11, Ali Sajassi (sajassi):

Here are a two comments on the changes in draft-ietf-bess-evpn-overlay-05:


5.1.3  Constructing EVPN BGP Routes

   In EVPN, an MPLS label identifying forwarding table is distributed by


"identifying forwarding table" was inserted above in -05
Is the use of a per access circuit MPLS label really precluded ? Why ?


It was added for clarification. To address your concern of not precluding
ACs, I¹ll change the sentence as below:

from:   "In EVPN, an MPLS label identifying forwarding table is distributed
by"
to: "In EVPN, an MPLS label typically identifying forwarding table is
distributed by"


This is better, although "for instance" would I think be more appropriate.


[...]

9 Support for Multicast

   The E-VPN Inclusive Multicast BGP route is used to discover the
   multicast tunnels among the endpoints associated with a given EVI
   (e.g., given VNI) for VLAN-based service and a given  for
   VLAN-aware bundle service. The Ethernet Tag field of this route is
   set as described in section 5.1.3.


It was agreed in June to strike this sentence, which does not seem to
add any information.
( https://www.ietf.org/mail-archive/web/bess/current/msg01769.html )


John agreed to strike the last sentence and not the whole paragraph.


Indeed John agreed.
(I'm not sure why you mention striking the whole paragraph, I don't 
recall anyone asking that, and certainly not me)



And frankly I think it is OK to keep the last sentence and to remind the
reader that the Ethernet Tag field is set per section 5.1.3. We are not
duplicating text here. We are just providing a reference.


Mentioning *only* this field as being set as described in section 5.1.3 
can also be a possible source of confusion (are other fields set 
according to another section?).


I would suggest one of the following:
- strike the sentence
- say something like "all fields in this route are set as described in 
section 5.1.3"


Best,

-Thomas

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

[bess] Comments on draft-ietf-bess-evpn-overlay-05.txt

[Thomas Morin]

Hi authors of draft-ietf-bess-evpn-overlay,

Here are a two comments on the changes in draft-ietf-bess-evpn-overlay-05:


5.1.3  Constructing EVPN BGP Routes

   In EVPN, an MPLS label identifying forwarding table is distributed by


"identifying forwarding table" was inserted above in -05
Is the use of a per access circuit MPLS label really precluded ? Why ?

[...]

9 Support for Multicast

   The E-VPN Inclusive Multicast BGP route is used to discover the
   multicast tunnels among the endpoints associated with a given EVI
   (e.g., given VNI) for VLAN-based service and a given  for
   VLAN-aware bundle service. The Ethernet Tag field of this route is
   set as described in section 5.1.3.


It was agreed in June to strike this sentence, which does not seem to 
add any information.

( https://www.ietf.org/mail-archive/web/bess/current/msg01769.html )

Best,

-Thomas


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

[bess] IMPORTANT: please resend your slots requests for BESS WG session - IETF 97 - Seoul !

[Thomas Morin]

Hi everyone,

You need to resend your request for a slot (unless the WG or Thomas were 
Cc'd in your initial email).

The reason behind this is that Martin's PC suffered from a crash today.

With our apologies for the inconvenience and for being late to post an 
agenda...


Thomas/Martin


Martin Vigoureux:

All,

it is time we start building the BESS WG agenda for Seoul.
The IETF agenda is available at:
https://datatracker.ietf.org/meeting/97/agenda.html
Please note that it is still a preliminary agenda.

The BESS WG session (2h) is currently scheduled on
Monday, 14th of November, Afternoon session I 13:30-15:30 (local time)

Please send us your request for a presentation slot, indicating
draft name, speaker and desired duration (covering presentation +
discussion)

Please send the requests no later than the 30th of October.
Thank you

M&T

___
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

Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df

[Thomas Morin]

Hi everyone,

We have a new WG document.
Authors, can you please repost as draft-ietf-bess-evpn-ac-df-00 ?

Thanks in advance,

-Thomas/Martin


2016-08-30, Thomas Morin:

Hello working group,

This email starts a two-week poll on adopting
draft-rabadan-bess-evpn-ac-df-05 [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 *September 14th*.

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.

At this date, 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-rabadan-bess-evpn-ac-df

___
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

[bess] Adopted: draft-dhjain-bess-bgp-l3vpn-yang-02 ! (was Re: Call for adoption: draft-dhjain-bess-bgp-l3vpn-yang-01)

[Thomas Morin]

Hi working group,

draft-dhjain-bess-bgp-l3vpn-yang is adopted as a working group document.

Can authors please repost as **draft-ietf-bess-l3vpn-yang-00** ?

Thanks,

-Thomas


2016-08-16, Thomas Morin:

Hello working group,

This email starts a two-week poll on adopting
draft-dhjain-bess-bgp-l3vpn-yang [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 **August 30th**.

*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://datatracker.ietf.org/doc/draft-dhjain-bess-bgp-l3vpn-yang


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

Re: [bess] shepherd review of draft-ietf-bess-evpn-etree

[Thomas Morin]

Hi Ali,

Thanks for the quick respin, which covers many of the points.

(inlined below, skipping the resolved points)

2016-09-02, Ali Sajassi (sajassi):


   sites albeit for different EVIs.




   +-++-+
   |   PE1   ||   PE2   |
+---+  |  +---+  |  +--+  |  +---+ |+---+
|CE1+---ES1+--+   |  |  | MPLS |  |  | +--+ES2-+CE2|
+---+  (Root)  |  |MAC|  |  |  /IP |  |  |MAC|  | (Leaf)   +---+
   |  |VRF|  |  |  |  |  |VRF|  |
   |  |   |  |  |  |  |  |   | |+---+
   |  |   |  |  |  |  |  | +--+ES3-+CE3|
   |  +---+  |  +--+  |  +---+  | (Leaf)   +---+
   +-++-+

   Figure 1: Scenario 1

   In such scenario, an EVPN PE implementation MAY provide E-TREE
   service using topology constraint among the PEs belonging to the same


"topology constraint" is a bit opaque as a term, perhaps "using 
tailored BGP RT import/export policies" would be more descriptive 
(assuming I understood your intent)


Done. Changed it to “topology constraint tailored by BGP Route Target 
(RT) import/export policies"




(I still think that "topology" is not a helpful terme to use here.)


   EVI. The purpose of this topology constraint is to avoid having PEs
   with only  Leaf sites importing and processing BGP MAC routes from
   each other. To support such topology constrain in EVPN, two BGP
   Route-Targets (RTs) are used for every EVPN Instance (EVI): one RT is
   associated with the Root sites and the other is associated with the
   Leaf sites. On a per EVI basis, every PE exports the single RT
   associated with its type of site(s). Furthermore, a PE with Root
   site(s) imports both Root and Leaf RTs, whereas a PE with Leaf
   site(s) only imports the Root RT.


The text seems to imply that the above is sufficient to deliver the 
service, but I fail to see what would prevent Leaf-to-Leaf traffic 
between Leaves bound to the same MAC-VRF (ES2 and ES3 in firgure1).  
Shouldn't the text mention the use of a split-horizon in Leaf MAC-VRFs ?



Agree, nice catch!. I changed the first sentence from:
"In such scenario, an EVPN PE implementation MAY provide E-TREE 
service using topology constraint among the PEs belonging to the same 
EVI."

TO
"In such scenario, topology constraint, provided by BGP Route Target 
(RT) import/export policies among the PEs belonging to the same EVI, 
can be used to restrict the communications among Leaf PEs."


The sentence above does not address my question in fact, which was about 
communication between Leaf ACs (rather than about communication between 
Leaf PEs)
Let me restate here, more clearly: I fail to see what would prevent 
Leaf-to-Leaf traffic between **ACs** bound to the same MAC-VRF (ES2 and 
ES3 in firgure1).  Shouldn't the text mention the use of a split-horizon 
in Leaf MAC-VRFs ?





(assuming the previous point is resolved:)

With this mechanism above, isn't it possible to have on a given PE, 
for a single E-TREE EVI, both Leaves and Roots, as long as distinct 
MAC-VRFs are used (one for Leaves and one for Roots) ?   (it seems to 
me that the assymetric import/export RT would do what is needed to 
build an E-TREE, we would just have a particular case where a Leaf 
MAC-VRF and a Root MAC-VRF for a given E-TREE end up on a single PE)



That’s not possible because per definition of an EVI, there is only a 
single MAC-VRF per EVI for a PE.


Where can I read such a definition ? (the Terminology section in RFC7432 
does not say that, unless I'm missing something).

And that seems a completely arbitrary restriction.
(just thinking that a given PE device can be split in two logical 
devices show that it can work)


Besides, I don’t understand what good does it do to have two MAC-VRFs 
on the same PE (one for Leafs and another for Roots)


Well, the "what is good for" is pretty simple: it means you can have, 
just by tailoring the import/export policies like in 2.1, something as 
useful as the scenario in 2.2.


because Leafs and Roots need to talk to each other and thus we want 
them to be in the same MAC-VRF.


The fact that Leafs and Roots need to talk to each other does not mean 
that they *have* to be in the same MAC-VRF, you can rely on the local 
MPLS dataplane inside the PE to carry the traffic between Roots and 
Leaves can be passed between a Leaf MAC-VRF and a Root MAC-VRF (and you 
can possibly implement a shortcut not involving MPLS encap/decap).



However, Leafs should not talk among themselves and thus we can put 
all the Leaf ACs in a split-horizon group.


Yes, this is the meaning of my initial comment above and it is true 
independently of whether or not you consider the possibility of having 
both a Roots MAC-VRF and Leaf MAC-VRF on a same PE.





If this is not possible, I think the text should explain why.

I don’t

[bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df

[Thomas Morin]

Hello working group,

This email starts a two-week poll on adopting
draft-rabadan-bess-evpn-ac-df-05 [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 *September 14th*.

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.


At this date, 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-rabadan-bess-evpn-ac-df

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

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

[Thomas Morin]

Hi working group, authors,

A quick update on draft-ietf-bess-evpn-overlay, as mentioned during BESS 
meeting in Berlin:
- the door for comments is still open to have more reviews on this 
important document
- reminder to authors: the outcome of the discussion right before/during 
WGLC haven't yet been incorporated in a revision


Best,

-Thomas

thomas.mo...@orange.com :

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 


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

Re: [bess] shepherd review of draft-ietf-bess-evpn-etree

[Thomas Morin]

My previous email was missing comments on the References section...


9  References

9.1 Normative References

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", February,
   2015.

[RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with
   Ethernet VPN (PBB-EVPN)", September, 2015.


RFC7385 will have to be added to the list.



9.2 Informative References

[RFC7387] Key et al., "A Framework for E-Tree Service over MPLS
Network", October 2014.
  



[RFC7153] Rosen et al., "IANA Registries for BGP Extended
Communities",  March, 2014.


This should be I think under Normative References.



[RFC6514] Aggarwal et al., "BGP Encodings and Procedures for
Multicast in MPLS/BGP IP VPNs",  February, 2012.


Ditto.

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

[bess] shepherd review of draft-ietf-bess-evpn-etree

[Thomas Morin]

Hi,

Here is the review I did while preparing the shepherd write-up for 
draft-ietf-bess-evpn-etree .


There is one thing that stands out: the document uses the most 
significant bit of the "PMSI Tunnel Attribute" Tunnel Type  field, which 
cant't be done I think without updating the structure of the 
corresponding registry (RFC7385).  I suggest how that can be done at the 
end of this review (a few people Cc'd for this reason).


Please find my comments below...

[...]


2  E-Tree Scenarios and EVPN / PBB-EVPN Support

   In this section, we will categorize support for E-Tree into three
   different scenarios, depending on the nature of the site association
   (Root/Leaf) per PE or per Ethernet Segment:

   - Leaf OR Root site(s) per PE

   - Leaf OR Root site(s) per AC

   - Leaf OR Root site(s) per MAC

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




   In this scenario, a PE may receive traffic from either Root sites OR
   Leaf sites for a given MAC-VRF/bridge table, but not both
   concurrently. In other words, a given EVI on a PE is either
   associated with a root or leaf.


s/with a root or leaf/with roots or leaves/ ?



The PE may have both Root and Leaf


s/both Root and Leaf/both Roots and Leaves/ ?



   sites albeit for different EVIs.




   +-++-+
   |   PE1   ||   PE2   |
+---+  |  +---+  |  +--+  |  +---+  | +---+
|CE1+---ES1+--+   |  |  | MPLS |  |  | +--+ES2-+CE2|
+---+  (Root)  |  |MAC|  |  |  /IP |  |  |MAC|  |   (Leaf) +---+
   |  |VRF|  |  |  |  |  |VRF|  |
   |  |   |  |  |  |  |  |   |  | +---+
   |  |   |  |  |  |  |  | +--+ES3-+CE3|
   |  +---+  |  +--+  |  +---+  |   (Leaf) +---+
   +-++-+

   Figure 1: Scenario 1

   In such scenario, an EVPN PE implementation MAY provide E-TREE
   service using topology constraint among the PEs belonging to the same


"topology constraint" is a bit opaque as a term, perhaps "using tailored 
BGP RT import/export policies" would be more descriptive (assuming I 
understood your intent)




   EVI. The purpose of this topology constraint is to avoid having PEs
   with only  Leaf sites importing and processing BGP MAC routes from
   each other. To support such topology constrain in EVPN, two BGP
   Route-Targets (RTs) are used for every EVPN Instance (EVI): one RT is
   associated with the Root sites and the other is associated with the
   Leaf sites. On a per EVI basis, every PE exports the single RT
   associated with its type of site(s). Furthermore, a PE with Root
   site(s) imports both Root and Leaf RTs, whereas a PE with Leaf
   site(s) only imports the Root RT.


The text seems to imply that the above is sufficient to deliver the 
service, but I fail to see what would prevent Leaf-to-Leaf traffic 
between Leaves bound to the same MAC-VRF (ES2 and ES3 in firgure1).  
Shouldn't the text mention the use of a split-horizon in Leaf MAC-VRFs ?


(assuming the previous point is resolved:)

With this mechanism above, isn't it possible to have on a given PE, for 
a single E-TREE EVI, both Leaves and Roots, as long as distinct MAC-VRFs 
are used (one for Leaves and one for Roots) ? (it seems to me that the 
assymetric import/export RT would do what is needed to build an E-TREE, 
we would just have a particular case where a Leaf MAC-VRF and a Root 
MAC-VRF for a given E-TREE end up on a single PE)


If this is not possible, I think the text should explain why.



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


This is not specific to E-VPN E-TREE, or even to E-VPN, why mention that ?




2.2 Scenario 2: Leaf OR Root site(s) per AC

   In this scenario, a PE receives traffic from either Root OR Leaf
   sites (but not both) on a given Attachment Circuit (AC) of an EVI. In
   other words, an AC (ES or ES/VLAN) is either associated with a Root
   or Leaf (but not both).


s/with a Root or Leaf/with Roots or Leaves/ ?





 +-++-+
 |   PE1   ||   PE2   |
+---+|  +---+  |  +--+  |  +---+  | +---+
|CE1+-ES1+--+   |  |  |  |  |  | +--+---ES2/AC1--+CE2|
+---+(Leaf)  |  |MAC|  |  | MPLS |  |  |MAC|  |   (Leaf) +---+
 |  |VRF|  |  |  /IP |  |  |VRF|  |
 |  |   |  |  |  |  |  |   |  | +---+
 |  |   |  |  |  |  |  | +--+---ES2/AC2--+CE3|
 |  +---+  |  +--+  |  +---+  |   (Root) +---+
 +-++-+

   Figure 2: Scenario 2

   In this scenario, if there are PEs with only root (or leaf) sites per
   EVI, then the RT constrain procedures described in section

Re: [bess] draft minutes from our session at IETF 96

[Thomas Morin]

Hi Greg,

I've just uploaded updated minutes to address your comment.

Best,

-Thomas, as WG co-chair


2016-07-26, Greg Mirsky:

Hi Thomas, et. al,
my note is regarding the presentation and the discussion of 
draft-ietf-bess-mvpn-fast-failover.
Minutes state "some discussion on BFD boostraping and suggestion we 
may want to have BFD WG aware".
I recall that I've used stronger than "may want" encouragement to 
bring BFD-related work to attention of the BFD WG. In fact, I've 
suggested that the work on bootstrapping p2mp BFD session belongs in 
BFD WG. And shortly after the meeting BFD WG co-chair, Reshad Rahman, 
concurred with my that comment on the mailing list.

Regards, Greg

On Fri, Jul 22, 2016 at 4:29 AM, > wrote:


HI everyone,

The draft minutes of yesterday's session are here:
https://www.ietf.org/proceedings/96/minutes/minutes-96-bess

Please read and suggest any relevant correction or adjustment.
These minutes will become final on September 12th.

Best,

-Thomas/Martin
































































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

[bess] Call for adoption: draft-dhjain-bess-bgp-l3vpn-yang-01

[Thomas Morin]

Hello working group,

This email starts a two-week poll on adopting 
draft-dhjain-bess-bgp-l3vpn-yang [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 **August 30th**.

*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://datatracker.ietf.org/doc/draft-dhjain-bess-bgp-l3vpn-yang

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

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

[Thomas Morin]

Hi everyone,

As announced during Berlin meeting, considering the small support base, 
this document is not adopted.


We will consider doing a call for adoption again when/if we hear more 
about the actual needs for such a solution.


Thomas/Martin



2016-06-20, 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


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

Re: [bess] still no slides for bess Berlin

[Thomas Morin]

Speakers,

We are still missing 3 of the slide decks:

draft-anshuverma-bess-vpls-best-site-id-02
10min, Anshu

draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-00
20min, Jeffrey

draft-sajassi-bess-evpn-igmp-mld-proxy-00
10min, Ali

Please post your slides tomorrow...

Best,

-Thomas

17/07/2016 à 12:53, Martin Vigoureux:

Speakers,

deadline is in less than 12 hrs and we still have not received a 
single set of slides ...
The agenda is pretty full, don't take the risk of seeing your slot 
moved at the end of the agenda.


M&T

___
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

[bess] Fwd: [IANA #915440] Early allocation request - draft-ietf-bess-evpn-optimized-ir

[Thomas Morin]

--- Begin Message ---
Hi all,

IANA has made the following early allocations under the Border Gateway Protocol 
(BGP) Parameters heading at http://www.iana.org/assignments/bgp-parameters:

1) In the P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types 
registry, IANA has registered the following:

0x0AAssisted-Replication Tunnel (TEMPORARY - registered 2016-06-30, expires 
2017-06-30) [draft-ietf-bess-evpn-optimized-ir]

2) In the P-Multicast Service Interface (PMSI) Tunnel Attribute Flags registry, 
IANA has registered the following:

3-4 Assisted-Replication Type (T) (TEMPORARY - registered 2016-06-30, 
expires 2017-06-30)   [draft-ietf-bess-evpn-optimized-ir]
5   Broadcast and Multicast (BM) (TEMPORARY - registered 2016-06-30, 
expires 2017-06-30)[draft-ietf-bess-evpn-optimized-ir]
6   Unknown (U) (TEMPORARY - registered 2016-06-30, expires 2017-06-30) 
[draft-ietf-bess-evpn-optimized-ir]

Please add these names and values to the document's IANA Considerations 
section. 

These allocations can be renewed for one additional year before they expire. If 
the document has yet to be approved for publication, we'll contact you within 
60 days of 2017-06-30 to ask you whether you want to renew.

Best regards,

Amanda Baber
IANA Senior Specialist
ICANN

On Thu Jun 30 18:43:25 2016, aret...@cisco.com wrote:
> On 6/30/16, 2:10 PM, "Amanda Baber via RT"
>  wrote:
> 
> Amanda:
> 
> Hi!
> 
> >As the AD for the BESS working group, can you confirm that IANA can make
> >the early allocations Martin requests below?
> 
> Yes, please go ahead.
> 
> > 
> >If these are OK, should we present the final pair of allocations as
> 
> Let's go with the second option, but a more specific name:
> 
> Value: 3-4
> Name: Assisted-Replication Type (T)
> Reference: draft-ietf-bess-evpn-optimized-ir
> 
> 
> 
> Thanks!
> 
> Alvaro.
> 
> 
> >
> >Value: 3 & 4
> >Name: Type (T)
> >Reference: draft-ietf-bess-evpn-optimized-ir
> >
> >or
> >
> >Value: 3-4
> >Name: Type (T)
> >Reference: draft-ietf-bess-evpn-optimized-ir
> >
> >or
> >
> >Value: 3
> >Name: Type1 (T1)
> >Reference: draft-ietf-bess-evpn-optimized-ir
> >Value: 4
> >Name: Type2 (T2)
> >Reference: draft-ietf-bess-evpn-optimized-ir
> >
> 



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

Re: [bess] Slots requests for BESS WG session - IETF 96 - Berlin

[Thomas Morin]

Patrice Brissette (pbrisset) :

Please set me for Yang again. !0 min for L2VPN, EVPN and L3VPN.


Well, implicitly we already assume slots requests are about non-zero 
time duration *.  ;-)


Typo joke aside, can you tell if you want 10 mins per draft, or if you 
plan to cover them all in one 10-minute slot ?


-Thomas

*: and we even accept slot requests for presentations of zero or 
negative time *after* the meeting is closed and people went back home










On 2016-06-20, 4:10 AM, "BESS on behalf of Martin Vigoureux"
 wrote:


All,

it is time we start building the BESS WG agenda for Berlin.
The IETF agenda is available at:
https://datatracker.ietf.org/meeting/96/agenda.html
Please note that it is still a preliminary agenda.

The BESS WG session (2h) is currently scheduled on
Thursday, 21st of July, Afternoon session I 14:00-16:00 (local time)

Please send us your request for a presentation slot, indicating
draft name, speaker and desired duration (covering presentation +
discussion)

Please send the requests no later than the 7th of July.
Thank you

M&T

___
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



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

Re: [bess] draft-ietf-bess-evpn-overlay / section 5.1.3 vs. section 9 (was Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps)

[Thomas Morin]

Sounds good.

Thanks,

-Thomas


2016-06-15, John E Drake:

Thomas,

Comments inline.

Yours Irrespectively,

John


-Original Message-
From: Thomas Morin [mailto:thomas.mo...@orange.com]
Sent: Wednesday, June 15, 2016 8:47 AM
To: John E Drake; Rabadan, Jorge (Nokia - US); BESS; draft-ietf-bess-evpn-
over...@tools.ietf.org; Ali Sajassi (sajassi)
Subject: draft-ietf-bess-evpn-overlay / section 5.1.3 vs. section 9 (was Re: 
[Idr] draft-ietf-
bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps)

Hi John, Ali,

Through the discussion below it appeared that section 9 and section
5.1.3 needed adjustments to be brought in sync, and indeed there were some 
changes in
last revision.

However, I don't think the cleanup/precision is complete yet:
- section 5.1.3 says "the MPLS label field in the [...] Inclusive Multicast 
Ethernet Tag routes is
used to carry the VNI" although the "Inclusive Multicast Ethernet Tag Route" has no 
"MPLS
label field"
- (directly related to the above) none of these section talks about using the 
MPLS field of
the PMSI Tunnel Attribute as the VNI, although the discussion below concluded 
that it is
what implementations actually do



[JD] Accordingly, and specifically to support the option of locally assigned 
VNIs, the MPLS label1 field in the MAC Advertisement route, the MPLS label 
field in the Ethernet AD per EVI route, and the MPLS label field in the PMSI 
Tunnel Attribute of the Inclusive Multicast Ethernet Tag route are used to 
carry the VNI.



- also, section 9 now says "The Ethernet Tag field of this route is set as 
described in section
5.1.3.", but I find this sentence useless and redundant (precisely because 
5.1.3 already says
it and nothing would indicate that section 9 would be exempt of what 5.1.3 says)



[JD]  We should strike the sentence.




Additionally, it occurred to me that "the MPLS field" is not, strictly 
speaking, unambiguous
for MAC Advertisement routes, because the route actually has two MPLS fields.  
The text
should just say "MPLS Label1 field" for the MAC/IP advertisement route.



[JD]  See above.




Best,

-Thomas


2016-05-04, John E Drake:

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 

[bess] draft-ietf-bess-evpn-overlay / section 5.1.3 vs. section 9 (was Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps)

[Thomas Morin]

Hi John, Ali,

Through the discussion below it appeared that section 9 and section 
5.1.3 needed adjustments to be brought in sync, and indeed there were 
some changes in last revision.


However, I don't think the cleanup/precision is complete yet:
- section 5.1.3 says "the MPLS label field in the [...] Inclusive 
Multicast Ethernet Tag routes is used to carry the VNI" although the 
"Inclusive Multicast Ethernet Tag Route" has no "MPLS label field"
- (directly related to the above) none of these section talks about 
using the MPLS field of the PMSI Tunnel Attribute as the VNI, although 
the discussion below concluded that it is what implementations actually do
- also, section 9 now says "The Ethernet Tag field of this route is set 
as described in section 5.1.3.", but I find this sentence useless and 
redundant (precisely because 5.1.3 already says it and nothing would 
indicate that section 9 would be exempt of what 5.1.3 says)


Additionally, it occurred to me that "the MPLS field" is not, strictly 
speaking, unambiguous for MAC Advertisement routes, because the route 
actually has two MPLS fields.  The text should just say "MPLS Label1 
field" for the MAC/IP advertisement route.


Best,

-Thomas


2016-05-04, John E Drake:

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 the
encapsulation extended community. There are a few implementations
using this community and it is enough when only the encapsulation type is 
needed.



[JD]   I agree and the tunnel encaps draft does keep the EC






* I think it would be better to avoid the explicit list of encap
types in section 5.1.3, and rather refer to
draft-ietf-idr-tunnel-encaps instead


[JORGE] I agree.



[JD]  According to IANA, it allocated the five tunnels types to the
overlay draft so I think we need to keep them





* the following minor modification was proposed, but not yet incorporated:

  

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

[Thomas Morin]

Hi Ali,

The changes in -04 look good.

I would have one suggestion: say explicitly that the "use the label as 
the VNI" behavior is  the same as what the tunnel encap says.


This could be done by adding something like the following to section  
5.1.3 :


Note that the procedure defined here to use the MPLS Label field to 
carry the VNI in the presence
   of a Tunnel Encapsulation Extended Community specifying the use of a 
VNI, is
   aligned with the procedures described in [tunnel-encap] (Section 
"Use of Virtual Network
   Identifiers and Embedded Labels when Imposing a Tunnel Encapsulation 
" for "Labeled Address Families").


Best,

-Thomas



Le 07/06/2016 à 18:04, Ali Sajassi (sajassi) a écrit :

Hi Martin,

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.

Regards,
Ali

On 6/7/16, 1:08 AM, "BESS on behalf of Martin Vigoureux"
  wrote:


Hi,

We are fine with keeping 5512 as the Normative reference for now.
We would think it wise if the editors can add an Informative reference
to draft-ietf-idr-tunnel-encaps (with some text indicating that both
specs provide the required support for the procedures).
The ideal situation would be that tunnel-encaps progresses fast enough
so that in the last stages before publishing evpn-overlay we can be in a
situation to make tunnel-encaps the Normative reference. RFC 4897 would
facilitate that by the way.

If the WG has specific opinions on that matter, they are welcome.

We take good note of the shepherd suggestion. We'll confirm who will
shepherd the document after WG LC (we'll also call for volunteers during
WG Last Call).

Reviews are highly welcome anyway, in particular from people
close to the topic or implementations, and ideally from more than one
person, the best time being now or at least before the WG LC ends.

We'll start the WG LC in a couple of days.

Martin & Thomas


Le 24/05/2016 15:39, John E Drake a écrit :

Hi,

Ali and I decided to keep the normative reference to RFC 5512 rather
than changing it to Eric¹s tunnel encapsulation draft because the
normative reference pre-dates Eric¹s draft and because our draft does
not use any of the new capabilities introduced in Eric¹s draft.

Ali and I would also like to request that Jorge be the document shepherd
for this draft.

Yours Irrespectively,

John

*From:*Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
*Sent:* Tuesday, May 24, 2016 3:05 AM
*To:* John E Drake; EXT -thomas.mo...@orange.com; IDR; BESS;
draft-ietf-bess-evpn-over...@tools.ietf.org; 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

Folks,

I have updated and published rev03 of even-overlay draft.

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/

The main changes are:

  1. section 10.2 ­ DCI using ASBR
  2. The setting of Ethernet tag and VNI fields ­ there were some
 inconsistencies in different sections. Section 5.1.3 captures the
 setting of these fields for different type of services in pretty
 good details. All other sections were cleaned up and now refer to
 section 5.1.3.

Thomas,

The draft is ready for its long-overdue WG LC considering how long its
has been around and its multi-vendor implementation status.

Regards,

Ali



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

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

[Thomas Morin]

nt
   (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 2.1 then that's
fine,
but the text does not have a clear context.


Agreed. Updated the section to indicate the context is section 2.1.




3.3.2 E-Tree without MAC Learning

   The PEs implementing an E-Tree service need not perform MAC
learning
   when the traffic flows between Root and Leaf sites are multicast
or
   broadcast.

I suppose an "only" word should be added at the end of the above

sentence.

Agreed.




   The fields of the IMET route are populated per the procedures

defined

   in [RFC7432], and the route import rules are as described in

previous

   sections.

The route import rules described in previous sections are for MAC

routes,

not IMET routes. Additionally, those rules may not be recommended,
so
might as well delete the last sentence.


Changed the last sentence to ³Š, and the multicast tunnel setup
criteria
are as described in the previous section.²



Section 3.3.1 talks about BUM procedures. That is not specific to
3.3.1
though. Perhaps extract that out to a separate section, and remove
the
BUM text from 3.3.2 as well.


I think it is OK.



   The E-TREE Extended Community is encoded as an 8-octet value as
   follows:


0   1   2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
0 1


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | Type=0x06 | Sub-Type=0x04 | Flags(1 Octet)|

|



+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |  Reserved=0   |   Leaf Label

|



+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


I assume the octect after the flags octet is also reserved=0.
Better

mark

it as "Reserved=0".


Agreed.



When it is used with Ethernet A-D per ES route, the leaf flag
SHOULD
be
set to 0 but ignored by the receiving routers. Therefore, why not
set

it

to 1 to be consistent the MAC/IP route case?


Because the flag is used for known unicast traffic and Leaf label
for
BUM
traffic. We don¹t want to mix the two.

Cheers,
Ali



Thanks.
Jeffrey


-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Thomas
Morin
Sent: Tuesday, January 19, 2016 3:51 AM
To: BESS ;
draft-ietf-bess-evpn-et...@tools.ietf.org
Subject: [bess] WG Last Call on draft-ietf-bess-evpn-etree

Hello Working Group,

This email starts a Working Group Last Call on
draft-ietf-bess-evpn-etree [1] which is considered mature and
ready

for

a final working group review.

Please read the document if you haven't read the most recent
version

yet

(-03), and send your comments to the list, no later than *February

the

2nd* (2016-02-02).

This is not only a call for comments on the document, but also a
call

of

support for its publication.

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

Thank you,

Thomas/Martin

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



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

[bess] draft-shah-bess-l2vpn-yang is adopted (was Re: Poll for adoption: draft-shah-bess-l2vpn-yang)

[Thomas Morin]

Hi everyone,

We've just received the last pending answers on the reminder IPR question.

We have consensus for this draft to become a BESS WG document.

Authors can you please repost as draft-ietf-bess-l2vpn-yang ?

You can include the agreed changes in -00, in particular the ones that 
are small. You can also cover them in next revision.


Additionally, we encourage you to trim the list of authors right now, 
because with 20 co-authors (!) you are beating records, and well beyond 
the recommended limit of 5 authors.  One option you can consider is keep 
only editors in the list of authors and list everyone else in a 
"Contributors" section.


Best,

-Thomas


2016-05-04, Thomas Morin:

Hello working group,

This email starts a two-week poll on adopting
draft-shah-bess-l2vpn-yang [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 *May 25th*.

This call runs in parallel with the adoption call on
draft-brissette-bess-evpn-yang hence the extended period.


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-shah-bess-l2vpn-yang


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

[bess] draft-brissette-bess-evpn-yang is adopted (was Re: Poll for adoption: draft-brissette-bess-evpn-yang)

[Thomas Morin]

Hi everyone,

We have consensus for this draft to become a BESS WG document.
Authors can you please repost as draft-ietf-bess-evpn-yang-00 with the 
agreed changes ?


Best,

-Thomas


Thomas Morin :

Hello working group,

This email starts a two-week poll on adopting
draft-brissette-bess-evpn-yang [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 *May 25th*.

This call runs in parallel with the adoption call on 
draft-shah-bess-l2vpn-yang hence the extended period.



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-brissette-bess-evpn-yang

___
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

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

[Thomas Morin]

Hi John,

[with a question to IDR chairs and  draft-ietf-idr-tunnel-encaps authors 
below]


2016-05-18, John E Drake:
> Unless and until Eric’s draft is published the normative reference is 
to RFC 5512 and neither you nor anyone else knows when or if
> Eric’s draft will be published as an RFC and I think it is a serious 
breach of procedure to hold up the overlay draft by asserting you

> know what the future portends.

Oh, oh, Big Words  :-D
(can you hear the faint murmur of lawyers in the background, impatient 
to enter the procedural battle ?)


Talking about "holding up" the draft could give the wrong impression 
that apart from this question, the draft is ready.
From a strict procedural standpoint, if we set aside that it has been 
'expired' for 4 weeks, draft-ietf-bess-evpn-overlay is in the same state 
as draft-ietf-idr-tunnel-encaps, and noone knows its future for sure either.


And talking about "holding up" the draft could give the wrong impression 
on the kind of input I am providing, that merely relate to producing 
specs not only clear for its authors but to a larger audience. In that 
respect, if we can avoid a short term future where the draft would point 
to an obsolete spec, I think it will be better. Hence, having a 
normative reference to draft-ietf-idr-tunnel-encaps seems better.


IDR chairs and draft-ietf-idr-tunnel-encaps authors, do you know when we 
should expect a WGLC on draft-ietf-idr-tunnel-encaps ?

Progressing it quickly will help clarify all that.

If too far or too much unknown around the progress of 
draft-ietf-idr-tunnel-encaps, I can certainly live with 
draft-ietf-bess-evpn-overlay refer to RFC5512 normatively and to 
draft-ietf-idr-tunnel-encaps informatively, and have text explicitly 
state where things stand.  But's let's not rush, and remember that 
implementers care more about spec stability than knowing what the exact 
RFC number will be.


> This is not the first time an RFC made a normative reference to an 
RFC that subsequently was obsoleted and the RFC system deals

> quite nicely with this situation.

Of course we can deal with less-than-ideal... it doesn't mean we can't 
anticipate and do better.


-Thomas




*From:*Thomas Morin [mailto:thomas.mo...@orange.com]
*Sent:* Wednesday, May 18, 2016 10:23 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


John,

2016-05-18, John E Drake:

I spoke with Ali and he will reference the tunnel encapsulation
draft rather than RFC 5512 but make it Informative.

I think this is in the spirit of what you proposed in your email,
below.


Well, only for some definition of "in the spirit"... :-/

What I think we should do is normatively refer to 
draft-ietf-idr-tunnel-encaps and informatively refer to RFC5512, not 
the reverse.
Or else we end up with an RFC that soon after publication will 
normatively depend to an obsoleted RFC.


-Thomas



*From:*thomas.mo...@orange.com <mailto:thomas.mo...@orange.com>
[mailto:thomas.mo...@orange.com]
*Sent:* Wednesday, May 18, 2016 6:19 AM
*To:* John E Drake; IDR; BESS;
draft-ietf-bess-evpn-over...@tools.ietf.org
<mailto:draft-ietf-bess-evpn-over...@tools.ietf.org>; Ali Sajassi
(sajassi); Rabadan, Jorge (Nokia - US);
draft-ietf-idr-tunnel-en...@tools.ietf.org
<mailto:draft-ietf-idr-tunnel-en...@tools.ietf.org>
*Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs.
draft-ietf-idr-tunnel-encaps

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 any

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

[Thomas Morin]

John,

2016-05-18, John E Drake:
I spoke with Ali and he will reference the tunnel encapsulation draft 
rather than RFC 5512 but make it Informative.

I think this is in the spirit of what you proposed in your email, below.


Well, only for some definition of "in the spirit"... :-/

What I think we should do is normatively refer to 
draft-ietf-idr-tunnel-encaps and informatively refer to RFC5512, not the 
reverse.
Or else we end up with an RFC that soon after publication will 
normatively depend to an obsoleted RFC.


-Thomas



*From:*thomas.mo...@orange.com [mailto:thomas.mo...@orange.com]
*Sent:* Wednesday, May 18, 2016 6:19 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


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-

[bess] Fwd: [IANA #907843] General Request for Assignment (bgp-extended-communities - draft-ietf-bess-service-chaining)

[Thomas Morin]

Hi everyone,

FYI:  codepoints just assigned by IANA in the corresponding FCFS 
registry for the two Extended Communities defined in 
draft-ietf-bess-service-chaining.

The draft itself remains to be updated.

Best,

-Thomas
--- Begin Message ---
Dear Thomas,

IANA has registered the following Transitive Opaque Extended Community 
Sub-Types:

0x13Route-Target Record [draft-ietf-bess-service-chaining]  
2016-05-11
0x14Consistent Hash Sort Order  [draft-ietf-bess-service-chaining]  
2016-05-11

Please see
http://www.iana.org/assignments/bgp-extended-communities

The name of the registry and the registrations' values and descriptions should 
be added to the document's IANA Considerations section.

Best regards,

Amanda Baber
IANA Senior Specialist
ICANN


On Mon May 09 13:56:11 2016, thomas.mo...@orange.com wrote:
> 
> Contact Name:
> Thomas Morin
> 
> Contact Email:
> thomas.mo...@orange.com
> 
> Type of Assignment:
> BGP Extended Community sub-types
> 
> Registry:
> Registry for "Transitive Opaque Extended Community Sub-Types"
> 
> http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-
> communities.xhtml#trans-opaque
> 
> 
> 
> Description:
> These assignments are needed for a first implementation of draft-ietf-
> bess-service-chaining which is now a WG document of the IETF BESS
> working group.
> 
> The two allocations requested are the following:
> - "Route-Target Record", ideally with a Sub-Type of 0x13
> - "Consistent Hash Sort Order", ideally with a Sub-Type of 0x14
> 
> Additional Info:
> draft-ietf-bess-service-chaining (section 9.1 and 9.2)



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

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

[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

[bess] Poll for adoption: draft-shah-bess-l2vpn-yang

[Thomas Morin]

Hello working group,

This email starts a two-week poll on adopting
draft-shah-bess-l2vpn-yang [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 *May 25th*.

This call runs in parallel with the adoption call on 
draft-brissette-bess-evpn-yang hence the extended period.



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-shah-bess-l2vpn-yang

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

[bess] Poll for adoption: draft-brissette-bess-evpn-yang

[Thomas Morin]

Hello working group,

This email starts a two-week poll on adopting
draft-brissette-bess-evpn-yang [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 *May 25th*.

This call runs in parallel with the adoption call on 
draft-shah-bess-l2vpn-yang hence the extended period.



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-brissette-bess-evpn-yang

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

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

[Thomas Morin]

Hi,

There is another point that I missed in this first email.

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.


This is really different than the approach used for other routes (not 
relying on the generic mechanism in draft-ietf-idr-tunnel-encaps), I 
think it would be worth highlighting, by adding something like:


   How the VNI or VSID is encoded in these route is done different
   from the approach used for other routes, because draft-ietf-idr-
   tunnel-encaps does not provide procedures describing how to derive a
   VNI or VSID from a Label in a PMSI Tunnel Attribute.

[ An alternative would be to have draft-ietf-idr-tunnel-encaps provide 
procedures describing how to derive a VNI or VSID from a Label in a PMSI 
Tunnel Attribute and have draft-ietf-bess-evpn-overlay follow that. I 
understand that the existence of implementation makes this hard to change. ]


-Thomas





2016-05-04, Thomas Morin:

Hi,

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.

* I think it would be better to avoid the explicit list of encap types
in section 5.1.3, and rather refer to draft-ietf-idr-tunnel-encaps instead
* the following minor modification was proposed, but not yet incorporated:

John Drake, 2015-11-13 (to BESS ML):

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

"If the BGP Encapsulation extended community is not present, then
the default 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."


I think this change is useful and should be incorporated, although
skipping the last sentence would be wise if the full list of tunnel
types is removed.

Thanks in advance,

-Thomas



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

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

[Thomas Morin]

Hi,

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.


* I think it would be better to avoid the explicit list of encap types 
in section 5.1.3, and rather refer to draft-ietf-idr-tunnel-encaps instead

* the following minor modification was proposed, but not yet incorporated:

   John Drake, 2015-11-13 (to BESS ML):

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

"If the BGP Encapsulation extended community is not present, then the default 
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."


I think this change is useful and should be incorporated, although 
skipping the last sentence would be wise if the full list of tunnel 
types is removed.


Thanks in advance,

-Thomas

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

Re: [bess] minutes of our IETF 95 meeting

[Thomas Morin]

Hi,

I've updated the minutes.
Thanks for the precision.

Beyond this minute adjustment, I understand that the key thing you need 
to clarify is what is missing or problematic in RFC5549.


Thank you,

-Thomas


2016-04-13, li_zhenqi...@hotmail.com:

for draft-li-bess-4pe-01:
Please add my response to comments from Keyur and Wim: 4PE routers 
need IPv4 next hop information to install their IPv4 routing table.


Thanks and Best Regards,

li_zhenqi...@hotmail.com

*From:* Thomas Morin <mailto:thomas.mo...@orange.com>
*Date:* 2016-04-08 05:44
*To:* BESS <mailto:bess@ietf.org>
*Subject:* [bess] minutes of our IETF 95 meeting
Hi everyone,
We have just posted draft minutes for today's meeting.
You can read them at
https://www.ietf.org/proceedings/95/minutes/minutes-95-bess
Please send any comments you may have on these minutes.
Many many thanks to Gunter for his minute taking!
-Thomas/Martin
___
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

[bess] minutes of our IETF 95 meeting

[Thomas Morin]

Hi everyone,

We have just posted draft minutes for today's meeting.

You can read them at 
https://www.ietf.org/proceedings/95/minutes/minutes-95-bess


Please send any comments you may have on these minutes.

Many many thanks to Gunter for his minute taking!

-Thomas/Martin

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

Re: [bess] IETF 95 meeting, *draft* agenda

[Thomas Morin]

The agenda posted below is the final agenda.

Thank you,
See you the next in Buenos Aires!

-Thomas

2016-03-22, Thomas Morin:

Hi everyone

We've just posted the **draft** agenda (still subject to changes) for
our meeting in Buenos Aires:

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

We were not able to accommodate for all requests for time, thank you for
your understanding.

Best,

-Thomas/Martin


WG Status
Co-Chairs, 10 min

Yang models
draft-dhjain-bess-bgp-l3vpn-yang
draft-shah-bess-l2vpn-yang-01
draft-brissette-bess-evpn-yang-01
Patrice, 10min

draft-li-bess-4pe-01
Zhenqiang, 10 min

draft-zzhang-bess-evpn-bum-procedure-updates-01
Jeffrey, 15 min

draft-rabadan-bess-evpn-pref-df-00
Jorge, 10 min

draft-rabadan-bess-evpn-ac-df-03
Jorge, 5 min

draft-rabadan-bess-vendor-evpn-route-00
Jorge, 10 min

draft-boutros-bess-evpn-auto-provisioning-01
Rex or Sami, 10 min

draft-boutros-bess-evpn-vpws-service-edge-gateway-02
Sami or Patrice, 10 min

draft-lin-bess-evpn-irb-mcast-02
Wen, 10 min

draft-sajassi-bess-evpn-l3vpn-multihoming-01
Ali, 10 min

draft-hao-bess-evpn-centralized-df-00
Weiguo, 10 min




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

Re: [bess] Ref: Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02

[Thomas Morin]

Hi Erik,

Yes indeed, Monday morning Buenos Aires time.

"The I-D submission tool will be reopened after 2016-04-03 23:59 ART 
(IETF-meeting local time). " [1]


Best,

-Thomas

[1] https://datatracker.ietf.org/submit/


2016-03-31, Erik Nordmark:

On 3/30/16 1:52 PM, Thomas Morin wrote:

Hi everyone,

This draft is now a BESS working group document.
Can authors please resubmit as draft-ietf-bess-evpn-proxy-arp-nd-00 ?

I suspect we have to wait until the I-D submissions open up again, which
they tend to do the Monday of the IETF meeting.

Erik



Thanks in advance,

-Thomas


2016-02-15, Iftekhar Hussain:


Support.

I have read the draft and found it to provide very useful operational
information.

Thanks,

Iftekhar

From: 

To: "bess at ietf.org" 

Cc: "draft-snr-bess-evpn-proxy-arp-nd at ietf.org"


Date: Fri, 5 Feb 2016 16:56:50 +

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







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

Re: [bess] Ref: Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02

[Thomas Morin]

Hi everyone,

This draft is now a BESS working group document.
Can authors please resubmit as draft-ietf-bess-evpn-proxy-arp-nd-00 ?

Thanks in advance,

-Thomas


2016-02-15, Iftekhar Hussain:


Support.

I have read the draft and found it to provide very useful operational 
information.


Thanks,

Iftekhar

From: 

To: "bess at ietf.org" 

Cc: "draft-snr-bess-evpn-proxy-arp-nd at ietf.org" 



Date: Fri, 5 Feb 2016 16:56:50 +

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



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

[bess] IETF 95 meeting, *draft* agenda

[Thomas Morin]

Hi everyone

We've just posted the **draft** agenda (still subject to changes) for 
our meeting in Buenos Aires:


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

We were not able to accomodate for all requests for time, thank you for 
your understanding.


Best,

-Thomas/Martin


WG Status
Co-Chairs, 10 min

Yang models
draft-dhjain-bess-bgp-l3vpn-yang
draft-shah-bess-l2vpn-yang-01
draft-brissette-bess-evpn-yang-01
Patrice, 10min

draft-li-bess-4pe-01
Zhenqiang, 10 min

draft-zzhang-bess-evpn-bum-procedure-updates-01
Jeffrey, 15 min

draft-rabadan-bess-evpn-pref-df-00
Jorge, 10 min

draft-rabadan-bess-evpn-ac-df-03
Jorge, 5 min

draft-rabadan-bess-vendor-evpn-route-00
Jorge, 10 min

draft-boutros-bess-evpn-auto-provisioning-01
Rex or Sami, 10 min

draft-boutros-bess-evpn-vpws-service-edge-gateway-02
Sami or Patrice, 10 min

draft-lin-bess-evpn-irb-mcast-02
Wen, 10 min

draft-sajassi-bess-evpn-l3vpn-multihoming-01
Ali, 10 min

draft-hao-bess-evpn-centralized-df-00
Weiguo, 10 min


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

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

[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


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

[bess] draft-rabadan-bess-evpn-optimized-ir is adopted (was Re: Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02)

[Thomas Morin]

Hi everyone,

This draft is now a WG document.
Authors, can you please repost as draft-ietf-bess-evpn-optimized-ir ?

Thanks,

-Thomas


2016-01-26, Thomas Morin:

Hello working group,

This email starts a two-week poll on adopting
draft-rabadan-bess-evpn-optimized-ir-02 [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 9th**.


*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-rabadan-bess-evpn-optimized-ir-02















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

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

[Thomas Morin]

Hi Alvaro,

Thanks for your very careful review.
I may not agree with every comment made, but many will certainly improve 
the document.


See inlined below...

Thanks,

-Thomas


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


 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.


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.


According to the e-mail archive, it looks like an early presentation 
of this work happened in an mboned meeting, but I didn't find 
discussion on the pim or idr lists.  Once the comments below are 
addressed I will want to forward the document to pim/idr for their review.


Practically speaking pim/mboned is roughly the same people.
But yes, forwarding the document to these working group is fine.


Major:

 1. There are 6 authors listed on the front page.  According to
RFC7322, the total number is generally limited to 5.  Please work
among yourselves to cut the number of authors.  Alternatively, we
can just list an Editor (there's one already identified)..or you
can produce a justification detailing the contributions of each
author to consider an exception.



Ok, we will address that.


 1. Replace the reference to RFC4601 with a reference to
draft-ietf-pim-rfc4601bis.  Note that the section numbers have
changed slightly!



Yes, we can update.
(you see me surprised to see that appear as a "major" issue!)


 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 algorithm, but some of the text leave doubts.  For
example:
  * "inspired from BGP unicast route damping"  I know the
application is different, but if the algorithm is the same
then please say it.



The procedures associated to the exponential decay are different.


1.
  * Section 5.1. (PIM procedures)
  o "updating the *figure-of-merit* based on the decay
algorithm must be done prior to this increment"  This
statement seems to directly imply that the algorithm is
used.  Please reorder the steps to explicitly call this
one out, instead of plugging it in as an afterthought.
 BTW, should the "must" be "MUST"?  Ordering should help
you not having to deal with that last question.



I've revised the text to describe this step in i

[bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02

[Thomas Morin]

Hello working group,

This email starts a two-week poll on adopting
draft-rabadan-bess-evpn-optimized-ir-02 [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 9th**.


*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-rabadan-bess-evpn-optimized-ir-02













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

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

[Thomas Morin]

Hello Working Group,

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


Please read the document if you haven't read the most recent version yet 
(-03), and send your comments to the list, no later than *February the 
2nd* (2016-02-02).


This is not only a call for comments on the document, but also a call of 
support for its publication.


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


Thank you,

Thomas/Martin

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

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

Re: [bess] WG Last Call for draft-ietf-bess-pta-flags-01

[Thomas Morin]

Martin,

Martin Vigoureux :
*Coincidentally*, we are also polling for knowledge of any IPR that 
applies to draft-ietf-bess-multicast-damping, 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
draft-ietf-bess-pta-flags-01 please respond to this email and indicate 
whether or not you are aware of any relevant IPR.


I am not aware of any such IPR.

Best,

-Thomas

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

[bess] Closing the call for adoption on draft-hao-bess-inter-nvo3-vpn-optionc

[Thomas Morin]

Hi working group,

Based on this long discussion following the call for adoption, we 
consider that there is no consensus at this point to adopt 
draft-hao-bess-inter-nvo3-vpn-optionc as a working group document.


Our understanding is that the problem to address and the different 
alternatives solution are worth exploring, and we consider that the 
question of documenting a solution can be raised again in the future.


We identify that the following will be helpful in this perspective:
- documenting the different alternatives and their pros and cons ; we 
encourage people having raised their voice in this discussion to work 
together to this
- having consolidated information about what encapsulation the typical 
ToR hardware chipsets will support in the mid/long term ; it will be an 
important input to help the WG decide what solution should be documented


Thank you,

Martin & Thomas

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

Re: [bess] Introducing a one-implementation requirement before WG last calls

[Thomas Morin]

Kireeti, Martin,

Any data related to a serious implementation (even a beta without a 
shipping date), would I think be convincing enough.
"release x.y @shipping date d" was simply provided as a possible answer, 
not of the minimum requirement to be convincing.


As Martin said we need more than "I am aware of an implementation".
I would say we also need more than "we plan to implement".

There are cases where we may need more detailed data.
Take for instance the case of a draft that needs specific dataplane 
support: would we accept as convincing enough an implementation on a 
software-only platform, in the absence of any vendor planning to 
implement on hardware ?


-Thomas



Martin Vigoureux :

Hello Kireeti,

thanks for your inputs.
I understand the challenge that "release x.y @shipping date d" might 
pose. What we want, is to go beyond the "I am aware of an 
implementation" type of response. It might currently be sufficient 
with regards to the shepherd write-up question, but won't be any more 
if we introduce the requirement. We'd like to have tangible 
information. Giving "details on how much of the spec was implemented" 
is clearly going in that direction.


-m

Le 26/11/2015 02:26, Kireeti Kompella a écrit :
Sounds like a good idea to me. One tweak: having an official "release 
x.y @shipping date d" is unlikely for a draft. The value of one 
implementation (vs more) is that it shows that a spec is 
implementable and reasonably complete. So, this should be the focus, 
with details on how much of the spec was implemented. Shipping plans 
should be totally optional.


Note that even an experimental implementation takes effort, is likely 
to become official, and shows a degree of seriousness of the part of 
the implementor.  Asking for greater commitment at WGLC is (imho) 
asking too much.


Kireeti

On Nov 24, 2015, at 01:03, Thomas Morin  
wrote:


Hello everyone,

Following the positive feedback received during BESS meeting in 
Yokohama about introducing a one-implementation requirement in BESS, 
we propose to do the following for future WG last calls:


As a prerequisite before doing a working group last call on a 
document, the chairs will ask the working group for known 
implementations of the specifications; a relatively detailed level 
of information will be required (e.g. "release x.y of solution z 
shipping date d", "all features implemented", "partial 
implementation only", etc.) and everyone will be invited to reply 
(not only co-authors of the specifications); the chairs will then do 
the working group last call if satisfying information was provided 
on at least one implementation.


We are open for comments on this proposal until December 7th.

Martin & Thomas


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

[bess] Introducing a one-implementation requirement before WG last calls

[Thomas Morin]

Hello everyone,

Following the positive feedback received during BESS meeting in Yokohama 
about introducing a one-implementation requirement in BESS, we propose 
to do the following for future WG last calls:


As a prerequisite before doing a working group last call on a document, 
the chairs will ask the working group for known implementations of the 
specifications; a relatively detailed level of information will be 
required (e.g. "release x.y of solution z shipping date d", "all 
features implemented", "partial implementation only", etc.) and everyone 
will be invited to reply (not only co-authors of the specifications); 
the chairs will then do the working group last call if satisfying 
information was provided on at least one implementation.


We are open for comments on this proposal until December 7th.

Martin & Thomas

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

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

[Thomas Morin]

ds a different VXLAN UDP destination port/receive 
port.
There might be SW elements that could do some of this, but IETF 
defines solutions which should be implemented across the board 
HW/SW/etc. Even if some SW switches can do this, the proposal will 
impose so many issues in HW/data-plane engines that I cannot be behind 
this solution.
To make this work generically we will have to make changes anyhow. 
Given this, we better do it in the right way and guide the industry to 
a solution which does not imply those complexities. Otherwise we will 
stick with these specials forever with all consequences (bugs, etc).

- snip -
From: "thomas.mo...@orange.com 
<mailto:thomas.mo...@orange.com><mailto:thomas.mo...@orange.com 
<mailto:thomas.mo...@orange.com>>" <mailto:thomas.mo...@orange.com><mailto:thomas.mo...@orange.com 
<mailto:thomas.mo...@orange.com>>>

Organization: Orange
Date: Tuesday 17 November 2015 at 01:37
To: Wim Henderickx <mailto:wim.henderi...@alcatel-lucent.com><mailto:wim.henderi...@alcatel-lucent.com 
<mailto:wim.henderi...@alcatel-lucent.com>>>, BESS <mailto:bess@ietf.org><mailto:bess@ietf.org <mailto:bess@ietf.org>>>

Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
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.
WH2> can it not be all cases: TOR/vswitch/Application. I would make 
the solution flexible to support all of these not?

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.
WH> for me the proposal is not acceptable for the reasons explained: 
too much impact on the data-planes
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 how many ports simultaneously would they support?
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

Re: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags -> adopted

[Thomas Morin]

Hi working group,

We have a new working group document.

Authors, can you please repost as
draft-ietf-bess-bgp-vpls-control-flags ?

Thank you,

-Thomas/Martin


2015-10-26, Ravi Singh:

Hi Thomas, Martin

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.


In a network where some BGP-VPLS PEs have ability to insert CW and some do not, 
not implementing section 3 has potential to cause the PW to not come up or 
cause dropped packets (depending on implementation).
Section 3 of this draft is implemented in JunOS. See last paragraph on
http://www.juniper.net/techpubs/en_US/junos14.1/topics/concept/vpls-bgp-control-word-overview.html
This was implemented in response to a specific-network-deployment-issue.

The key aspect of RFC4761 that necessitates the text of section 3 of this draft 
is that the NLRI-advertising-PE is predicating on all other PEs in the same 
VPLS, that they must or must-not insert the CW, for example, regardless of 
whether they have the capability or not. [See 
https://tools.ietf.org/html/rfc4761#section-3.2.4]
This is in contrast to the proposed modification (for a different purpose) 
where this PE is just advertising its ability 
(https://tools.ietf.org/html/draft-ietf-bess-fat-pw-bgp-00#section-2)

The proposed text in section 3 provides a way around presumption of other-PEs' 
abilities.
Section 4 provides an extension of the same intent for a deployment where the 
transport LSP maybe a p2mp LSP.
Section 5 generalizes the previous sections as deployed to multi-homing 
scenarios.

Both p2mp and multi-homing have some deployments and may run into the issue.

Regards
Ravi




-Original Message-
From: thomas.mo...@orange.com [mailto:thomas.mo...@orange.com]
Sent: Monday, October 5, 2015 12:29 AM
To: bess@ietf.org; draft-singh-bess-bgp-vpls-control-fl...@tools.ietf.org; Ravi
Singh ; Kireeti Kompella ;
senad.palislamo...@alcatel-lucent.com
Subject: Re: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags

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

















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

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

[Thomas Morin]

Wim,

Henderickx, Wim (Wim) :

VXLAN has a dedicated UDP port and is very clear in the RFC7348


Well, having a port reserved for this use that won't be the default for 
another protocol is one thing, but that does not prevent in itself the 
same protocol to be applied on another range of ports. (Because HTTP 
specs says port 80 does not prevent the URI scheme to allow specifying 
the port in the URL)


Even reading the VXLAN (Informational) specs, we see room for 
flexibility wrt ports:


  -  Destination Port: IANA has assigned the value 4789 for the
 VXLAN UDP port, and this value SHOULD be used by default as the
 destination UDP port.  Some early implementations of VXLAN have
 used other values for the destination port.  To enable
 interoperability with these implementations, the destination
 port SHOULD be configurable.

I read "4789 SHOULD be used by default" and "SHOULD be configurable".




Will write something on what I proposed when I get some time, not soon


The co-chair in me needs to ask the following question: should this call 
for adoption be kept on hold until an outline of an alternative solution 
is provided ?


-Thomas







From: Lucy yong mailto:lucy.y...@huawei.com>>
Date: Friday 13 November 2015 at 17:10
To: Wim Henderickx >, Haoweiguo 
mailto:haowei...@huawei.com>>
Cc: "bess@ietf.org " >

Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim,

OptionC is very useful for DCI use case. In this case, multi-hop EBGP 
redistributes VN routes between the end NVEs in source and destination 
Ass, ASBRs do not maintain and distribute the VN routes; a tunnel is 
built between the end NVEs in source and destination Ass for traffic 
transport. Due to the different data planes in DC and WAN, the tunnel 
is stitched by several segments, IP tunnels are used in DCs, and MPLS 
tunnels are used in WAN.


Traditional OptionC requires end-to-end MPLS, which may fit to some 
DCI cases. However, there are many DCs that do not support MPLS data 
plane. This draft is to provide the solution for this use case.


Although VXLAN has UDP port number, if tunnel ingress and egress can 
negotiate to use another UDP port for the VXLAN encapsulation, I don’t 
see it breaks anything. Not sure if hw has this restriction either. 
Even yes, we can consider using UDP source port for this purpose. UDP 
source port is used for transit ECMP and filled by flow entropy, 
tunnel egress can determine the flow entropy value and inform tunnel 
ingress. Thus, tunnel egress (i.e. DC ASBR) can maintain UDP source 
port and MPLS label table; when DC ASBR receives a packet from NVE, by 
lookup the table, it gets the label for the packet, push the label on 
the packet before sending toward WAN.


Hope we together work out the solution for this valid use case and 
like to hear any better alternative.


Regards,

Lucy

*From:*BESS [mailto:bess-boun...@ietf.org] *On Behalf Of *Henderickx, 
Wim (Wim)

*Sent:* Thursday, November 12, 2015 11:00 PM
*To:* Haoweiguo
*Cc:* bess@ietf.org 
*Subject:* Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

The whole draft complicates any data plane we defined so far and since 
there is simpler solutions I don’t support this proposal.


Arguments have been given as to why.

*From: *Haoweiguo mailto:haowei...@huawei.com>>
*Date: *Friday 13 November 2015 at 02:44
*To: *Wim Henderickx >
*Cc: *"bess@ietf.org " >

*Subject: *RE: draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim,

It is used for layer 3 VPN CE device to visit IP based overlay data 
center network. For layer 3 traffic forwarding, the MAC address in 
VXLAN/NVGRE is restricted only in data center inside domain. For the 
traffic from data center inside to outside,  the inner MAC 
address(destination MAC is ASBR-d's MAC, src MAC is NVE's MAC) in 
VXLAN/NVGRE will be dropped at ASBR-d, only IP payload will continue 
to be carried into MPLS network. I can emphasize this point in my 
later version, it doesn't have much impact on the whole solution.


This draft also is suitable for VXLAN-GPE and MPLSoGRE/MPLSoUDP 
network to interconnect with MPLS VPN network. In VXLAN-GPE, it 
supports IP in IP encapsulation, so no inner MAC concerns.


Thanks,

weiguo



*From:*BESS [bess-boun...@ietf.org ] on 
behalf of Henderickx, Wim (Wim) [wim.henderi...@alcatel-lucent.com 
]

*Sent:* Thursday, November 12, 2015 22:33
*To:* bess@ietf.org 
*Subject:* [bess] draft-hao-bess-inter-nvo3-vpn-optionc

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

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

[Thomas Morin]

Lucy Yong :
[Lucy1] Is this one?  “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.”


If yes, you suggest NVE to implement MPLSoGRE or MPLSoUDP, to support 
VXLAN-GPE for L3 payload. First of all, using MPLSoGRE or MPLSoUDP for 
this case, requires three labels + GRE/UDP tunnel, huge overhead is 
introduced here. This is very complex in my opinion. Our solution can 
apply VXLAN-GRE encap. and also support MPLSoX encap (5.1.1 and 
5.1.2). BTW, this may be not what you suggested.


I don't think Wim mentioned 3-labels over UDP or GRE.
Wim proposal works with 2-labels over an IP encap (the topmost label of 
the typical 3-label option C being replaced by an IP transport).


WH> it is less bits then you proposal and no changes in any CP/DP that 
is standardised today. Where is the complexity? Works today and is 
deployed in many networks


[Lucy2] This is not compliant with many DCs’ architecture as Thomas 
pointed out.


( Note that I merely mentioned the problem of vswitch/ToR support for 
MPLS/MPLS/(UDP or GRE), but had mentioned nothing about overall DC 
architecture.  )


-Thomas




*From: *Lucy yong mailto:lucy.y...@huawei.com>>
*Date: *Friday 13 November 2015 at 17:10
*To: *Wim Henderickx >, Haoweiguo 
mailto:haowei...@huawei.com>>
*Cc: *"bess@ietf.org " >

*Subject: *RE: draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim,

OptionC is very useful for DCI use case. In this case, multi-hop EBGP 
redistributes VN routes between the end NVEs in source and destination 
Ass, ASBRs do not maintain and distribute the VN routes; a tunnel is 
built between the end NVEs in source and destination Ass for traffic 
transport. Due to the different data planes in DC and WAN, the tunnel 
is stitched by several segments, IP tunnels are used in DCs, and MPLS 
tunnels are used in WAN.


Traditional OptionC requires end-to-end MPLS, which may fit to some 
DCI cases. However, there are many DCs that do not support MPLS data 
plane. This draft is to provide the solution for this use case.


Although VXLAN has UDP port number, if tunnel ingress and egress can 
negotiate to use another UDP port for the VXLAN encapsulation, I don’t 
see it breaks anything. Not sure if hw has this restriction either. 
Even yes, we can consider using UDP source port for this purpose. UDP 
source port is used for transit ECMP and filled by flow entropy, 
tunnel egress can determine the flow entropy value and inform tunnel 
ingress. Thus, tunnel egress (i.e. DC ASBR) can maintain UDP source 
port and MPLS label table; when DC ASBR receives a packet from NVE, by 
lookup the table, it gets the label for the packet, push the label on 
the packet before sending toward WAN.


Hope we together work out the solution for this valid use case and 
like to hear any better alternative.


Regards,

Lucy

*From:*BESS [mailto:bess-boun...@ietf.org] *On Behalf Of *Henderickx, 
Wim (Wim)

*Sent:* Thursday, November 12, 2015 11:00 PM
*To:* Haoweiguo
*Cc:* bess@ietf.org 
*Subject:* Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

The whole draft complicates any data plane we defined so far and since 
there is simpler solutions I don’t support this proposal.


Arguments have been given as to why.

*From: *Haoweiguo mailto:haowei...@huawei.com>>
*Date: *Friday 13 November 2015 at 02:44
*To: *Wim Henderickx >
*Cc: *"bess@ietf.org " >

*Subject: *RE: draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim,

It is used for layer 3 VPN CE device to visit IP based overlay data 
center network. For layer 3 traffic forwarding, the MAC address in 
VXLAN/NVGRE is restricted only in data center inside domain. For the 
traffic from data center inside to outside,  the inner MAC 
address(destination MAC is ASBR-d's MAC, src MAC is NVE's MAC) in 
VXLAN/NVGRE will be dropped at ASBR-d, only IP payload will continue 
to be carried into MPLS network. I can emphasize this point in my 
later version, it doesn't have much impact on the whole solution.


This draft also is suitable for VXLAN-GPE and MPLSoGRE/MPLSoUDP 
network to interconnect with MPLS VPN network. In VXLAN-GPE, it 
supports IP in IP encapsulation, so no inner MAC concerns.


Thanks,

weiguo



*From:*BESS [bess-boun...@ietf.org ] on 
behalf of Henderickx, Wim (Wim) [wim.henderi...@alcatel-lucent.com 
]

*Sent:* Thursday, November 12, 2015 22:33
*To:* bess@ietf.org 
*Subject:* [bess] draft-hao-bess-inter-nvo3-vpn-optionc

I don’t support the adoption of this draft as a WG. There is a major 
fl

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

[Thomas Morin]

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


Well, although discussing forever is certainly not the goal, the reasons 
for rejecting a proposal need to be thoroughly understood.


(more below)




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)


WH> b depends on the use case


I don't get what you mean by "b depends on the use case".
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> 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 ?


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.


-Thomas









From: Thomas Morin 
Organization: Orange
Date: Friday 13 November 2015 at 09:57
To: Wim Henderickx 
Cc: "bess@ietf.org" mailto: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 ?






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

[bess] IDR accepting post-WGLC comments on draft-ietf-idr-rtc-no-rt

[Thomas Morin]

Hi working group,

draft-ietf-idr-rtc-no-rt has passed working group last call in IDR on 
June 22th and the shepherd noticed that considering that specs being 
worked on in BESS are the primary use case, comments from BESS working 
group could have been solicited.


Hence, IDR chairs have proposed to accept comments on these specs until 
November 27th to let BESS contributors the opportunity to comment.


Please send any comment you have on the idr mailing list.

Best,

-Thomas/Martin

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

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

[Thomas Morin]

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 ?


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

Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'

[Thomas Morin]

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






-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of
thomas.mo...@orange.com
Sent: Thursday, November 12, 2015 3:39 AM
To: bess@ietf.org
Subject: Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'

HI John, Weiguo,

John E Drake :


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



By the way, I suggested this to be documented in draft-rosen-idr-tunnel-
encaps [1].

Best,

-Thomas

[1] http://www.ietf.org/mail-archive/web/idr/current/msg14732.html



*From:*Haoweiguo [mailto:haowei...@huawei.com]
*Sent:* Wednesday, November 11, 2015 1:08 AM
*To:* Rabadan, Jorge (Jorge); saja...@cisco.com; John E Drake
*Cc:* bess@ietf.org
*Subject:* RE: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'

Jorge,

Understood, many thanks. Now that the default tunnel encapsulation is
MPLS encapsulation, the tunnel type 10 seems to be unneccessary. So is
the introduction of tunnel type 10 just for further removing
ambiguity? If i don't use the tunnel type 10 in MPLS based EVPN
implementation(RFC 7432), it will also never incur any issue. Am i right?

Thanks,

weiguo

--
--

*From:*BESS [bess-boun...@ietf.org] on behalf of Rabadan, Jorge
(Jorge) [jorge.raba...@alcatel-lucent.com]
*Sent:* Wednesday, November 11, 2015 11:47
*To:* Haoweiguo; saja...@cisco.com ;
jdr...@juniper.net 
*Cc:* bess@ietf.org 
*Subject:* Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'

Weiguo,

Well, if an RFC7432 implementation does not use the RFC5512 ext
community, the following sentence in the evan-overlay draft should
help interoperability. I personally don’t see any issues.

If the BGP Encapsulation extended community is not present, then the
default MPLS encapsulation or a statically configured encapsulation
is assumed.

Thanks.

Jorge

*From: *Haoweiguo 
>

*Date: *Tuesday, November 10, 2015 at 7:03 PM
*To: *Jorge Rabadan mailto:jorge.raba...@alcatel-lucent.com>>, "saja...@cisco.com
" mailto:saja...@cisco.com>>, "jdr...@juniper.net
" mailto:jdr...@juniper.net>>
*Cc: *"bess@ietf.org " mailto:bess@ietf.org>>
*Subject: *RE: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'

 Jorge,

 Thanks for your explanations. However, i still can't understand,
 i'm sorry.

 RFC 5512 only defines IP tunnel type and encapsulation attribute,
 like L2TPv3,GRE and IP in IP.  For RFC 5512, MPLS tunnel doesn't
 need to be defined specifically, it is default case. In RFC 7432,
 the tunnel type 10 also hasn't been defined. Later, when the EVPN
 for overlay network solution was proposed, the tunnel type 10 was
 introduced to differentiate MPLS tunnel and VXLAN/NVGRE/MPLS Over
 GRE tunnel, because same route type 1,2,3,4 and 5 are used in both
 RFC 7432 and the draft 'draft-ietf-bess-evpn-overlay-02'. We need
 the tunnel type to clearly notify peer EVPN PE which
 tunnel(including MPLS tunnel type) should be used.  So it
 introduced updates on RFC 7432 and will incur some interoperbility
 issue for RFC 7432. Am i right?

 Thanks,

 weiguo


--
--

 *From:*BESS [bess-boun...@ietf.org ]
 on behalf of Rabadan, Jorge (Jorge)
 [jorge.raba...@alcatel-lucent.com
 ]
 *Sent:* Wednesday, November 11, 2015 0:01
 *To:* Haoweiguo; saja...@cisco.com ;
 jdr...@juniper.net 
 *Cc:* bess@ietf.org 
 *Subject:* Re: [bess] One question about
 'draft-ietf-bess-evpn-overlay-02'

 Weiguo,

 There are already implementations using value 10 in the RFC5512
 BGP encap ext community.

 That is the value you would have in RFC7432 compliant networks
 where you can also have overlay tunnels. Value 10 would indicate
 to the ingress PE that the route needs an MPLS tunnel to be resolved.

 Thx

 Jorge

 *From: *BESS mailto:bess-boun...@ietf.org>> on behalf of Haoweiguo
 mailto:haowei...@huawei.com>>
 *Date: *Tuesday, November 10, 2015 at 1:05 AM
 *To: 

[bess] Poll for adoption: draft-hao-bess-inter-nvo3-vpn-optionc

[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

[bess] Agenda for Dallas

[Thomas Morin]

Hi everyone,

Here is our final agenda for our meeting next week in Dallas (Wednesday, 
March 25, 9:00-11:30).


Note well that all slots include the time for discussing the drafts.

Monday 8pm (Dallas local time) is the _deadline_ for presenters to send 
us their slides, keeping in mind that sending them _before is better_.


Thanks and see you in Dallas,

-Thomas/Martin

http://www.ietf.org/proceedings/92/agenda/agenda-92-bess
htmlized: http://tools.ietf.org/wg/bess/agenda?item=agenda-92-bess.html

WG Status, chairs
10 min

draft-xu-bess-l3vpn-prefix-orf
draft-xu-bess-virtual-subnet-rib-reduction
Xiaohu X., 20 min
(30 min)

draft-morin-bess-mvpn-fast-failover
Robert K., 5 min
(35 min)

draft-dolganow-bess-mvpn-expl-track
Eric R., 15 min
(50 min)

draft-kebler-bess-sa-pref
Robert K., 5 min
(55 min)

draft-ietf-bess-pta-flags
Eric R., 20 min
(75min)

draft-snr-bess-evpn-na-flags
draft-snr-bess-evpn-proxy-arp-nd
Jorge R., 10 min
(85 min)

draft-mohanty-bess-evpn-df-election
Satya M., 15 min
(100 min)

draft-hao-bess-evpn-df-handshaking
Weiguo H., 10 min
(110 min)

draft-tsingh-bess-pbb-evpn-yang-cfg
Kishore T., 15 min
(125 min)

draft-boutros-bess-evpn-vpws-service-edge-gateway
Patrice B., 10 min
(135 min)

draft-abhattacharya-bess-l2vpn-ipv6-remotepe
Mohamed B., 5 min
(140 min)

draft-hao-bess-inter-nvo3-vpn
Lucy Y., 10 min
(150 min)






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

[bess] Draft agenda for Dallas

[Thomas Morin]

  
  
Hi working group,

Here is the draft agenda for our meeting in Dallas, scheduled
Wednesday, March 25, 9:00-11:30.

Note well that this agenda is still subject to change.
Feel free to comment...

Best,

-Thomas/Martin

http://www.ietf.org/proceedings/92/agenda/agenda-92-bess
Administrivia and WG Status
chairs, 10 min

draft-xu-bess-l3vpn-prefix-orf-00 
draft-xu-bess-virtual-subnet-rib-reduction-00 
Xiaohu X., 20 min

draft-morin-bess-mvpn-fast-failover-01 
Robert K., 5 min

draft-dolganow-bess-mvpn-expl-track-00
Eric R., 15 min

draft-kebler-bess-sa-pref-00 
Robert K., 5 min

draft-ietf-pta-flags-00 
Eric R., 20 min

draft-tsingh-bess-pbb-evpn-yang-cfg-00 
Kishore T., 15 min

draft-mohanty-l2vpn-evpn-df-election-01 
Satya M., 15 min


  


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

Re: [bess] Poll for adoption: draft-sajassi-bess-evpn-etree

[Thomas Morin]

Hello working group,

This poll is now closed.
We consider that strong-enough support to adopt the document has not 
been expressed at this time.


Thank you,

-Thomas/Martin


2015-02-02, Thomas Morin :

Hello working group,

This email starts a two-week poll on adopting
draft-sajassi-bess-evpn-etree-00 [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 16th**.


*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-sajassi-bess-evpn-etree

___
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

Re: [bess] Pete Resnick's No Objection on draft-ietf-l3vpn-acceptown-community-09: (with COMMENT)

[Thomas Morin]

Adrian, Pete,

2015-02-05, Adrian Farrel:


I looked through the archive.
The comments from the contributor were responded to with a polite email 
explaining how the authors disagreed and why.
The contributor (whose original comments were more like "I would do it 
different") did not follow up, and in the absence of that the response form the 
authors seems to have reasonably addressed the comments.


Thanks Adrian.

I came to the same conclusion when preparing the write-up ; this is why 
I'm confident that the work is well supported.


-Thomas



-Original Message-
From: Pete Resnick [mailto:presn...@qti.qualcomm.com]
Sent: 05 February 2015 00:54
To: The IESG
Cc: draft-ietf-l3vpn-acceptown-community@ietf.org; bess-cha...@ietf.org;
thomas.mo...@rd.francetelecom.com; bess@ietf.org
Subject: Pete Resnick's No Objection on draft-ietf-l3vpn-acceptown-community-
09: (with COMMENT)

Pete Resnick has entered the following ballot position for
draft-ietf-l3vpn-acceptown-community-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-l3vpn-acceptown-community/



--
COMMENT:
--

In the ballot:

   Opposition to the proposal was initially expressed by one contributor,

   but there was good support for adoption and no particular follow-up
   from that contributor.

I'm glad someone wrote it down, but it's not exactly confidence
inspiring. Was this just random opposition without explanation, or did
the person have a point and it got addressed to the chairs' satisfaction,
or did something get dropped? I expect it's that the concern was
addressed reasonably, but the above doesn't exactly say that.





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

Re: [bess] Alia Atlas' Yes on draft-ietf-l3vpn-acceptown-community-09: (with COMMENT)

[Thomas Morin]

Hi Alia,

Alia Atlas:

In Sec 2,2, it says:
"This implies that when propagating routes into a VRF,
the ACCEPT_OWN community should not be propagated.  Likewise, if a
route carrying the ACCEPT_OWN community is received in an address
family which does not allow the source VRF to be looked up, the
ACCEPT_OWN community MUST be discarded."

In the first sentence above, it seems like the "should not" should be
either "SHOULD NOT" or "MUST NOT".  Is there a reason that the text is 
descriptive instead of
normative?


A possible reason to choose to use descriptive text is that the 
propagation of a route into a VRF is a purely local matter. A specific 
implementation might have specific reasons not to discard the community 
at this step, and, as long as the attribute is discarded before being 
re-advertized to a VRF CE BGP neighbor, this is fine.  I think your 
concern is valid since no text makes this mandatory.


I would suggest keeping the first sentence as is, but modify the second 
sentence to cover route advertisement additionally to reception.


OLD:

   Likewise, if a route carrying the ACCEPT_OWN community is received
   in an address family which does not allow the source VRF to be looked up, the
   ACCEPT_OWN community MUST be discarded.

proposed NEW:

   Likewise, if a route carrying the ACCEPT_OWN community is received or 
re-advertized
   in an address family which does not allow the source VRF to be looked up, the
   ACCEPT_OWN community MUST be discarded.

Authors, do you agree ?

-Thomas, as doc shepherd

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

Re: [bess] Stephen Farrell's No Objection on draft-ietf-l3vpn-acceptown-community-09: (with COMMENT)

[Thomas Morin]

Hi Stephen, all,

Stephen Farrell:

- section 6: I think I buy the argument that there are no
new security issues here but that's only true I think if the
security issues with route reflectors are somewhere (and if
those cover cases where crypto is not used to enforce the
"P" in VPN). Wouldn't a reference to something like that be
good here?


RFC4456, which specifies BGP route reflection has a security section 
which merely states that it "does not change the underlying security 
issues inherent in the existing IBGP", but which can be referenced 
nonetheless.


OLD:

   No new fundamental
   security issues are introduced by ACCEPT_OWN.

proposed NEW:

 No new fundamental security issues are introduced by ACCEPT_OWN, 
beyond what is
 already documented in "Security Considerations" sections of 
RFC4271 and RFC4456.


Best,

-Thomas, as doc shepherd


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

[bess] Poll for adoption: draft-sajassi-bess-evpn-etree

[Thomas Morin]

Hello working group,

This email starts a two-week poll on adopting
draft-sajassi-bess-evpn-etree-00 [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 16th**.


*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-sajassi-bess-evpn-etree

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

Re: [bess] Poll for adoption: draft-morin-bess-multicast-damping

[Thomas Morin]

Hi working group,

I'm not aware of any undisclosed IPR related to this draft, and support 
adoption as a co-author.


Best,

-Thomas


2015-01-26, Martin Vigoureux:

Hello working group,

This email starts a two-week poll on adopting
draft-morin-bess-multicast-damping [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 9th**.


*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-morin-bess-multicast-damping


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

Re: [bess] Poll for adoption: draft-rabadan-bess-dci-evpn-overlay / adopted !

[Thomas Morin]

Hi everyone,

We have a new working group document.
Can authors please re-post as draft-ietf-bess-dci-evpn-overlay ?

Best,

-Thomas

2014-12-05 14:13, Thomas Morin:

Hello working group,

This email starts a two-week poll on adopting
draft-rabadan-bess-dci-evpn-overlay [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 **December 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-rabadan-bess-dci-evpn-overlay

___
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

Re: [bess] Poll for adoption: draft-rosen-l3vpn-ir => adopted !

[Thomas Morin]

Hi everyone,

We have a new working group document.
Can authors please repost as draft-ietf-bess-ir-00 ?

Best,

-Thomas

2014-12-04 17:29, Thomas Morin :

Hello working group,

This email starts a two-week poll on adopting draft-rosen-l3vpn-ir [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 **December 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-rosen-l3vpn-ir

___
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

[bess] WG Last Call for draft-ietf-l3vpn-mvpn-bidir-ingress-replication

[Thomas Morin]

Hello working group,

This email starts a Working Group Last Call on 
draft-ietf-l3vpn-mvpn-bidir-ingress-replication, which is considered 
mature and ready for a working group review.


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


(the document has expired a few days ago, so can authors please repost 
the document, as-is, as 
draft-ietf-bess-mvpn-bidir-ingress-replication-00, to make it easier to 
find the it ?)


Thank you,

-Thomas & Martin

[1]

http://tools.ietf.org/html/draft-ietf-l3vpn-mvpn-bidir-ingress-replication-01

https://datatracker.ietf.org/doc/draft-ietf-l3vpn-mvpn-bidir-ingress-replication

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

Re: [bess] Adoption of draft-boutros-l2vpn-evpn-vpws-04 / adopted

[Thomas Morin]

Hi everyone,

We have a new working group document.
Can authors please repost as draft-ietf-bess-evpn-vpws-00 ?

Best,

-Thomas


2015-01-06, Sami Boutros (sboutros):

The same here.

Thanks,

Sami
On Jan 6, 2015, at 2:49 AM, Samer Salam (ssalam) wrote:


Hi,

I am not aware of any IPR related to this draft beyond what has already
been disclosed.

Thanks,
Samer

On 2014-12-19 1:05 AM, "Thomas Morin"  wrote:


[initially sent to l2vpn instead of bess]

Hi everyone,

Before formally adopting this in BESS, we need an answer from each
co-author on this recurrent reminder question about existing 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.

Best,

-Thomas/Martin


Nabil:

Hi,
For the record, this call had closed on October 20. The draft has good
support. The authors are to work with the BESS WG chairs to issue this
draft as a BESS working group draft.

Thanks,
Nabil & Giles
_
From: Bitar, Nabil
N
Sent: Monday, October 06, 2014 9:16 AM
To: l2...@ietf.org
Cc: Giles Heron;
amcla...@cisco.com
Subject: [l2vpn] WG adoption call for the draft VPWS
support in E-VPN, draft-boutros-l2vpn-evpn-vpws-04

L2VPN WG,

This is the
start of a 2-week call for adopting the draft ³VPWS support in E-VPN²,
draft-boutros-l2vpn-evpn-vpws-04, as an L2VPN WG document. The draft
can be
found at: http://www.ietf.org/id/draft-boutros-l2vpn-evpn-vpws-04.txt

This
draft was well supported in the WG meeting in Toronto, but as always we
are
taking it to the list to decide on WG adoption. Please, reply to this
email
indicating your support or objection to adopting this draft as a WG
document. Substantive comments in addition to indicating your support or
objection are appreciated

This call will close on Monday, October 20,
2014.


Thanks,
Nabil & Giles











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

[bess] Adoption of draft-boutros-l2vpn-evpn-vpws-04

[Thomas Morin]

[initially sent to l2vpn instead of bess]

Hi everyone,

Before formally adopting this in BESS, we need an answer from each 
co-author on this recurrent reminder question about existing 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.


Best,

-Thomas/Martin


Nabil:

Hi,
For the record, this call had closed on October 20. The draft has good
support. The authors are to work with the BESS WG chairs to issue this draft as 
a BESS working group draft.

Thanks,
Nabil & Giles
_
From: Bitar, Nabil
N
Sent: Monday, October 06, 2014 9:16 AM
To: l2...@ietf.org
Cc: Giles Heron;
amcla...@cisco.com
Subject: [l2vpn] WG adoption call for the draft VPWS
support in E-VPN, draft-boutros-l2vpn-evpn-vpws-04

L2VPN WG,

This is the
start of a 2-week call for adopting the draft ³VPWS support in E-VPN²,
draft-boutros-l2vpn-evpn-vpws-04, as an L2VPN WG document. The draft can be
found at: http://www.ietf.org/id/draft-boutros-l2vpn-evpn-vpws-04.txt

This
draft was well supported in the WG meeting in Toronto, but as always we are
taking it to the list to decide on WG adoption. Please, reply to this email
indicating your support or objection to adopting this draft as a WG
document. Substantive comments in addition to indicating your support or
objection are appreciated

This call will close on Monday, October 20,
2014.


Thanks,
Nabil & Giles





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

Re: [bess] WG Last Call for draft-ietf-bess-mvpn-global-table-mcast

[Thomas Morin]

Hi everyone,

This last call is now ended.
We'll move the doc to the IESG as soon as the shepherd review is done.

Thanks,

-Thomas

2014-11-28, Thomas Morin :

Hello working group,

This email starts a Working Group Last Call on
draft-ietf-bess-mvpn-global-table-mcast [1],
which is considered mature and ready for a last working group review.

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


Thank you,

-Thomas & Martin

[1] http://tools.ietf.org/html/draft-ietf-bess-mvpn-global-table-mcast



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

Re: [bess] Last Call Comment draft-ietf-l3vpn-end-system-04.txt / XML schema registration

[Thomas Morin]

Hi IANA,

We need to find the right way to choose the URI for the XML schema in 
this draft, and understand based on RFC3688 that the registry at [1] is 
the right place.


We need to identify whether a URL (like the one currently in the draft: 
http://www.ietf.org/bgp-l3vpn-unicast.xsd) is suitable, or if it would 
better to choose a URN (e.g. 
"urn:ietf:params:xml:schema:bess:unicast").  The registry notes that it 
applies to both URN and URLs, but there is no precedent for a URL.


I've tried to reach Jari Urpalainen who is the expert designed in this 
registry, but his email address @nokia.com bounces ("User unknown").   
Does IANA have an alternate address to reach him ? If not, does IANA 
have a backup expert ?


Note that once we have the answer we will have an additional piece of 
text to add to the IANA actions section.


Best,

-Thomas,
as draft shepherd

[1] http://www.iana.org/assignments/xml-registry/xml-registry.xhtml#schema



Pedro Marques :

Benson,

On Nov 25, 2014, at 10:25 AM, Benson Schliesser 
mailto:bens...@queuefull.net>> wrote:


Simple: I agree that it should be relatively straight-forward to fix 
the namespace issue. While I'm not intimately familiar with it, I 
think that RFC 3688 describes how the appropriate namespace can be 
assigned. I'm comfortable describing this as editorial rather than 
material.


RFC 3688 provides a way to ask IANA to assign a URN for a schema. It 
doesn’t include guidelines on how that URN should look like. From the 
point of view of the draft in question it is simple to modify the 
examples to use TBD as a URN. However IANA would probably want 
guidance as to what name to assign. Does it make sense to include a 
suggestion in the IANA section ?



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

Re: [bess] [IANA #798045] IANA's comments on draft-ietf-l3vpn-end-system

[Thomas Morin]

Hi Pearl,

Pearl Liang :

However, it also said that bess-ch...@tools.ietf.org address does not exist:


bess-ch...@tools.ietf.org<mailto:bess-ch...@tools.ietf.org>
The email address you entered couldn't be found. Please check the recipient's 
email address and try to resend the message. If the problem continues, please 
contact your helpdesk.

The following organization rejected your message: pechora3.icann.org, 
zinfandel.tools.ietf.org.

Has that address been set-up?


It seems that bess-cha...@tools.ietf.org  (with an 's' to chairs) does 
exist, but that bess-ch...@tools.ietf.org does not.
(In fact, I don't know if any -chair@ alias, without an 's', exist 
at all)


Best,

-Thomas







My response will be in a response to this email.

Cheers,
Adrian


IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-l3vpn-end-system-04.  Authors should

review

the comments and/or questions below.  Please report any inaccuracies

and

respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has a question about the IANA Considerations section of this

document.

Previously, an early assignment has been made to support this draft.

The

original request for an assignment is below:



Contact Name:
Thomas Morin

Contact Email:
thomas.mo...@orange.com

Type of Assignment:
Assignement of a BGP parameter in a FCFS registry.

Registry:
BGP Tunnel Encapsulation Attribute Tunnel Types

See: https://www.iana.org/assignments/bgp-parameters

Description:
Needed for draft-ietf-l3vpn-end-system, to allow the use of an
MPLS-over-UDP encapsulation as specified in draft-ietf-mpls-in-udp

.

No value has been proposed yet, next available value 13 would be

fine.

Additional Info:
draft-ietf-l3vpn-end-system


IANA Question --> The IANA Considerations section said "This

document has

no IANA actions."  and, as a result, the assignment made through the

request

above would not be made permanent. Is this the author's intent? If

not, could

the draft be revised to indicate that the assignment made based on

the request

above be changed from an initial assignment to a permanent

assignment.

Note:  The actions requested in this document will not be completed

until the

document has been approved for publication as an RFC. This message

is only

to confirm what actions will be performed.

Please note that IANA cannot reserve specific values. However, early

allocation

is available for some types of registrations. For more information,

please see

RFC 7120.



___
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

Re: [bess] [IANA #798045] RE: IANA's comments on draft-ietf-l3vpn-end-system

[Thomas Morin]

Hi IANA,

Let me simply state that I agree with Adrian's analysis and suggestion.

-Thomas,
(as shepherd of this draft, and as the one who took the action of 
registering the code point)



Tue Dec 09 2014 14:20:26 GMT+0100 (CET), Adrian Farrel:


Hi,

Replying to myself and keeping the same IANA tracking number.

> > IESG/Authors/WG Chairs:

> >

> > IANA has reviewed draft-ietf-l3vpn-end-system-04.Authors should review

> > the comments and/or questions below.Please report any inaccuracies and

> > respond to any questions as soon as possible.

> >

> > IANA's reviewer has the following comments/questions:

> >

> > IANA has a question about the IANA Considerations section of this 
document.


> >

> > Previously, an early assignment has been made to support this 
draft. The


> > original request for an assignment is below:

> >

> >> 

> >> Contact Name:

> >> Thomas Morin

> >>

> >> Contact Email:

> >> thomas.mo...@orange.com

> >>

> >> Type of Assignment:

> >> Assignement of a BGP parameter in a FCFS registry.

> >>

> >> Registry:

> >> BGP Tunnel Encapsulation Attribute Tunnel Types

> >>

> >> See: https://www.iana.org/assignments/bgp-parameters

> >>

> >> Description:

> >> Needed for draft-ietf-l3vpn-end-system, to allow the use of an

> >> MPLS-over-UDP encapsulation as specified in draft-ietf-mpls-in-udp .

> >>

> >> No value has been proposed yet, next available value 13 would be 
fine.


> >>

> >> Additional Info:

> >> draft-ietf-l3vpn-end-system

> >> 

> >

> > IANA Question --> The IANA Considerations section said "This 
document has


> > no IANA actions."and, as a result, the assignment made through the 
request


> > above would not be made permanent. Is this the author's intent? If 
not, could


> > the draft be revised to indicate that the assignment made based on 
the request


> > above be changed from an initial assignment to a permanent assignment.

How do you mean?

The registry is FCFS for which *any* document is sufficient.

The assignment has been made and is as permanent as any FCFS 
assignment ever is.


> > Please note that IANA cannot reserve specific values. However, early

> > allocation is available for some types of registrations. For more 
information,


> > please see RFC 7120.

Yes, but this is a FCFS registry to which 7120 does not apply, and nor 
does "reservation of values".


With FCFS the value is assigned when requested and that's it.

Now, it is a different question whether this document should ask for 
the registry to be updated to point to the consequent RFC instead of 
the I-D.


I think that might be valuable. So the IANA section should read...

IANA has previously made an allocation from the "BGP Tunnel Encapsulation

Attribute Tunnel Types" registry that reads:

Value| Name| Reference

+---+---

13| MPLS in UDP Encapsulation | [draft-ietf-l3vpn-end-system]

IANA is requested to change the reference to point to the RFC number

of this document when it is published.

Cheers,

Adrian



___
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

[bess] Poll for adoption: draft-rabadan-bess-dci-evpn-overlay

[Thomas Morin]

Hello working group,

This email starts a two-week poll on adopting
draft-rabadan-bess-dci-evpn-overlay [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 **December 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-rabadan-bess-dci-evpn-overlay

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

[bess] Poll for adoption: draft-rosen-l3vpn-ir

[Thomas Morin]

Hello working group,

This email starts a two-week poll on adopting draft-rosen-l3vpn-ir [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 **December 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-rosen-l3vpn-ir

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

Re: [bess] Last Call Comment draft-ietf-l3vpn-end-system-04.txt

[Thomas Morin]

Hi Benson,

2014-12-03 19:38, Benson Schliesser:
Simple: I agree that it should be relatively straight-forward to fix 
the namespace issue. While I'm not intimately familiar with it, I 
think that RFC 3688 describes how the appropriate namespace can be 
assigned. I'm comfortable describing this as editorial rather than 
material.


RFC 3688 provides a way to ask IANA to assign a URN for a schema. It 
doesn’t include guidelines on how that URN should look like. From the 
point of view of the draft in question it is simple to modify the 
examples to use TBD as a URN. However IANA would probably want 
guidance as to what name to assign. Does it make sense to include a 
suggestion in the IANA section ?




That makes sense to me. Maybe somebody else knows more about the 
process, and could give better feedback, but what you propose is 
exactly what I would do under the circumstances.


It was identified during shepherd review that a review of the XML 
specifics of these specs was probably a good idea.
We'll take the action of getting in touch with whoever ends up being the 
right person and identify the right solution for the namespace.



Probably very material: The draft really needs some kind of text 
around the various issues I included in the "Second" issue 
paragraph, in my previous message.

[Quote of this message:]
Second, the document doesn't seem to provide adequate operational 
guidance on how to determine the route server JID, how to determine the 
correct pubsub node values, etc. I assume that the server JID is a 
configurable option. And I assume that the pubsub node is equivalent to 
the 128 octet VPN ID. But neither seems to be spelled out clearly 
(unless I'm overlooking it) and in any case there don't seem to be any 
discussions of error handling. (In fact, the only comment I can find on 
the 'node' value suggests vaguely that perhaps all values are implicitly 
correct, in which case there needs to be some additional text about 
troubleshooting.)


Specifically, there needs to be some text about assignment of 
route-server JIDs. This should include some explanation about how 
route-server JIDs relate to the redundancy scheme that's sketched 
out in the draft. This should also include some kind of error 
handling discussion around incorrect JIDs being used in messages, 
etc. Much of the preceding also applies to pubsub 'node' values, 
with an emphasis on the error handling issues. It is possible that 
the authors have an editorial solution to this, which would avoid 
material changes to the draft text, but my limited imagination can't 
picture what that might look like.


The reference to the “jid” value in the RD assignment procedure is 
incorrect; This procedure uses the IP identifier of the compute node. 
Earlier versions of the document assume the JID to be the IP 
identifier… this is no longer the case.

Thank you for highlighting this… I’ll update the document.


I look forward to seeing the updated text. I'm not sure that your 
proposal covers all the issues that I've identified, but I'll wait to 
see the text before I leap to any conclusions. :)


Let's try to avoid being dependant of how fast we can loop through 
revision/feedback cycles, and anticipate resolutions.


What I think we need from you at this point, is (a) an exhaustive list 
of the issues you see, with a level of detail appropriate so that we are 
able to identify earlier in the process what changes are required to 
satisfy your concerns, and (b) early feedback to Pedro suggested changes 
(such as indication of issue that they would not address, if any).


For instance...
My guess is that Pedro's answer may address some of your concerns on the 
jabber ids, but possibly not the ones related to route-servers (how they 
are chosen and known to end-systems) and error handling. Is that correct 
?  On redundancy, can you provide more details on why you think is 
missing and why you think the redundancy scheme relates to how 
route-servers JIDs are chosen and known to end-systems ?


Best,

-Thomas
(as draft shepherd)




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

[bess] WG Last Call for draft-ietf-bess-mvpn-global-table-mcast

[Thomas Morin]

Hello working group,

This email starts a Working Group Last Call on
draft-ietf-bess-mvpn-global-table-mcast [1],
which is considered mature and ready for a last working group review.

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


Thank you,

-Thomas & Martin

[1] http://tools.ietf.org/html/draft-ietf-bess-mvpn-global-table-mcast


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

[bess] Draft minutes for our IETF91 sessions

[Thomas Morin]

Hi everyone,

Draft minutes for our 2 sessions during last IETF are at: 
http://tools.ietf.org/wg/bess/minutes


These minutes where compiled based on the impressively extensive minutes 
taken by John Scudder, complemented by the minutes taken by Lucy Yong 
and some notes by chairs. Thanks John and Lucy!


Everyone, please comment/correct or complete these minutes, whether on 
the list or directly on the etherpad (indicate your name in this case).


Best,

-Thomas

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

Re: [bess] Two minor last call comments on draft-ietf-l3vpn-acceptown-community-08.txt

[Thomas Morin]

Hi Adrian,

Adrian Farrel :

- Check whether you really need the pre-RFC5378 boilerplate and remove it if
possible



This was handled with authors during shepherd review: all agreed to 
grant appropriate rights, and removal of the boilerplate should be done 
in the next respin.


Best,

-Thomas

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

[bess] Last minute / agenda update for our session on Friday (service chaining)

[Thomas Morin]

Hi everyone,

We've updated our agenda for tomorrow's session to accommodate for a 
discussion on service-chaining:


Friday, 1150-1320 - Kahili
* draft-sajassi-bess-evpn-virtual-eth-segment, Ali, 10' including 
questions
* draft-sajassi-bess-evpn-etree, Ali, 10' including questions
* draft-sajassi-bess-evpn-vpls-seamless-integ, Ali, 10' including 
questions
* draft-boutros-l2vpn-evpn-vpws, Sami, 10' including questions
* draft-boutros-l2vpn-evpn-vxlan, Sami, 10' including questions
+   * draft-mackie-sfc-using-virtual-networking, Ron/Kireeti, 10' including 
questions
+   * draft-rfernando-l3vpn-service-chaining, **TBC**, 10' including 
questions
+   * / open discussion on service chaining, 20' including questions

Best,

Thomas & Martin
BESS chairs





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

[bess] Flowspec for L2VPN and E-VPN

[Thomas Morin]

Hi WG,

A heads up...

These two drafts relate to BESS and thus may be of interest to us:
- draft-hao-idr-flowspec-l2vpn 
 (on 
idr agenda, being presented right now)
- draft-hao-idr-flowspec-evpn 



Best,

-Thomas


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

[bess] Request for publication of draft-ietf-l3vpn-acceptown-community

[Thomas Morin]

IESG,

The L3VPN WG requests that draft-ietf-l3vpn-acceptown-community-08 be 
published as an RFC on the Standard track.


The shepherd write-up is in the datatacker [1].

Thank you,

-Thomas
for the BESS WG

[1] 
https://datatracker.ietf.org/doc/draft-ietf-l3vpn-acceptown-community/shepherdwriteup/


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