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

[Aldrin Isaac]

I would also like to indicate my support.  
Cheers,Aldrin






On Tue, Jan 31, 2017 at 6:58 AM -0800, "Thomas Morin"  
wrote:










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 mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call for draft-ietf-bess-dci-evpn-overlay-04

[Henderickx, Wim (Nokia - BE)]

Support, not aware of IPR related to this draft

On 07/02/2017, 07:42, "BESS on behalf of Dolganow, Andrew (Nokia - SG)" 
 wrote:

Support

Andrew

Sent from my iPhone

> On Feb 6, 2017, at 10:07 PM, Martin Vigoureux 
 wrote:
> 
> Hello Working Group,
> 
> This email starts a Working Group Last Call on 
draft-ietf-bess-dci-evpn-overlay-04 [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, and send your comments to the list, no later than
> *19th of February*.
> 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 Proposed 
Standard RFC.
> 
> *Coincidentally*, we are also polling for knowledge of any IPR that 
applies to draft-ietf-bess-dci-evpn-overlay, 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-dci-evpn-overlay-04 please respond to this email and 
indicate whether or not you are aware of any relevant IPR.
> 
> Note that IPR exists and has been disclosed against this document [2].
> 
> Thank you,
> M
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/
> [2] 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-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


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

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

Hi Himanshu,

Please see comments inline.

From: "Shah, Himanshu" >
Date: Tuesday, February 7, 2017 at 12:45 PM
To: Sami Boutros >, Sami 
Boutros >, Iftekhar 
Hussain >
Cc: Jeffrey Zhang >, "Alvaro 
Retana (aretana)" >, 
"bess-cha...@ietf.org" 
>, 
"bess@ietf.org" >, 
"draft-ietf-bess-evpn-v...@ietf.org" 
>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

It seems to me that single-active multihoming case could use some more 
clarification text.

I think there should be an additional field in L2 extended community
as (for example) “election priority” so that each multi-homed member can 
definitely tell
to each other as well as to remote PE who/what primary election order would be.

[Sami] In single active, there would be only one primary as per definition 
below in this e-mail.

Thus, when ESI link to primary fails, remote PE can quickly change the next hop
to next priority PE multi-home member.

[Sami] Extending the DF election is not in scope for the draft and I doubt we 
will include it, however there are other drafts extending DF election like 
rabadan-evpn-pref-df.

The text in VPWS draft is not very clear.

It seems to suggest there could be multiple primaries and backups.
But if that is true how would remote PE can independently switchover to backup 
PE
(i.e. which backup PE?).

[Sami] As per draft, "A remote PE receiving B=1 from more than one PE will 
select only one backup PE."

If there are multiple primary PEs, and if one of them fail, why not switchover 
to other
primary PE, so on and so forth..

[Sami] In single active there should be only one primary, having more than one 
primary will be transit in this case.

So what is the intent?

[Sami] As per EVPN, the intent is to support A/A in which all will be primary, 
or A/S in which only one primary and one backup.

One primary, one backup
Multiple primary, one backup
Or (one or) multiple primaries, multiple backups?

[Sami] We are not redefining what single active or all active mean, this is as 
per EVPN RFC7432

Single-Active Redundancy Mode: When only a single PE, among all the
  PEs attached to an Ethernet segment, is allowed to forward traffic
  to/from that Ethernet segment for a given VLAN, then the Ethernet
  segment is defined to be operating in Single-Active redundancy
  mode.


I.e. One primary and one/multiple backup.


   All-Active Redundancy Mode: When all PEs attached to an Ethernet
  segment are allowed to forward known unicast traffic to/from that
  Ethernet segment for a given VLAN, then the Ethernet segment is
  defined to be operating in All-Active redundancy mode.

 I.e. Multiple Primary


Also, there has to be corresponding understanding/configuration in CE as well.
So if the CE+multi-hommed-PEs configuration is consistent and if all the 
parties,
(CE, multi-homed PEs and remote PE) are aware of this, selection algorithm 
would work better?

[Sami] Again, we are not redefining EVPN multihoming or DF election, those are 
following base EVPN.

Thanks,

Sami

Thanks,
Himanshu

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Sami Boutros
Sent: Tuesday, February 07, 2017 2:06 PM
To: Sami Boutros >; 
Iftekhar Hussain >
Cc: Jeffrey Zhang >; Alvaro 
Retana (aretana) >; 
bess-cha...@ietf.org; 
bess@ietf.org; 
draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Iftekhar,

Are you ok with what I added to the doc? For presenting the entity for 
Management.

VPWS Service Instance: It is represented by a pair of EVPN service labels 
associated with a pair of endpoints. Each label is downstream assigned and 
advertised by the disposition PE through an Ethernet A-D per-EVI route. The 
downstream label identifies the endpoint on the disposition PE. A VPWS service 
instance can be associated with only one VPWS service identifier.

Thanks,

Sami

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

[bess] I-D Action: draft-ietf-bess-evpn-vpws-08.txt

[internet-drafts]

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   : VPWS support in EVPN
Authors : Sami Boutros
  Ali Sajassi
  Samer Salam
  John Drake
  Jorge Rabadan
Filename: draft-ietf-bess-evpn-vpws-08.txt
Pages   : 14
Date: 2017-02-07

Abstract:
   This document describes how EVPN can be used to support Virtual
   Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the
   following characteristics for VPWS: single-active as well as all-
   active multi-homing with flow-based load-balancing, eliminates the
   need for traditional way of PW signaling, and provides fast
   protection convergence upon node or link failure.


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

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

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


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

[Shah, Himanshu]

Hi Sami –

It seems to me that single-active multihoming case could use some more 
clarification text.

I think there should be an additional field in L2 extended community
as (for example) “election priority” so that each multi-homed member can 
definitely tell
to each other as well as to remote PE who/what primary election order would be.

Thus, when ESI link to primary fails, remote PE can quickly change the next hop
to next priority PE multi-home member.

The text in VPWS draft is not very clear.

It seems to suggest there could be multiple primaries and backups.
But if that is true how would remote PE can independently switchover to backup 
PE
(i.e. which backup PE?).

If there are multiple primary PEs, and if one of them fail, why not switchover 
to other
primary PE, so on and so forth..

So what is the intent?

One primary, one backup
Multiple primary, one backup
Or (one or) multiple primaries, multiple backups?

Also, there has to be corresponding understanding/configuration in CE as well.
So if the CE+multi-hommed-PEs configuration is consistent and if all the 
parties,
(CE, multi-homed PEs and remote PE) are aware of this, selection algorithm 
would work better?

Thanks,
Himanshu

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Sami Boutros
Sent: Tuesday, February 07, 2017 2:06 PM
To: Sami Boutros ; Iftekhar Hussain 

Cc: Jeffrey Zhang ; Alvaro Retana (aretana) 
; bess-cha...@ietf.org; bess@ietf.org; 
draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Iftekhar,

Are you ok with what I added to the doc? For presenting the entity for 
Management.

VPWS Service Instance: It is represented by a pair of EVPN service labels 
associated with a pair of endpoints. Each label is downstream assigned and 
advertised by the disposition PE through an Ethernet A-D per-EVI route. The 
downstream label identifies the endpoint on the disposition PE. A VPWS service 
instance can be associated with only one VPWS service identifier.

Thanks,

Sami

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

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Iftekhar Hussain]

