[bess] AD Review of draft-ietf-bess-evpn-etree-09

[Alvaro Retana (aretana)]

Dear authors:

I just finished reading this document.  In general, the document could benefit 
from an editorial pass to improve readability; I put in some suggestions below, 
but I’m sure I didn’t mention all.  I don’t think that my comments (even the 
Major ones) will be hard to resolve – most are around providing clarity and 
consistency.  I’ll wait for a revised draft before starting the IETF Last Call.

Thanks!

Alvaro.



Major:

M1. Both the Introduction and the Abstract mention that “this document 
discusses how the functional requirements for E-Tree service can be easily 
met…”  It seems to me that RFC7387 is used as the building block for this 
document.  Why is it not a Normative reference?


M2. There is no reference to E-Tree.  Please add a Normative one.


M3. In Section 2.2 (Scenario 2: Leaf OR Root site(s) per AC): “…then a single 
RT per EVI MAY be used…”  I think that “MAY” is out of place because it seems 
to be expressing just a fact.  Also, please keep the normative language where 
the operation is defined (in this case in 3.1).


M4. Section 3.1 (Known Unicast Traffic) talks about how in the “multi-homing 
scenario of section 2.2…the PE MAY advertise leaf indication along with the 
Ethernet A-D per EVI route”.  Given that the text later says that “in case of 
discrepancy, the multi-homing for that pair of PEs is assumed to be in default 
"root" mode”, I find the “MAY” not sufficient.  If we want to prevent as many 
discrepancies as possible, shouldn’t that be a “SHOULD” (or even a “MUST”)?   
Given the local configuration, why would the PE not want to include the leaf 
indication…ever…?


M5. In Section 5.1 (E-TREE Extended Community) there is redundant information 
(first and last paragraphs).  Among that redundant information there is no 
consistency: “the Leaf Label field is set to a valid MPLS label” and “the Leaf 
Label MUST be set to a valid MPLS label” – please be consistent and specify 
things just once.

M5.1. BTW, that is a “valid MPLS label”?  How would a receiver recognize it?  
Please add a reference to avoid confusion.


M6. Definition of the E-TREE Extended Community

M6.1. Only one Flag is defined.  What about the others?  Please set up a 
registry.

M6.2. [Minor] Please put a Figure number and heading for the community format.

M6.3. It looks like the Reserved fields are set to 0.  What should happen if 
the receiver gets something else?

M6.4. “…the Leaf-Indication flag MUST be set to one and Leaf Label is set to 
zero. The received PE should ignore Leaf Label and only processes 
Leaf-Indication flag.”  What if the Leaf Label is not set to zero?  The second 
sentence says to ignore it, but the first one that it “MUST be…set to zero”.  
Which one is it?  Maybe both…  Be specific!

M6.5. “…the Leaf Label MUST be set to a valid MPLS label and the 
Leaf-Indication flag should be set to zero. The received PE should ignore the 
Leaf-Indication flag.”  Similar question for the Leaf-Indication bit.

M6.6. “A non-valid MPLS label when sent along with the Ethernet A-D per ES 
route, should be logged as an error.”  I’m assuming that not only the logging 
is needed, but is the route ignored/discarded too?


M7. The PMSI Tunnel Attribute:  Please be clear to the fact that the C bit is 
being defined/introduced in this document (and not just start talking about it 
as if it is well-known to every reader).

M7.1. It is not clear to me how the C bit is to be used.  Section 5.2 says that 
“the high-order bit of the tunnel type field (C bit - Composite tunnel bit) is 
set while the remaining low-order seven bits indicate the tunnel type as 
before.”   But 3.3.1 says that the “new composite tunnel type is advertised by 
the root PE to simultaneously indicate a P2MP tunnel in transmit direction and 
an ingress-replication tunnel in the receive direction…”.  Knowing, from 5.2 
that when the C bit is set “Tunnel Types…0x06 'Ingress Replication' is 
invalid”, then does the C bit have a set meaning or ???   [BTW, s/is/are]

M7.2. [Minor] In some places you talk about the “C bit” or “Composite tunnel 
bit”, but later mention the “Composite flag”.  I’m assuming it is the same 
thing – please be consistent!

M7.3. “invalid tunnel type”  RFC6514 talks about an “undefined tunnel type”.  
Do you mean the same thing?  If you do, please use the right terminology and 
put a reference to rfc6514 here to remind people where the action is defined.


M8. Section 8.1 (Considerations for PMSI Tunnel Types).

