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

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

Hi Ali,

Sounds good.
Thank you for fixing it.

Jorge

-----Original Message-----
From: "Ali Sajassi   (sajassi)" <[e-mail]>
Date: Monday, September 8, 2014 at 10:53 AM
To: Jorge Rabadan <[e-mail]>,
"[e-mail]" <[e-mail]>,
"[e-mail]"
<[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: AD review of draft-ietf-l2vpn-evpn

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