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

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 7 Jun 2017 05:18:55 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 12, 2017 at 4:15 PM
To: "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Thomas Morin <[email-masked]<mailto:[email-masked]>>
Subject: Re: AD Review of draft-ietf-bess-evpn-etree-09
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
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)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 12, 2017 at 12:18 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Thomas Morin <[email-masked]<mailto:[email-masked]>>
Subject: Re: AD Review of draft-ietf-bess-evpn-etree-09

On 5/9/17, 8:51 PM, "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>> 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<https://tools.ietf.org/html/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 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.

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

I meant to say 0xFF. Basically the existing experimental types 0xFB – 0xFE and reserved type of 0xFF has moved to new code points of: 0x7B – 0x7E and 0x7F.

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

On the 2nd thought, it doesn’t updated it because the whole purpose of C-bit is backward compatibility. So no updates to rfc6514. I removed it from the text.

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.

Added a sentence to the introduction in last paragraph.

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

This one must be Normative.

Done.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 7 Jun 2017 12:10:06 +0000

On 5/12/17, 7:15 PM, "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>> 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.

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

Please do.

…
> 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])?
>
> 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.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 7 Jun 2017 19:16:09 +0000

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

Date: Wednesday, June 7, 2017 at 5:10 AM

Ali:

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

Thanks!

Alvaro.

...

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-
> > > 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
> > > 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]
> >
> > replication tunnel type" is not valid because for that we don't need composite tunnel
> > type!!
> Let me see if I understand what you're saying:
>
> That's correct. The remaining 7 bits indicate the type of tunnel.
>
> Basically composite tunnel type doesn't make sense when ingress replication (0x06)

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

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 7 Jun 2017 22:26:20 +0000

On 6/7/17, 3:16 PM, "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>> 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… <sigh>

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

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 23 Jun 2017 00:02:41 +0000

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

Date: Wednesday, June 7, 2017 at 3:26 PM

Ali:

Hi!

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

> 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

That is ok with me.

Alvaro.