M8.1. What should the name of the bit be?  C bit, “composite tunnels” or 
“Composite tunnel bit” – all 3 versions are used, and IANA will want specific 
directions.

M8.2. “…by removing the entries for 0xFB-0xFE and 0x0F”  The range between 
0x80-0xFA also needs to be changed/updated.  s/0x0F/0xFF.  It may be clearer to 
write that this document updates the range 0x80-0xFF.

M8.3. “…and replacing them by…”   Please format the table so that spacing is 
aligned (for better clarity for IANA).  Also, plea

Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09

[Ali Sajassi (sajassi)]

Hi Alvaro,

Thank you  for your thorough review and comments. I have addressed all of them. 
Please refer inline for details on each. I just posted a new rev (rev10) that 
covers all the comment resolutions addressed here.

https://www.ietf.org/id/draft-ietf-bess-evpn-etree-10.txt


From: "Alvaro Retana (aretana)" mailto:aret...@cisco.com>>
Date: Tuesday, April 4, 2017 at 2:37 PM
To: 
"draft-ietf-bess-evpn-et...@ietf.org"
 
mailto:draft-ietf-bess-evpn-et...@ietf.org>>
Cc: "bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
Thomas Morin mailto:thomas.mo...@orange.com>>
Subject: AD Review of draft-ietf-bess-evpn-etree-09
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Cisco Employee mailto:saja...@cisco.com>>, 
mailto:ssa...@cisco.com>>, 
mailto:ju1...@att.com>>, 
mailto:jdr...@juniper.net>>, 
mailto:sbout...@vmware.com>>, 
mailto:jorge.raba...@nokia.com>>
Resent-Date: Tuesday, April 4, 2017 at 2:37 PM

Dear authors:

I just finished reading this document.  In general, the document could benefit 
from an editorial pass to improve readability; I put in some suggestions below, 
but I’m sure I didn’t mention all.  I don’t think that my comments (even the 
Major ones) will be hard to resolve – most are around providing clarity and 
consistency.  I’ll wait for a revised draft before starting the IETF Last Call.

Thanks!

Alvaro.



Major:

M1. Both the Introduction and the Abstract mention that “this document 
discusses how the functional requirements for E-Tree service can be easily 
met…”  It seems to me that RFC7387 is used as the building block for this 
document.  Why is it not a Normative reference?

Because RFC7387 is informational RFC (and the framework RFC) and the idnits 
complains of a downref: Normative reference to an informational RFC

M2. There is no reference to E-Tree.  Please add a Normative one.

Added a reference for E-TREE definition in MEF.

M3. In Section 2.2 (Scenario 2: Leaf OR Root site(s) per AC): “…then a single 
RT per EVI MAY be used…”  I think that “MAY” is out of place because it seems 
to be expressing just a fact.  Also, please keep the normative language where 
the operation is defined (in this case in 3.1).

Changed “MAY” to “can”.

M4. Section 3.1 (Known Unicast Traffic) talks about how in the “multi-homing 
scenario of section 2.2…the PE MAY advertise leaf indication along with the 
Ethernet A-D per EVI route”.  Given that the text later says that “in case of 
discrepancy, the multi-homing for that pair of PEs is assumed to be in default 
"root" mode”, I find the “MAY” not sufficient.  If we want to prevent as many 
discrepancies as possible, shouldn’t that be a “SHOULD” (or even a “MUST”)?   
Given the local configuration, why would the PE not want to include the leaf 
indication…ever…?

It is cleaned up.

M5. In Section 5.1 (E-TREE Extended Community) there is redundant information 
(first and last paragraphs).  Among that redundant information there is no 
consistency: “the Leaf Label field is set to a valid MPLS label” and “the Leaf 
Label MUST be set to a valid MPLS label” – please be consistent and specify 
things just once.

Removed the replicated/redundant text

M5.1. BTW, that is a “valid MPLS label”?  How would a receiver recognize it?  
Please add a reference to avoid confusion.

Added a brief description of “valid MPLS label” and provided the reference


M6. Definition of the E-TREE Extended Community

M6.1. Only one Flag is defined.  What about the others?  Please set up a 
registry.

If needed in the future, we will setup a registry.

M6.2. [Minor] Please put a Figure number and heading for the community format.

Done.

M6.3. It looks like the Reserved fields are set to 0.  What should happen if 
the receiver gets something else?

Added a sentence that “the receiver should ignore the reserved bits”