Hi Sami,

Please see in-line {iftekhar2]

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Sunday, February 05, 2017 11:59 AM
To: Iftekhar Hussain
Cc: Alvaro Retana (aretana); Jeffrey Zhang; bess-cha...@ietf.org; 
bess@ietf.org; draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Attached is the draft updated with the VPWS Service instance (control plane 
managed entity) definition in the terminology section and with the general VPWS 
reference to RFC4664]
Hi Iftekhar,

Please see inline

Hi Authors,

I support this work. However, I do have few comments that I would like to add 
to the list from the AD:

· Section 1:  The terms ES and ACs are used interchangeably (e.g., see 
“….Ethernet Virtual Private Line (EVPL) service as p2p service between a pair 
of ACs” and “…Ethernet Private Line (EPL) service … a single pair of ESes” .  
This is confusing. What is the reason for not considering a port as an AC?

Suggestion: Please include a complete service entity reference mode in this 
draft. Clearly indicate what entities are involved to provision a VPWS (for 
example, ES-AC - LSP etc.). This will also be extremely useful for data 
modeling of the service.
Sami: I am not sure I get this, we spend a lot of time on this on the list to 
conclude to the text in Place for ES and AC. I am not sure changing any of that 
will clarify or confuse.

Iftekhar:  I am not saying you didn’t spend enough time. What I am saying is at 
least to me the equivalence of AC and ES is not clear. Are you saying AC == ES? 
 As I understand, these two constructs are not equivalent. AC is a data plane 
construct while ES appears to be purely a control plane construct. Okay for the 
sake of argument, say ES and AC are equivalent. Then why do you need AC? 
Moreover, what will be the data plane entity representation of VPWS-EVPN  for 
EVPL and EPL look like? Would it be AC- (xconnect) label – LSP or ES- 
(xconnect) – LSP?

If you have a look at the terminology section it clarifies what exactly we mean 
by ES in the doc it refers to the link/port attached to the PE and we refer to 
AC as the VLAN like port. Like Pwe3 the evpn p2p lsp can be looked at as a Pw 
construct. By the way AC is both a data and control plane construct. We are not 
redefining what EVPL or EPL means but on a given PE we are cross connecting a 
port or a VLAN like service to an evpn signaled p2p bidir lsp using evpn-vpws.


[Iftekhar2] “….refer to AC as the VLAN like port”. My question is why a port is 
not an AC? In my understanding an AC can be a single VLAN, multiple (list or 
range of VLANs) including the entire port (all VLANs). My suggestion is even 
for the EPL (port-based service) – you should use the term AC (as opposed to 
ES). In addition, if you need the notion of ES to define the service that is 
okay. My earlier question was if you could provide an example of all the 
management entities involved for configuring a EVPL and a EPL service using the 
VPWS-EVPN solution that would be helpful.

Having said that I don’t want to hold your doc back, if other folks, are happy 
with the current state of the doc and want to proceed to the next step that is 
fine.


· Section 1: “…whereas, for more general VPWS,…”  What is a more 
general VPWS?

Sami: Please refer to 
https://tools.ietf.org/html/rfc4664
 for the general VPWS definition. I will add a reference to it in the doc.

Iftekhar: Okay.


· Section 1: It is hard to keep track of what enhancements are being 
proposed and what functionalities defined in RFC7432 applies or don’t apply to 
VPWS.

Sami: The only change is making the Ethernet tag ID setting to a non zero value 
a MUST, this is explicitly mentioned in section 1

"Unlike EVPN where Ethernet Tag ID in EVPN routes are set to zero for 
Port-based, vlan-based, and vlan-bundle interface mode and it is set to 
non-zero Ethernet tag ID for vlan-aware bundle mode, in EVPN-VPWS, for all the 
four interface modes, Ethernet tag ID in the Ethernet A-D route MUST be set to 
a non-zero value in all the service interface types."

Iftekhar: Let me give couple of examples. Does (a) MAC/IP route (type2) or 
Inclusive Multicast Ethernet Tag route (type 3) (b) MAC Mobility Extended 
Community or  Default Gateway Extended Community  defined in RFC7432 apply to 
EVPN-VPWS?  If not, it would be useful that this document clarifies it.


The document clearly mention that there is no Mac related routes, or bridge 
like service related routes not sure what more clarifications we need. 
Enumerating route types and extended communities not supported doesn't make 
sense given that EVPN is still adding more route types and more extended 
communities in several drafts 

Re: [bess] [ALU] WG Last Call for draft-ietf-bess-dci-evpn-overlay-04

[Diego Garcia del Rio]

Support 










On Tue, Feb 7, 2017 at 3:56 PM -0300, "Oya Luengo, Roberto (Nokia - US)" 
 wrote:










Support

On 2/6/17, 5:07 AM, "BESS on behalf of Martin Vigoureux"
 wrote:

>Hello Working Group,
>
>This email starts a Working Group Last Call on
>draft-ietf-bess-dci-evpn-overlay-04 [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, and send your comments to the list, no later than
>*19th of February*.
>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 Proposed
>Standard RFC.
>
>*Coincidentally*, we are also polling for knowledge of any IPR that
>applies to draft-ietf-bess-dci-evpn-overlay, 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-dci-evpn-overlay-04 please respond to this email and
>indicate whether or not you are aware of any relevant IPR.
>
>Note that IPR exists and has been disclosed against this document [2].
>
>Thank you,
>M
>
>[1] https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/
>[2] 
>https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-bess-d
>ci-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





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

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

Hi Iftekhar,

Are you ok with what I added to the doc? For presenting the entity for 
Management.

VPWS Service Instance: It is represented by a pair of EVPN service labels 
associated with a pair of endpoints. Each label is downstream assigned and 
advertised by the disposition PE through an Ethernet A-D per-EVI route. The 
downstream label identifies the endpoint on the disposition PE. A VPWS service 
instance can be associated with only one VPWS service identifier.

Thanks,

Sami

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

Re: [bess] [ALU] WG Last Call for draft-ietf-bess-dci-evpn-overlay-04

[Wen Lin]

Support.

Thanks,
Wen

On 2/7/17, 1:56 PM, "BESS on behalf of Oya Luengo, Roberto (Nokia - US)" 
 wrote:

Support

On 2/6/17, 5:07 AM, "BESS on behalf of Martin Vigoureux"
 wrote:

>Hello Working Group,
>
>This email starts a Working Group Last Call on
>draft-ietf-bess-dci-evpn-overlay-04 [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, and send your comments to the list, no later than
>*19th of February*.
>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 Proposed
>Standard RFC.
>
>*Coincidentally*, we are also polling for knowledge of any IPR that
>applies to draft-ietf-bess-dci-evpn-overlay, 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-dci-evpn-overlay-04 please respond to this email and
>indicate whether or not you are aware of any relevant IPR.
>
>Note that IPR exists and has been disclosed against this document [2].
>
>Thank you,
>M
>
>[1] https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/
>[2] 
>https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-bess-d
>ci-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


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

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

[Wen Lin]

Support as a co-author.

Thanks,
Wen

On 1/31/17, 9:58 AM, "Thomas Morin"  wrote:

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

Re: [bess] [ALU] WG Last Call for draft-ietf-bess-dci-evpn-overlay-04

[Oya Luengo, Roberto (Nokia - US)]

Support

On 2/6/17, 5:07 AM, "BESS on behalf of Martin Vigoureux"
 wrote:

>Hello Working Group,
>
>This email starts a Working Group Last Call on
>draft-ietf-bess-dci-evpn-overlay-04 [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, and send your comments to the list, no later than
>*19th of February*.
>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 Proposed
>Standard RFC.
>
>*Coincidentally*, we are also polling for knowledge of any IPR that
>applies to draft-ietf-bess-dci-evpn-overlay, 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-dci-evpn-overlay-04 please respond to this email and
>indicate whether or not you are aware of any relevant IPR.
>
>Note that IPR exists and has been disclosed against this document [2].
>
>Thank you,
>M
>
>[1] https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/
>[2] 
>https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-bess-d
>ci-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] WG Last Call for draft-ietf-bess-dci-evpn-overlay-04

[Sathappan, Senthil (Nokia - US)]

Support as co-author. 
I am not aware of any IPR that has not been disclosed yet.
Thanks,
Senthil.

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Rabadan, Jorge (Nokia - 
US)
Sent: Monday, February 06, 2017 11:45 PM
To: Vigoureux, Martin (Nokia - FR); bess@ietf.org
Subject: [ALU] Re: [bess] WG Last Call for draft-ietf-bess-dci-evpn-overlay-04

As a co-author, I fully support this document for publication as Proposed 
Standard RFC.
Nokia SROS has an implementation of this draft and it is deployed in some 
networks.

I am not aware of any IPR that has not been disclosed yet.

Thank you.
Jorge

On 2/6/17, 2:14 PM, "BESS on behalf of Martin Vigoureux"  wrote:

WG,

major omission in my previous e-mail:
¤ We are also polling for knowledge of implementations of part or all of 
what this document specifies. This information is expected as per [3]. 
Please inform the mailing list, or the chairs, or only one of the chairs.

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

-m

Le 06/02/2017 à 14:07, Martin Vigoureux a écrit :
> Hello Working Group,
>
> This email starts a Working Group Last Call on
> draft-ietf-bess-dci-evpn-overlay-04 [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, and send your comments to the list, no later than
> *19th of February*.
> 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 Proposed
> Standard RFC.
>
> *Coincidentally*, we are also polling for knowledge of any IPR that
> applies to draft-ietf-bess-dci-evpn-overlay, 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-dci-evpn-overlay-04 please respond to this email and
> indicate whether or not you are aware of any relevant IPR.
>
> Note that IPR exists and has been disclosed against this document [2].
>
> Thank you,
> M
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/
> [2]
> 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-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


___
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] WG Last Call for draft-ietf-bess-dci-evpn-overlay-04

[Dolganow, Andrew (Nokia - SG)]

Support

Andrew

Sent from my iPhone

> On Feb 6, 2017, at 10:07 PM, Martin Vigoureux  
> wrote:
> 
> Hello Working Group,
> 
> This email starts a Working Group Last Call on 
> draft-ietf-bess-dci-evpn-overlay-04 [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, and send your comments to the list, no later than
> *19th of February*.
> 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 Proposed Standard 
> RFC.
> 
> *Coincidentally*, we are also polling for knowledge of any IPR that applies 
> to draft-ietf-bess-dci-evpn-overlay, 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-dci-evpn-overlay-04 please respond to this email and indicate 
> whether or not you are aware of any relevant IPR.
> 
> Note that IPR exists and has been disclosed against this document [2].
> 
> Thank you,
> M
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/
> [2] 
> https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-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] WG Last Call for draft-ietf-bess-dci-evpn-overlay-04

[Walsh, Brian (Nokia - SG)]

Support.

Thx,
Brian

-Original Message-
From: BESS  on behalf of Martin Vigoureux 

Date: Monday, 6 February 2017 at 9:14 PM
To: "bess@ietf.org" 
Subject: Re: [bess] WG Last Call for draft-ietf-bess-dci-evpn-overlay-04

WG,

major omission in my previous e-mail:
¤ We are also polling for knowledge of implementations of part or all of 
what this document specifies. This information is expected as per [3]. 
Please inform the mailing list, or the chairs, or only one of the chairs.

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

-m

Le 06/02/2017 à 14:07, Martin Vigoureux a écrit :
> Hello Working Group,
>
> This email starts a Working Group Last Call on
> draft-ietf-bess-dci-evpn-overlay-04 [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, and send your comments to the list, no later than
> *19th of February*.
> 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 Proposed
> Standard RFC.
>
> *Coincidentally*, we are also polling for knowledge of any IPR that
> applies to draft-ietf-bess-dci-evpn-overlay, 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-dci-evpn-overlay-04 please respond to this email and
> indicate whether or not you are aware of any relevant IPR.
>
> Note that IPR exists and has been disclosed against this document [2].
>
> Thank you,
> M
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/
> [2]
> 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-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


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

Re: [bess] WG Last Call for draft-ietf-bess-dci-evpn-overlay-04

[Jeff Tantsura]

Yes/support
On Tue, Feb 7, 2017 at 00:06 Ali Sajassi (sajassi) 
wrote:

>
> Support as a co-author. Cisco has implemented this draft and it has
> deployments based on some sections of this draft. I am not aware of any
> IPR that hasn’t already been disclosed.
>
> Cheers,
> Ali
>
> On 2/6/17, 5:14 AM, "BESS on behalf of Martin Vigoureux"
>  wrote:
>
> >WG,
> >
> >major omission in my previous e-mail:
> >¤ We are also polling for knowledge of implementations of part or all of
> >what this document specifies. This information is expected as per [3].
> >Please inform the mailing list, or the chairs, or only one of the chairs.
> >
> >[3]
> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
> >
> >-m
> >
> >Le 06/02/2017 à 14:07, Martin Vigoureux a écrit :
> >> Hello Working Group,
> >>
> >> This email starts a Working Group Last Call on
> >> draft-ietf-bess-dci-evpn-overlay-04 [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, and send your comments to the list, no later than
> >> *19th of February*.
> >> 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 Proposed
> >> Standard RFC.
> >>
> >> *Coincidentally*, we are also polling for knowledge of any IPR that
> >> applies to draft-ietf-bess-dci-evpn-overlay, 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-dci-evpn-overlay-04 please respond to this email and
> >> indicate whether or not you are aware of any relevant IPR.
> >>
> >> Note that IPR exists and has been disclosed against this document [2].
> >>
> >> Thank you,
> >> M
> >>
> >> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/
> >> [2]
> >>
> >>
> https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-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
>
> ___
> 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] WG Last Call for draft-ietf-bess-dci-evpn-overlay-04

[Ali Sajassi (sajassi)]

Support as a co-author. Cisco has implemented this draft and it has
deployments based on some sections of this draft. I am not aware of any
IPR that hasn’t already been disclosed.

Cheers,
Ali

On 2/6/17, 5:14 AM, "BESS on behalf of Martin Vigoureux"
 wrote:

>WG,
>
>major omission in my previous e-mail:
>¤ We are also polling for knowledge of implementations of part or all of
>what this document specifies. This information is expected as per [3].
>Please inform the mailing list, or the chairs, or only one of the chairs.
>
>[3] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>-m
>
>Le 06/02/2017 à 14:07, Martin Vigoureux a écrit :
>> Hello Working Group,
>>
>> This email starts a Working Group Last Call on
>> draft-ietf-bess-dci-evpn-overlay-04 [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, and send your comments to the list, no later than
>> *19th of February*.
>> 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 Proposed
>> Standard RFC.
>>
>> *Coincidentally*, we are also polling for knowledge of any IPR that
>> applies to draft-ietf-bess-dci-evpn-overlay, 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-dci-evpn-overlay-04 please respond to this email and
>> indicate whether or not you are aware of any relevant IPR.
>>
>> Note that IPR exists and has been disclosed against this document [2].
>>
>> Thank you,
>> M
>>
>> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/
>> [2]
>> 
>>https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-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

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