Re: AD review of draft-ietf-l2vpn-evpn

["Ali Sajassi (sajassi)" <[e-mail]>]

Adrian,

Thanks very much for your review. I will incorporate your comments into
the next rev. For more details, please refer inline ...

Regards,
Ali

On 7/18/14 3:56 PM, "Adrian Farrel" <[e-mail]> wrote:

>Goodness, but there's a long and complicated document. But I think
>you have made it as clear and concise as it could possibly have been.
>Good job!
>
>I have done my AD review and found no substantive issues. I do,
>however, have a little pile of nits. Actually, quite a large heap.
>Nothing to worry about, but if you could clean them up i think it
>would improve the document still further.
>
>The only topics that need real attention are those related to IANA.
>
>Let me know how you get on, and please object if my comments are wrong.
>
>Thanks,
>Adrian
>
>===
>
>It would be best to move the Introduction to be the first section in
>the document.
>
>---
>
>Section 5
>
>   Ethernet segments have an
>   identifier, called the "Ethernet Segment Identifier" (ESI) which is
>   encoded as a ten octets integer.
>
>It would help if you said "...in line format with the most significant
>octet sent first."

Done.

>
>---
>
>Section 5
>
>   In general, an Ethernet segment MUST have a non-reserved ESI that is
>   unique network wide
>
>"In general" is not really consistent with "MUST"

Will change "MUST" to "SHOULD"

>
>---
>
>Do you want an IANA registry to track the values of the Type field of
>the ESI? 

We don't anticipate any other ESI type besides the ones mentioned here.

>                  
>
>---               
>
>There is some mixing of "octet" and "byte" in the document. This creates
>the impression that you mean something different by the two words.

Will make it consistent.

>
>---
>
>Could you expand DF on first use. You have it in 8.3.

Will do.

>
>---
>
>Section 6
>
>You use "Ethernet Tag ID", "Ethernet Tag", and "Ethernet Tag Identifier"
>interchangeably. It would be helpful to use just one term and to check
>usage in the rest of the document.

Will do.

>
>---
>
>Section 6.1
>
>   In such
>   scenarios, the Ethernet frames transported over MPLS/IP network
>   SHOULD remain tagged with the originating VID and a VID translation
>   MUST be supported in the data path and MUST be performed on the
>   disposition PE.
>
>I think you should add under what circumstances the frames MAY be re-
>tagged with a different VID (or s/SHOULD/MUST). You don't need a
>detailed explanation, but a guide to the implementer/operator.

The sentence before this says:
"If the VLAN is represented
   by different VIDs on different PEs, then each PE needs to perform VID
   translation for frames destined to its attached CEs."

I thought this description is clear enough but I will try to make it more
clear.

>
>---
>
>Do you want IANA to create a registry and track the Route Types defined
>for the EVPN NLRI in Section 7?

We'll look into it.

>
>---
>
>Section 7.1 and onwards...
>
>I know "RD" is a term of art in the context of BGP, but could you
>please expand RD it on first use rather than leaving that to 8.2.1.

Sure, we'll do.

>
>(All the forward references to later sections are good, thanks.)
>
>---
>
>A small inconsistency between sections 7 and 8. In the figures in
>Section 7 you have "MPLS Label" and "MPLS Label1" etc. In the text
>in Section 8 you have "MPLS label" etc. When you refer to the fields
>you need to match the case. When you refer to the concept of an MPLS
>label, you can (of course) use normal case.

Agreed.

>
>---
>
>Are you sure that the ESI Label extended community and subtypes don't
>need IANA intervention here?

We have registered these values with IANA. We will reflect that in IANA
section.

>
>---
>
>It would be nice if 7.5 included a hint as to what an "ESI label" is.

Agreed.

>
>---
>
>In 7.10
>
>   If a PE uses RT-Constrain, the PE SHOULD advertise all such RTs using
>   RT Constraints.
>
>Is this a general restatement of RFC 4684 (if so add "As described in
>[RFC4684]...") or new guidance for implementers of this spec (if so,
>what is the reason for SHOULD? is there a MAY to counter it?)

I'll add RFC4684 reference.

>
>---
>
>8.1.1
>
>   The Ethernet Segment Identifier MUST be set to the ten octet ESI
>   identifier described in section 5.
>
>Would that be the ESII? :-)

Nice catch :-)

>
>---
>
>8.2.1 has "MANDATORY" I guess you are inventing a 2119 term to counter-
>point "OPTIONAL". Please use "REQUIRED."

Agreed.

>
>---
>
>In Section 13.1
>
>   In certain
>   environments the source MAC address MAY be used to authenticate the
>   CE and determine that traffic from the host can be allowed into the
>   network.
>
>Want to hint which environments they would be. Possibly more important,
>want to say in which environments this would be a damn fool idea?

We'll do :-)

>
>---
>
>14.1.2
>
>   The MPLS label stack to send the packets to PE1 is the MPLS LSP stack
>   to get to PE1 and the EVPN label advertised by PE1 for CE1's MAC.
>
>and
>
>   The MPLS label stack to send packets to PE2 is the MPLS LSP stack to
>   get to PE2 and the MPLS label in the Ethernet A-D route advertised by
>   PE2 for <ES1, VLAN1>, if PE2 has not advertised MAC1 in BGP.
>
>It *should* be perfectly obvious to the implementer, but perhaps you
>should say what order the labels appear on the stack since "and" is non-
>specific.

OK.

>
>---
>
>Section 18
>
>I wish you would add a reference to 4385 and use that control word with
>the various fields set to zero. This would keep us from increasing the
>number of different control word definitions in the wild. I think that
>the impact on your spec would be zero.

We'll do.

>
>---
>
>Section 21 should be renamed "Contributors"

We'll do.

>
>---
>
>I think RFC 2119 is a normative reference.

OK.

>