Re: [PWE3] AD comments on draft-ietf-pwe3-dynamic-ms-pw

["Bocci, Matthew (Matthew)" <[e-mail]>]

Stewart

Thanks for your comments. Please see below.

Matthew

On 30/10/2013 14:19, "Stewart Bryant" <[e-mail]> wrote:

>I am about to put this into IETF LC.
>
>Please consider the following as LC comments.
>
>- Stewart
>
>Network Working Group                                 Luca Martini (Ed.)
>Internet Draft                                        Cisco Systems Inc.
>Expires: April 2014
>Intended status: Standards Track                     Matthew Bocci (Ed.)
>Updates: 6073                                         Florin Balus (Ed.)
>                                                           Alcatel-Lucent
>
>                                                          October 8, 2013
>
>
>              Dynamic Placement of Multi-Segment Pseudowires
>
>
>                   draft-ietf-pwe3-dynamic-ms-pw-19.txt
>
>SB> it updates the length value of the PW Switching Point PE Sub-TLV Type
>0x06 to 14.
>SB> It is confusing to talk about the "length value" of a TLV. I think you
>SB> mean "length"

MB> It should probably say "the value of the length field", since this
value was incorrectly specified in RFC6073.


>
>
>
>
>
>2.1. Changes to Existing PW Signaling
>
>
>    This document also updates the length value of the PW Switching Point
>    PE Sub-TLV Type 0x06 to 14.
>
>SB> Same comment as above
>
>
>
>4.2. LDP Signaling
>
>
>    The complete definitions of the content of the SENDER_TSPEC objects
>    are found in [TSPEC] section 3.1.
>
>SB> TSPEC is actually RFC2210 isn't it?
>SB> If so that would be a much better reference identifier


MB> agreed

>
>
>
>4.2.1. Equal Cost Multi Path (ECMP) in PW Routing
>
>    A next hop selection for a specific PW may find a match with a PW
>    route that has multiple next hops associated with it. Multiple next
>    hops may be either configured explicitly as static routes or may be
>    learned through BGP routing procedures. Implementations at and S-PE
>SB> s/and/an/
>
>    or T-PE MAY use selection algorithms, such as CRC32 on the FEC TLV,
>    for load balancing of PWs across multiple next-hops. The details of
>    such selection algorithms are outside the scope of this document.
>
>SB> Presumable FAT is another option?

MB> Yes. Fat PW didn¹t exist when this was written. I¹ll rephrase to
³Š,for example CRC32 on the FEC TLV, or Flow Aware Transport PW [RFC6391]Š²

>
>  4.2.2. Active/Passive T-PE Election Procedure
>
>
>    The determination of which T-PE assumes the active role SHOULD be
>    done as follows: the Source Attachment Individual Identifier (SAII)
>    and TAII are compared as unsigned integers, if the SAII is bigger
>    then the T-PE assumes the active role.
>
>SB> This does not look quite precise enough. You need to specify which
>bytes
>SB> and the bit order. What you say is technically correct
>SB> but isn't it clearer to say that the T-PE with the larger
>SB> SAII is active?

MB> Yes. I¹ll rephrase. I¹ll also need to confirm the bit ordering.

>SB> I do not see (pointer to) a definition of SAII or TAII in this draft

MB> It should be RFC6074, with the AII format for the SAII and TAII as per
Section 3.1 of this draft. I¹ll add text to clarify.
>
>
>
>6. Operations and Maintenance (OAM)
>
>    In this case, the following TLV type (0x06) MUST be used
>    in place of type 0x01 in the PW switching point TLV:
>
>SB> This is "PW Switching Point PE sub-TLV" in RFC6073

MB> Yes. I¹ll correct.

>SB>
>
>SB> Are there any interoperability issues with the change of length to
>SB> 14, i.e. is there any length 12 code in the wild?

MB> If you implement 6073 with a length field of 12, then the RFC6073
implementation would have problems, not just in the context of this draft,
but in general. I believe that known implementations of 6073 that work
correctly use a value of 14 for SP-PE TLV today.



>
>
>
>
>
>
>
>
>
>
>
>
>
>