M6.4. “…the Leaf-Indication flag MUST be set to one and Leaf Label is set to 
zero. The received PE should ignore Leaf Label and only processes 
Leaf-Indication flag.”  What if the Leaf Label is not set to zero?  The second 
sentence says to ignore it, but the first one that it “MUST be…set to zero”.  
Which one is it?  Maybe both…  Be specific!

For MPLS label, changed it to “the transmitter SHOULD set it to zero and the 
receiver SHOULD ignore it”.

M6.5. “…the Leaf Label MUST be set to a valid MPLS label and the 
Leaf-Indication flag should be set to zero. The received PE should ignore the 
Leaf-Indication flag.”  Similar question for the Leaf-Indication bit.

For Leaf-Inication flag, change it to "the transmitter SHOULD set it to zero 
and the receiver SHOULD ignore it"

M6.6. “A non-valid MPLS label when sent along with the Ethernet A-D per ES 
route, should be logged as an error.”  I’m assuming that not only the logging 
is needed, but is the route ignored/discarded too?

Added “the route should be ignored"

M7. The

Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09

[Alvaro Retana (aretana)]

On 5/9/17, 8:51 PM, "Ali Sajassi (sajassi)" 
mailto:saja...@cisco.com>> wrote:

Ali:

Hi!

We’re on the right path, but not there yet.  Please see my comments inline 
below.

Thanks!

Alvaro.


…
> > M1. Both the Introduction and the Abstract mention that “this document 
> > discusses
> > how the functional requirements for E-Tree service can be easily met…”  It 
> > seems to
> > me that RFC7387 is used as the building block for this document.  Why is it 
> > not a
> > Normative reference?
>
> Because RFC7387 is informational RFC (and the framework RFC) and the idnits
> complains of a downref: Normative reference to an informational RFC

The status of an RFC is not an indicator of how it should be referenced – 
complaints from idnits is not an excuse.  IOW, there is nothing that prevents 
an Informational document to be referenced as Normative – we just need to take 
care of the process: not a big deal, but important.

Let me rephrase.  Is rfc7387 a document that “that must be read to understand 
or implement” [1] what is specified in this document?  Because of how rfc7387 
is positioned in the Abstract/Introduction, it seems to me that the framework 
must be read to then understand how this document addresses it:


