date:20170224

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

2017-02-24 Thread Alvaro Retana (aretana)

Sami:

The reference to RFC5226 should be Normative.  Other than that, it looks good 
to me.

Thanks!

Alvaro.

On 2/24/17, 2:54 PM, "Sami Boutros"  wrote:

> Attached is the -10 draft with all updates. If All good, I will submit it 
> Monday.

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

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

2017-02-24 Thread Shah, Himanshu

In red..

Thanks,
Himanshu

From: BESS  on behalf of Sami Boutros 

Date: Friday, February 24, 2017 at 2:29 PM
To: "Shah, Himanshu" , Alvaro Retana , 
"draft-ietf-bess-evpn-v...@ietf.org" 
Cc: Jeffrey Zhang , "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Himanshu,

Please see comments inline.

Hi Sami –

Some more comments for your consideration (based on -09- version) –
Many of the followings are either clarifications related or editorial.

1-

Overall comment : the draft uses long sentences, short sentences are more
favored (at least that is the feedback I used to get for my drafts).

For example:
--- original text --
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.

This could be written as –

Ethernet tag ID in Ethernet A-D route MUST be set to a non-zero value
irrespective of the service interface types. This is a deviation from
what is expected for EVPN. In EVPN, Ethernet Tag ID in EVPN routes are
set to zero for Port-based, vlan-based and vlan-bundle interface mode
while non-zero Ethernet tag ID only for vlan-aware bundle mode.

[Sami] We are defining new interface types in other drafts, so we can’t say in 
the above text
For all a service interface types for example, honestly I am not in favor to 
change the text.

[Himanshu] OK. I understand the intent. You note the issue on using 
“irrespective
of service interface types”. You can append that as “irrespective of service
interface types defined in this document”.

But this was a suggestion for better reading. Leave it or take it.. ☺
2-

In section 2.1

Original text ---

If the VLAN is represented by different VIDs on different PEs.
(note there should not be a period here)
[Himanshu] do note the comment on this ‘period’
(e.g., a different VID per Ethernet segment per PE), then each PE needs to
perform VID translation for frames destined to its Ethernet segment.

Comment ---

This particular paragraph is somewhat confusing. The confusing part is
That text seems to indicate that multiple PEs connected to an ES may
see same VLAN as different VID (which I believe is not true).

[Sami] This is not what the text is indicating.

For
example, PE members PE1 and PE2 of same ESx, may see VID 100 for PE1
but 101 for PE2.

[Sami] This is simply not possible, since the source of traffic on the ES is 
one for both PE1 and PE2.

[Himanshu] but of course. That is the point. It needs clarifying and the text
you offer below would work as well.
I believe what you are trying to convey is PEs on
local ES and PEs on remote ES may have different VIDs.

[Sami] I will add to the above text, on different PE (s) and different ES (es) 
instead of different PE (s)

It can be clarified as –

If the VLAN is represented by different VIDs on local PEs (connected
to local ES) and remote PEs (connected to remote ES), then each PE
needs to perform VID translation for frames destined to its Ethernet segment.

---
3- editorial

Original text for page 8 –

A remote PE SHOULD receive P=1 from only one Primary PE and a B-1 from only one 
Backup PE.

Comment –
B=1

[Sami] Sure will fix.

4- clarification

original text –

This allows an ingress PE to perform flow-based load-balancing
of traffic flows to all of the PEs attached to that ES.

Comment --

In multi-homed All-active configuration, this allows an ingress PE to perform
Flow-based load-balancing of traffic flows to all the PEs attached to that ES.

(I am assuming that in VPWS, single active multi-homing, there is load-balancing
from remote to local multi-homed PEs – Right??)

[Sami] Ok I will add that this is for all-active.

Thanks,

Sami

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

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

2017-02-24 Thread Sami Boutros

Hi Himanshu,

Please see comments inline.



Hi Sami –

Some more comments for your consideration (based on -09- version) –
Many of the followings are either clarifications related or editorial.

1-

Overall comment : the draft uses long sentences, short sentences are more
favored (at least that is the feedback I used to get for my drafts).

For example:
--- original text --
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.

This could be written as –

Ethernet tag ID in Ethernet A-D route MUST be set to a non-zero value
irrespective of the service interface types. This is a deviation from
what is expected for EVPN. In EVPN, Ethernet Tag ID in EVPN routes are
set to zero for Port-based, vlan-based and vlan-bundle interface mode
while non-zero Ethernet tag ID only for vlan-aware bundle mode.


