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

["Alvaro Retana (aretana)" <[e-mail]>]

On 5/9/17, 8:51 PM, "Ali Sajassi (sajassi)" <[e-mail]<mailto:[e-mail]>> 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


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