“ A solution

   framework for supporting this service in MPLS networks is proposed in

   RFC7387 ("A Framework for Ethernet Tree 
(E-Tree) Service over a

   Multiprotocol Label Switching (MPLS) Network"). This document

   discusses how those functional requirements can be easily met with

   Ethernet VPN (EVPN) and how EVPN offers a more efficient

   implementation of these functions.”

[1] https://www.ietf.org/iesg/statement/normative-informative.html


> > M2. There is no reference to E-Tree.  Please add a Normative one.
>
> Added a reference for E-TREE definition in MEF.

This reference needs to be Normative – see above.


…
> > M6. Definition of the E-TREE Extended Community
> >
> > M6.1. Only one Flag is defined.  What about the others?  Please set up a 
> > registry.
>
> If needed in the future, we will setup a registry.

Please set it up now.

…
> > M7.1. It is not clear to me how the C bit is to be used.  Section 5.2 says 
> > that “the high-
> > order bit of the tunnel type field (C bit - Composite tunnel bit) is set 
> > while the
> > remaining low-order seven bits indicate the tunnel type as before.”   But 
> > 3.3.1 says
> > that the “new composite tunnel type is advertised by the root PE to 
> > simultaneously
> > indicate a P2MP tunnel in transmit direction and an ingress-replication 
> > tunnel in the
> > receive direction…”.  Knowing, from 5.2 that when the C bit is set “Tunnel
> > Types…0x06 'Ingress Replication' is invalid”, then does the C bit have a 
> > set meaning
> > or ???   [BTW, s/is/are]
>
> The description in section 3.3.1 is consistent with this section 5.2. 
> Basically, Composite
> Tunnel type, as its name implies consist of two tunnels: a P2MP tunnel in the 
> transmit
> direction and a MP2P tunnel in the receive direction. The MP2P tunnel in the 
> receive
> direction is used by Leaf PE devices for their BUM traffic transmission. The 
> "ingress
> replication tunnel type” is not valid because for that we don’t need 
> composite tunnel
> type!!
> I added the following sentence to the 1st paragraph to clarify it  more:
> "Composite tunnel type is advertised by the root PE to simultaneously 
> indicate a P2MP
> tunnel in transmit direction and an ingress-replication tunnel in the receive 
> direction
> for the BUM traffic."

Let me see if I understand what you’re saying:

If the C-bit is set, then the receive direction always has an IR tunnel.  The 
type of the P2MP tunnel is defined by one of the other bits.  Is that right?

If so, are all the other bits valid (always)?  The text already says that 
0x00/0x06 are invalid, but, for example, what about 0x07 (mLDP MP2MP LSP) or 
0x0A (Assisted-Replication Tunnel [draft-ietf-bess-evpn-optimized-ir])?

How can you be sure that any other type besides 0x00/0x06 will be ok?



…
> > M8.4. What is 0x7F reserved for?  It doesn’t seem to be used in this 
> > document.  Why
> > a different registration procedure?
>
> 0x7F just replaces 0x0F - i.e.  No new registration procedure

0x0F is currently Unassigned, not Reserved.


…
> > P17. The 'Updates: ' line in the draft header should list only the 
> > _numbers_ of the
> > RFCs which will be updated by this document (if approved); it should not 
> > include the
> > word 'RFC' in the list.
>
> Done. Also added 6514 to the list.

Hmm...  I don’t see how this document Updates rfc6514….??

But if it does, you need to include some text about it in both the Abstract and 
the Introduction.  BTW, please add something about the Update to rfc7385 in the 
Introduction.


> > P18. There is no reference to rfc5226.
>
> Done.

This one must be Normative.
___
BESS m

Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09

[Ali Sajassi (sajassi)]

Hi Alvaro,

Please see my comment resolutions inline. I have updated and posted a new rev:

https://www.ietf.org/id/draft-ietf-bess-evpn-etree-11.txt


From: "Alvaro Retana (aretana)" mailto:aret...@cisco.com>>
Date: Friday, May 12, 2017 at 12:18 PM
To: Cisco Employee mailto:saja...@cisco.com>>, 
"draft-ietf-bess-evpn-et...@ietf.org"
 
mailto:draft-ietf-bess-evpn-et...@ietf.org>>
Cc: "bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
Thomas Morin mailto:thomas.mo...@orange.com>>
Subject: Re: AD Review of draft-ietf-bess-evpn-etree-09

On 5/9/17, 8:51 PM, "Ali Sajassi (sajassi)" 
mailto:saja...@cisco.com>> wrote:

Ali:

Hi!

We’re on the right path, but not there yet.  Please see my comments inline 
below.

Thanks!

Alvaro.


…
> > M1. Both the Introduction and the Abstract mention that “this document 
> > discusses
> > how the functional requirements for E-Tree service can be easily met…”  It 
> > seems to
> > me that RFC7387 is used as the building block for this document.  Why is it 
> > not a
> > Normative reference?
>
> Because RFC7387 is informational RFC (and the framework RFC) and the idnits
> complains of a downref: Normative reference to an informational RFC

The status of an RFC is not an indicator of how it should be referenced – 
complaints from idnits is not an excuse.  IOW, there is nothing that prevents 
an Informational document to be referenced as Normative – we just need to take 
care of the process: not a big deal, but important.

Let me rephrase.  Is rfc7387 a document that “that must be read to understand 
or implement” [1] what is specified in this document?  Because of how rfc7387 
is positioned in the Abstract/Introduction, it seems to me that the framework 
must be read to then understand how this document addresses it:


“ A solution

   framework for supporting this service in MPLS networks is proposed in

   RFC7387 ("A Framework for Ethernet Tree 
(E-Tree) Service over a

   Multiprotocol Label Switching (MPLS) Network"). This document

   discusses how those functional requirements can be easily met with

   Ethernet VPN (EVPN) and how EVPN offers a more efficient

   implementation of these functions.”

[1] https://www.ietf.org/iesg/statement/normative-informative.html

It is a bit subjective in this case but to be safe and assuming the readers 
don’t have any background in E-TREE (which has been around for a long time – 
e.g., private VLAN), I have moved it to the normative section.

> > M2. There is no reference to E-Tree.  Please add a Normative one.
>
> Added a reference for E-TREE definition in MEF.

This reference needs to be Normative – see above.

Done.

…
> > M6. Definition of the E-TREE Extended Community
> >
> > M6.1. Only one Flag is defined.  What about the others?  Please set up a 
> > registry.
>
> If needed in the future, we will setup a registry.

Please set it up now.

OK, I will set it up.

…
> > M7.1. It is not clear to me how the C bit is to be used.  Section 5.2 says 
> > that “the high-
> > order bit of the tunnel type field (C bit - Composite tunnel bit) is set 
> > while the
> > remaining low-order seven bits indicate the tunnel type as before.”   But 
> > 3.3.1 says
> > that the “new composite tunnel type is advertised by the root PE to 
> > simultaneously
> > indicate a P2MP tunnel in transmit direction and an ingress-replication 
> > tunnel in the
> > receive direction…”.  Knowing, from 5.2 that when the C bit is set “Tunnel
> > Types…0x06 'Ingress Replication' is invalid”, then does the C bit have a 
> > set meaning
> > or ???   [BTW, s/is/are]
>
> The description in section 3.3.1 is consistent with this section 5.2. 
> Basically, Composite
> Tunnel type, as its name implies consist of two tunnels: a P2MP tunnel in the 
> transmit
> direction and a MP2P tunnel in the receive direction. The MP2P tunnel in the 
> receive
> direction is used by Leaf PE devices for their BUM traffic transmission. The 
> "ingress
> replication tunnel type” is not valid because for that we don’t need 
> composite tunnel
> type!!
> I added the following sentence to the 1st paragraph to clarify it  more:
> "Composite tunnel type is advertised by the root PE to simultaneously 
> indicate a P2MP
> tunnel in transmit direction and an ingress-replication tunnel in the receive 
> direction
> for the BUM traffic."

Let me see if I understand what you’re saying:

If the C-bit is set, then the receive direction always has an IR tunnel.  The 
type of the P2MP tunnel is defined by one of the other bits.  Is that right?

That’s correct. The remaining 7 bits indicate the type of tunnel.

If so, are all the other bits valid (always)?  The text already says that 
0x00/0x06 are invalid, but, for example, what about 0x07 (mLDP MP2MP LSP) or 
0x0A (Assisted-Replication 

Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09

[Ali Sajassi (sajassi)]

Hi Alvaro,

I am still waiting for your feedback. Is there any additional 
questions/comments that I need to address.

BTW, besides this draft, we are also waiting for your feedback on even-overlay 
draft.

Regards,
Ali

From: Cisco Employee mailto:saja...@cisco.com>>
Date: Friday, May 12, 2017 at 4:15 PM
To: "Alvaro Retana (aretana)" mailto:aret...@cisco.com>>, 
"draft-ietf-bess-evpn-et...@ietf.org"
 
mailto:draft-ietf-bess-evpn-et...@ietf.org>>
Cc: "bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
Thomas Morin mailto:thomas.mo...@orange.com>>
Subject: Re: AD Review of draft-ietf-bess-evpn-etree-09
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Cisco Employee mailto:saja...@cisco.com>>, 
mailto:ssa...@cisco.com>>, 
mailto:ju1...@att.com>>, 
mailto:jdr...@juniper.net>>, 
mailto:sbout...@vmware.com>>, 
mailto:jorge.raba...@nokia.com>>
Resent-Date: Friday, May 12, 2017 at 4:19 PM


Hi Alvaro,

Please see my comment resolutions inline. I have updated and posted a new rev:

https://www.ietf.org/id/draft-ietf-bess-evpn-etree-11.txt


From: "Alvaro Retana (aretana)" mailto:aret...@cisco.com>>
Date: Friday, May 12, 2017 at 12:18 PM
To: Cisco Employee mailto:saja...@cisco.com>>, 
"draft-ietf-bess-evpn-et...@ietf.org"
 
mailto:draft-ietf-bess-evpn-et...@ietf.org>>
Cc: "bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
Thomas Morin mailto:thomas.mo...@orange.com>>
Subject: Re: AD Review of draft-ietf-bess-evpn-etree-09

On 5/9/17, 8:51 PM, "Ali Sajassi (sajassi)" 
mailto:saja...@cisco.com>> wrote:

Ali:

Hi!

We’re on the right path, but not there yet.  Please see my comments inline 
below.

Thanks!

Alvaro.


…
> > M1. Both the Introduction and the Abstract mention that “this document 
> > discusses
> > how the functional requirements for E-Tree service can be easily met…”  It 
> > seems to
> > me that RFC7387 is used as the building block for this document.  Why is it 
> > not a
> > Normative reference?
>
> Because RFC7387 is informational RFC (and the framework RFC) and the idnits
> complains of a downref: Normative reference to an informational RFC

The status of an RFC is not an indicator of how it should be referenced – 
complaints from idnits is not an excuse.  IOW, there is nothing that prevents 
an Informational document to be referenced as Normative – we just need to take 
care of the process: not a big deal, but important.

Let me rephrase.  Is rfc7387 a document that “that must be read to understand 
or implement” [1] what is specified in this document?  Because of how rfc7387 
is positioned in the Abstract/Introduction, it seems to me that the framework 
must be read to then understand how this document addresses it:


“ A solution

   framework for supporting this service in MPLS networks is proposed in

   RFC7387 ("A Framework for Ethernet Tree 
(E-Tree) Service over a

   Multiprotocol Label Switching (MPLS) Network"). This document

   discusses how those functional requirements can be easily met with

   Ethernet VPN (EVPN) and how EVPN offers a more efficient

   implementation of these functions.”

[1] https://www.ietf.org/iesg/statement/normative-informative.html

It is a bit subjective in this case but to be safe and assuming the readers 
don’t have any background in E-TREE (which has been around for a long time – 
e.g., private VLAN), I have moved it to the normative section.

> > M2. There is no reference to E-Tree.  Please add a Normative one.
>
> Added a reference for E-TREE definition in MEF.

This reference needs to be Normative – see above.

Done.

…
> > M6. Definition of the E-TREE Extended Community
> >
> > M6.1. Only one Flag is defined.  What about the others?  Please set up a 
> > registry.
>
> If needed in the future, we will setup a registry.

Please set it up now.

OK, I will set it up.

…
> > M7.1. It is not clear to me how the C bit is to be used.  Section 5.2 says 
> > that “the high-
> > order bit of the tunnel type field (C bit - Composite tunnel bit) is set 
> > while the
> > remaining low-order seven bits indicate the tunnel type as before.”   But 
> > 3.3.1 says
> > that the “new composite tunnel type is advertised by the root PE to 
> > simultaneously
> > indicate a P2MP tunnel in transmit direction and an ingress-replication 
> > tunnel in the
> > receive direction…”.  Knowing, from 5.2 that when the C bit is set “Tunnel
> > Types…0x06 'Ingress Replication' is invalid”, then does the C bit have a 
> > set meaning
> > or ???   [BTW, s/is/are]
>
> The description in section 3.3.1 is consistent with this section 5.2. 
> Basically, Composite
> Tunnel type, as its name implies consist of two tunnels: a P2MP 

Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09

[Alvaro Retana (aretana)]

On 5/12/17, 7:15 PM, "Ali Sajassi (sajassi)" 
mailto:saja...@cisco.com>> wrote:

Ali:

Hi!  Sorry for the long RTT, busy days…

I have two remaining comments (below).  Once the registry is defined, then we 
can start the IESTF LC.

Thanks!

Alvaro.


…
> > > M6. Definition of the E-TREE Extended Community
> > >
> > > M6.1. Only one Flag is defined.  What about the others?  Please set up a 
> > > registry.
> >
> > If needed in the future, we will setup a registry.
>
> Please set it up now.
>
> OK, I will set it up.

Please do.


…
> > > M7.1. It is not clear to me how the C bit is to be used.  Section 5.2 
> > > says that “the high-
> > > order bit of the tunnel type field (C bit - Composite tunnel bit) is set 
> > > while the
> > > remaining low-order seven bits indicate the tunnel type as before.”   But 
> > > 3.3.1 says
> > > that the “new composite tunnel type is advertised by the root PE to 
> > > simultaneously
> > > indicate a P2MP tunnel in transmit direction and an ingress-replication 
> > > tunnel in the
> > > receive direction…”.  Knowing, from 5.2 that when the C bit is set “Tunnel
> > > Types…0x06 'Ingress Replication' is invalid”, then does the C bit have a 
> > > set meaning
> > > or ???   [BTW, s/is/are]
> >
> > The description in section 3.3.1 is consistent with this section 5.2. 
> > Basically, Composite
> > Tunnel type, as its name implies consist of two tunnels: a P2MP tunnel in 
> > the transmit
> > direction and a MP2P tunnel in the receive direction. The MP2P tunnel in 
> > the receive
> > direction is used by Leaf PE devices for their BUM traffic transmission. 
> > The "ingress
> > replication tunnel type” is not valid because for that we don’t need 
> > composite tunnel
> > type!!
> > I added the following sentence to the 1st paragraph to clarify it  more:
> > "Composite tunnel type is advertised by the root PE to simultaneously 
> > indicate a P2MP
> > tunnel in transmit direction and an ingress-replication tunnel in the 
> > receive direction
> > for the BUM traffic."
>
> Let me see if I understand what you’re saying:
>
> If the C-bit is set, then the receive direction always has an IR tunnel.
> The type of the P2MP tunnel is defined by one of the other bits.  Is that 
> right?
>
> That’s correct. The remaining 7 bits indicate the type of tunnel.
>
> If so, are all the other bits valid (always)?  The text already says that 
> 0x00/0x06 are
> invalid, but, for example, what about 0x07 (mLDP MP2MP LSP) or 0x0A 
> (Assisted-Replication
>  Tunnel [draft-ietf-bess-evpn-optimized-ir])?
>
> How can you be sure that any other type besides 0x00/0x06 will be ok?
>
> Basically composite tunnel type doesn’t make sense when ingress replication 
> (0x06)
> is used or when tunnel info is not present (0x00). Other than that, it can be 
> used with
> other tunnel types.

I was asking about 0x07 because that is a MP2MP LSP, and the text says that the 
bits “indicate a P2MP tunnel”:  P2MP, but not other types.  Maybe the solution 
is to just say “indicate a tunnel”.

You said that IR doesn’t make sense, but “optimized IR” does?  I’ll take your 
work for it…

Just double checking, no change needed (except s/P2MP//) if any other tunnel 
can be used.



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

Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09

[Ali Sajassi (sajassi)]

Hi Alvaro,

Regarding your two remaining comments, let me address them directly here:

1)  I will get a registry for them set up when there will be more than one 
flag. Currently, there is only a single flag defined and we do not anticipate 
any additional flags at this point.

2) regarding removing P2MP mention (so that it get generalized to MP2MP), I 
will do that but will add a sentence to say the other tunnel types that are 
supported by EVPN - e.g., currently P2MP are supported but in the future MP2MP 
can also be supported. So, I don't wan to exclude MP2MP. I can add his sentence 
during the RFC editing phase, is that OK?

Cheers,
Ali


From: "Alvaro Retana (aretana)" mailto:aret...@cisco.com>>
Date: Wednesday, June 7, 2017 at 5:10 AM
To: Cisco Employee mailto:saja...@cisco.com>>, 
"draft-ietf-bess-evpn-et...@ietf.org"
 
mailto:draft-ietf-bess-evpn-et...@ietf.org>>
Cc: "bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
Thomas Morin mailto:thomas.mo...@orange.com>>
Subject: Re: AD Review of draft-ietf-bess-evpn-etree-09

On 5/12/17, 7:15 PM, "Ali Sajassi (sajassi)" 
mailto:saja...@cisco.com>> wrote:

Ali:

Hi!  Sorry for the long RTT, busy days...

I have two remaining comments (below).  Once the registry is defined, then we 
can start the IESTF LC.

Thanks!

Alvaro.


...
> > > M6. Definition of the E-TREE Extended Community
> > >
> > > M6.1. Only one Flag is defined.  What about the others?  Please set up a 
> > > registry.
> >
> > If needed in the future, we will setup a registry.
>
> Please set it up now.
>
> OK, I will set it up.

Please do.


...
> > > M7.1. It is not clear to me how the C bit is to be used.  Section 5.2 
> > > says that "the high-
> > > order bit of the tunnel type field (C bit - Composite tunnel bit) is set 
> > > while the
> > > remaining low-order seven bits indicate the tunnel type as before."   But 
> > > 3.3.1 says
> > > that the "new composite tunnel type is advertised by the root PE to 
> > > simultaneously
> > > indicate a P2MP tunnel in transmit direction and an ingress-replication 
> > > tunnel in the
> > > receive direction...".  Knowing, from 5.2 that when the C bit is set 
> > > "Tunnel
> > > Types...0x06 'Ingress Replication' is invalid", then does the C bit have 
> > > a set meaning
> > > or ???   [BTW, s/is/are]
> >
> > The description in section 3.3.1 is consistent with this section 5.2. 
> > Basically, Composite
> > Tunnel type, as its name implies consist of two tunnels: a P2MP tunnel in 
> > the transmit
> > direction and a MP2P tunnel in the receive direction. The MP2P tunnel in 
> > the receive
> > direction is used by Leaf PE devices for their BUM traffic transmission. 
> > The "ingress
> > replication tunnel type" is not valid because for that we don't need 
> > composite tunnel
> > type!!
> > I added the following sentence to the 1st paragraph to clarify it  more:
> > "Composite tunnel type is advertised by the root PE to simultaneously 
> > indicate a P2MP
> > tunnel in transmit direction and an ingress-replication tunnel in the 
> > receive direction
> > for the BUM traffic."
>
> Let me see if I understand what you're saying:
>
> If the C-bit is set, then the receive direction always has an IR tunnel.
> The type of the P2MP tunnel is defined by one of the other bits.  Is that 
> right?
>
> That's correct. The remaining 7 bits indicate the type of tunnel.
>
> If so, are all the other bits valid (always)?  The text already says that 
> 0x00/0x06 are
> invalid, but, for example, what about 0x07 (mLDP MP2MP LSP) or 0x0A 
> (Assisted-Replication
>  Tunnel [draft-ietf-bess-evpn-optimized-ir])?
>
> How can you be sure that any other type besides 0x00/0x06 will be ok?
>
> Basically composite tunnel type doesn't make sense when ingress replication 
> (0x06)
> is used or when tunnel info is not present (0x00). Other than that, it can be 
> used with
> other tunnel types.

I was asking about 0x07 because that is a MP2MP LSP, and the text says that the 
bits "indicate a P2MP tunnel":  P2MP, but not other types.  Maybe the solution 
is to just say "indicate a tunnel".

You said that IR doesn't make sense, but "optimized IR" does?  I'll take your 
work for it...

Just double checking, no change needed (except s/P2MP//) if any other tunnel 
can be used.



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

Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09

[Alvaro Retana (aretana)]

On 6/7/17, 3:16 PM, "Ali Sajassi (sajassi)" 
mailto:saja...@cisco.com>> wrote:

Ali:

Hi!

> 1)  I will get a registry for them set up when there will be more than one 
> flag. Currently, there is only a
> single flag defined and we do not anticipate any additional flags at this 
> point.

To be clear: without the registry defined the specification is incomplete.  If 
possible, consider the case where someone else (not one of the authors) wants 
to use one of the flags, what should be the policy for them to define it?  
Should it be first come first served, or would the WG prefer a Designated 
Expert to review the potential assignment, is it ok for an experimental draft 
to request assignment, or is a Standards Track document the only way?

We’ve probably already written more text than the actual policy definition 
would take… 


> 2) regarding removing P2MP mention (so that it get generalized to MP2MP), I 
> will do that but will
> add a sentence to say the other tunnel types that are supported by EVPN – 
> e.g., currently P2MP are
> supported but in the future MP2MP can also be supported. So, I don’t wan to 
> exclude MP2MP. I can
> add his sentence during the RFC editing phase, is that OK?

That is ok with me.

Alvaro.


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

Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09

[Ali Sajassi (sajassi)]

Hi Alvaro,

I captured the IANA registry request for E-Tree flags in the latest rev of the 
draft (along with other comment resolutions):

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

This was your last AI to be completed.

Cheers,
Ali



From: "Alvaro Retana (aretana)" mailto:aret...@cisco.com>>
Date: Wednesday, June 7, 2017 at 3:26 PM
To: Cisco Employee mailto:saja...@cisco.com>>, 
"draft-ietf-bess-evpn-et...@ietf.org"
 
mailto:draft-ietf-bess-evpn-et...@ietf.org>>
Cc: "bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
Thomas Morin mailto:thomas.mo...@orange.com>>
Subject: Re: AD Review of draft-ietf-bess-evpn-etree-09

On 6/7/17, 3:16 PM, "Ali Sajassi (sajassi)" 
mailto:saja...@cisco.com>> wrote:

Ali:

Hi!

> 1)  I will get a registry for them set up when there will be more than one 
> flag. Currently, there is only a
> single flag defined and we do not anticipate any additional flags at this 
> point.

To be clear: without the registry defined the specification is incomplete.  If 
possible, consider the case where someone else (not one of the authors) wants 
to use one of the flags, what should be the policy for them to define it?  
Should it be first come first served, or would the WG prefer a Designated 
Expert to review the potential assignment, is it ok for an experimental draft 
to request assignment, or is a Standards Track document the only way?

We've probably already written more text than the actual policy definition 
would take... 


> 2) regarding removing P2MP mention (so that it get generalized to MP2MP), I 
> will do that but will
> add a sentence to say the other tunnel types that are supported by EVPN - 
> e.g., currently P2MP are
> supported but in the future MP2MP can also be supported. So, I don't wan to 
> exclude MP2MP. I can
> add his sentence during the RFC editing phase, is that OK?

That is ok with me.

Alvaro.


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