[Sami] We are defining new interface types in other drafts, so we can’t say in 
the above text
For all a service interface types for example, honestly I am not in favor to 
change the text.

2-

In section 2.1

Original text ---

If the VLAN is represented by different VIDs on different PEs.
(note there should not be a period here)
(e.g., a different VID per Ethernet segment per PE), then each PE needs to
perform VID translation for frames destined to its Ethernet segment.

Comment ---

This particular paragraph is somewhat confusing. The confusing part is
That text seems to indicate that multiple PEs connected to an ES may
see same VLAN as different VID (which I believe is not true).

[Sami] This is not what the text is indicating.

For
example, PE members PE1 and PE2 of same ESx, may see VID 100 for PE1
but 101 for PE2.

[Sami] This is simply not possible, since the source of traffic on the ES is 
one for both PE1 and PE2.

I believe what you are trying to convey is PEs on
local ES and PEs on remote ES may have different VIDs.

[Sami] I will add to the above text, on different PE (s) and different ES (es) 
instead of different PE (s)

It can be clarified as –

If the VLAN is represented by different VIDs on local PEs (connected
to local ES) and remote PEs (connected to remote ES), then each PE
needs to perform VID translation for frames destined to its Ethernet segment.

---
3- editorial

Original text for page 8 –

A remote PE SHOULD receive P=1 from only one Primary PE and a B-1 from only one 
Backup PE.

Comment –
B=1


[Sami] Sure will fix.

4- clarification

original text –

This allows an ingress PE to perform flow-based load-balancing
of traffic flows to all of the PEs attached to that ES.



Comment --

In multi-homed All-active configuration, this allows an ingress PE to perform
Flow-based load-balancing of traffic flows to all the PEs attached to that ES.

(I am assuming that in VPWS, single active multi-homing, there is load-balancing
from remote to local multi-homed PEs – Right??)

[Sami] Ok I will add that this is for all-active.


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

2017-02-24 Thread Shah, Himanshu

Hi Sami –

Some more comments for your consideration (based on -09- version) –
Many of the followings are either clarifications related or editorial.

1-

Overall comment : the draft uses long sentences, short sentences are more
favored (at least that is the feedback I used to get for my drafts).

For example:
--- original text --
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.

This could be written as –

Ethernet tag ID in Ethernet A-D route MUST be set to a non-zero value
irrespective of the service interface types. This is a deviation from
what is expected for EVPN. In EVPN, Ethernet Tag ID in EVPN routes are
set to zero for Port-based, vlan-based and vlan-bundle interface mode
while non-zero Ethernet tag ID only for vlan-aware bundle mode.


2-

In section 2.1

Original text ---

If the VLAN is represented by different VIDs on different PEs.
(note there should not be a period here)
(e.g., a different VID per Ethernet segment per PE), then each PE needs to
perform VID translation for frames destined to its Ethernet segment.

Comment ---

This particular paragraph is somewhat confusing. The confusing part is
That text seems to indicate that multiple PEs connected to an ES may
see same VLAN as different VID (which I believe is not true). For
example, PE members PE1 and PE2 of same ESx, may see VID 100 for PE1
but 101 for PE2. I believe what you are trying to convey is PEs on
local ES and PEs on remote ES may have different VIDs.

It can be clarified as –

If the VLAN is represented by different VIDs on local PEs (connected
to local ES) and remote PEs (connected to remote ES), then each PE
needs to perform VID translation for frames destined to its Ethernet segment.

---
3- editorial

Original text for page 8 –

A remote PE SHOULD receive P=1 from only one Primary PE and a B-1 from only one 
Backup PE.

Comment –
B=1


4- clarification

original text –

This allows an ingress PE to perform flow-based load-balancing
of traffic flows to all of the PEs attached to that ES.



Comment --

In multi-homed All-active configuration, this allows an ingress PE to perform
Flow-based load-balancing of traffic flows to all the PEs attached to that ES.

(I am assuming that in VPWS, single active multi-homing, there is load-balancing
from remote to local multi-homed PEs – Right??)

--

Thanks,
Himanshu

From: BESS  on behalf of Alvaro Retana 

Date: Friday, February 24, 2017 at 10:17 AM
To: Sami Boutros , "draft-ietf-bess-evpn-v...@ietf.org" 

Cc: Jeffrey Zhang , "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

One more thing…you’re missing the reference to RFC5226.

Thanks!

Alvaro.

___
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] Last Call: (VPWS support in EVPN) to Proposed Standard

