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

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

Hi Jorge,

Since we are using ³SHOULD² in the next section (8.3), I will change the
sentence to the following to make it consistent:

"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 SHOULD be set to a valid MPLS label value.²

Cheers,
Ali



On 8/2/14, 2:49 AM, "Rabadan, Jorge (Jorge)"
<[e-mail]> wrote:

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