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

["Rabadan, Jorge (Jorge)" <[e-mail]>]

Ali,

I just realized something:

Page 19:
"If Single-Active redundancy mode is desired, then the "Single-Active” bit
in the flags of the ESI Label Extended Community MUST be set to 1 and the
ESI label MUST be set to zero."

later in the same page:
“...The ESI label SHOULD be distributed by all PEs when operating in
Single-Active redundancy mode using a set of Ethernet A-D per ES route."


If the single-active PEs SHOULD distribute the ESI label, the “ESI label
MUST be set to zero” statement sounds wrong. Can you please change it to
“MAY” if you agree?

Thank you.
Jorge


-----Original Message-----
From: "Ali Sajassi   (sajassi)" <[e-mail]>
Date: Sunday, July 20, 2014 at 9:55 PM
To: "[e-mail]" <[e-mail]>,
"[e-mail]"
<[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "Ali Sajassi (sajassi)"
<[e-mail]>
Subject: Re: AD review of draft-ietf-l2vpn-evpn

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