2017-02-24 Thread The IESG


The IESG has received a request from the BGP Enabled ServiceS WG (bess)
to consider the following document:
- 'VPWS support in EVPN'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2017-03-10. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ballot/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/2635/
   https://datatracker.ietf.org/ipr/2125/





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

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

2017-02-24 Thread Alvaro Retana (aretana)

One more thing…you’re missing the reference to RFC5226.

Thanks!

Alvaro.

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

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

2017-02-24 Thread Alvaro Retana (aretana)

On 2/21/17, 12:39 PM, "Sami Boutros"  wrote:

Sami:

Hi!

> Please see comments inline. I have submitted 09.

I just have a couple of small things below, the biggest being the 24-bit 
alignment – which seems to be resolved on the list.

I’m going to start the IETF Last Call, but please update the draft when you get 
a chance.

Thanks,

Alvaro.

…
> > > > M5.1. Section 3: “Ethernet Tag ID 32-bit field is set to the 24-bit 
> > > > VPWS service instance 
> > > > identifier” 
> > > > How should this be aligned into the larger field?
> > >  
> > > Sami: Changed the text to "This document specifies the use of the per EVI 
> > > Ethernet A-D route 
> > > to signal VPWS services. The Ethernet Segment Identifier field is set to 
> > > the customer ES and 
> > > the Ethernet Tag ID 32-bit field MUST be set to the 24-bit VPWS service 
> > > instance identifier 
> > > value."
> >
> > Ok, but you still didn’t mention how the 24-bit value is to be aligned in 
> > the 32-bit field.  I’m 
> > guessing there will be some 0-padding, but will that the at the beginning 
> > or the end?
> >
>
> I made the VPWS service instance identifier a 32-bit value in the new draft.

I also like Patrice’s suggestion [1]

[1] 
https://mailarchive.ietf.org/arch/msg/bess/hYuoAvF4eeYVSRRrlVi8MQMOf3Y/?qid=50f2dee8ec109478be61f1e0aefd03a5
 


…
> > > > P2. The [MEF] reference didn’t work for me; on all tries the connection 
> > > > timed out.  Is it 
> > > > possible to find a more stable reference?
> > > 
> > > Sami: No clue here!
> > How about this:  https://urldefense.proofpoint.com/v2/url?u=https-
3A__www.mef.net_Assets_Technical-5FSpecifications_PDF_MEF-5F6.1.pdf&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=GH5FIfqtBUACPwx-LVV2v5zPrGcNzhCEjfj8-0-R2OI&s=5b19ceQDqdsz0TepqsV7daJoYm9uDMyco7BZ4NeICWU&e=
   ??
> > 
> 
> Thanks,

Sorry, I don’t know why we ended up with that long thing, this is the short 
one: https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_6.1.pdf


> > …
> > > > P9. There is no Reference to any of the Extended Communities RFCs: 
> > > > 4360, 7153, etc…
> > >
> > > Sami: Done.
> >
> > We still need a reference to rfc4360 – at least in Section 3.1 where the 
> > new community is 
> > defined.
> >
> > You did add a reference to rfc7153, but it is not used in the text. ☹  
> > There’s no point in having it 
> > if it isn’t used!
> 
> I changed the text as follow in 3.1 and added/removed the above references.
>
> "This draft proposes a new extended community, defined below as per [RFC7432] 
> in addition to 
> the values specified in [RFC4360]"

This is enough: “This draft proposes a new extended community [RFC4360]…”.


___
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

2017-02-24 Thread Patrice Brissette (pbrisset)

Folks,

I’m not aware of any IPR on that draft.
And I support it

Regards,
Patrice Brissette

On 2017-02-24, 4:28 AM, "BESS on behalf of Martin Vigoureux" 
 wrote:

All,

there is good support for this document, but we are missing few answers 
to the IPR question.
As soon as they come in we'll move towards publication.

Thanks
-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&T
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/
> [2]
> 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=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

2017-02-24 Thread Martin Vigoureux


All,

there is good support for this document, but we are missing few answers 
to the IPR question.

As soon as they come in we'll move towards publication.

Thanks
-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&T

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/
[2]
https://datatracker.ietf.org/ipr/search/?submit=draft&id=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] AD Review of draft-ietf-bess-evpn-vpws-07

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

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

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

[bess] Last Call: (VPWS support in EVPN) to Proposed Standard

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

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

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

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

9 matches

Site Navigation

Mail list logo

Footer information