Re: [mpls] MPLS-RT review of draft-kompella-mpls-larp

[Lucy yong <[e-mail]>]

Thank authors for the update. It is better/clearer.



I am fine with the WG adoption on this version but have some comments/suggestions to this version.



·         Section 3.2 should make a general case. Tx that wants an attached node to have MPLS reachability, allocates a label to reach the node and advertises the label into the MPLS Fabric or to local subnet via LARP. Upon receiving a packet with the label from the fabric or the local subnet, Tx pops the label and sends the packet to the node. Note that Tx can allocate more than one label for the node and advertise to the MPLS fabric. This is normal MPLS behavior.

·         Should clarify that Tx devices MUST be configured as a host to the local network, i.e. not a bridge device. It MUST terminate/discard a locally received packet.

·         In security section, it should mention that a packet with a label sent by a host may be delivered by the local network as an unknown packet; thus more than one T device will get the packet. If a T device that is not the destination of a packet receives the packet and accidently takes an action on the packet, this will cause a major error.

·         It is important to address the client-server sync and withdrawing process in this mechanisms

·         A host may be configured a gateway address to send packet outside the subnet. It would be nice to state out the operation at T device in this case.

·         Text: This field is valid only in an L-ARP reply message.  Does it mean LST and ATT TLVs will be presented or not presented in the request msg? Please make the word very clearly.

·         The metric is a well-known parameter for network element, but not a host. When host supporting LARP sends a response, what is the recommendation to fill the ATT TLV? The draft should specify that for the integrity.

·         Replace “client must not insert” with “client MUST NOT insert” in section 9.



Regards,

Lucy







-----Original Message-----
From: Loa Andersson [mailto:[e-mail]]
Sent: Thursday, September 10, 2015 4:36 AM
To: Kireeti Kompella; Sriganesh Kini
Cc: Lucy yong; Kamran Raza (skraza); Aissaoui, Mustapha (Mustapha); [e-mail]; [e-mail]; [e-mail]
Subject: Re: MPLS-RT review of draft-kompella-mpls-larp



Lucy, Kamran, Sri and Mustapha



Can each of you confirm to me that your MPLS-RT review comments has been satisfactorily addressed.



I will start the working group adoption poll as soon as I have your¨resonses,



/Loa



On 2015-09-08 21:25, Kireeti Kompella wrote:

> Hi All,

>

> Thanks all again for your comments.

>

> I've just posted a new version incorporating all your feedback.  There

> is new text to clarify some points, and the text on unsolicited ARP

> and Async operation have been merged.  The one thing left to do is to

> write the MPLS Fabric document -- work has started here.

>

> Kireeti.

>

> On Wed, Jul 15, 2015 at 6:11 PM, Sriganesh Kini

> <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>> wrote:

>

>     Hello,

>

>     This is the MPLS-RT review of draft-kompella-mpls-larp -

>

>     The document is coherent.

>

>     Regarding whether it is useful (i.e., is it likely to be actually

>     useful in operational networks), the yet to do be defined reference

>     [TODO-MPLS-FABRIC] would be needed before commenting on it. Also if

>     any host NIC vendors can chime in or any evidence of host operating

>     systems that plan to support this is present, it will help to answer

>     this question. I don't see any technical reason why MPLS shouldn't

>     be useful in DC networks.

>

>     The document is technically sound for most parts, but as sec 4

>     points out there are a number of issues still left. I would add a

>     couple issues -

>              1.      The restarts should address control-plane restart

>     as well. Though there is no session between server and client, the

>     action (if any) to be performed when control-plane restarts should

>     be specified.



>              2.      If a LSR (L-ARP server) goes down, then there

>     should be a proposed resiliency mechanism (e.g. using BFD).



>

>     Other comments:

>              1.      It would be very useful to list the use-cases where

>     a host wants to participate in the fabric through a simpler

>     mechanism than RSVP-TE UNI. Additionally, even though label

>     distribution itself may become simpler using ARP, doesn't the host

>     have to do other MPLS OAM functionality? Some discussion of this

>     topic is needed.



>              2.      Section 3.4 "... presence of a complex

>     topology...". Which topology is this referring to ? Is it the

>     underlying ethernet network topology ? Pls state it explicitly and

>     also why it would cause a problem to LARP.



>

>     Nits:

>              1.      Section 1, page 1 s/Centre/Center



>              2.      The node 'T' should be shown in the MPLS Fabric of

>     Fig 1.



>              3.      Missing reference [TODO-MPLS-FABRIC]



>              4.      Sec 3.4 "Seamless MPLS" reference is missing.



>

>     Since [TODO-MPLS-FABRIC] seems to the primary driver for this

>     document, it would be better to consider this for a WG document

>     after that document is published.

>

>     - Sri

>     ________________________________________

>     From: Loa Andersson [[e-mail] <mailto:[e-mail]>]

>     Sent: Tuesday, 30 June 2015 9:18 AM

>     To: Lucy yong; Kamran Raza (skraza); Sriganesh Kini; Aissaoui,

>     Mustapha (Mustapha); [e-mail]<mailto:[e-mail]>

>     <mailto:[e-mail]>;

>     [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>

>     Subject: MPLS-RT review of draft-kompella-mpls-larp

>

>     Lucy, Kamran, Sri and Mustapha;

>

>     You have be selected as MPLS-RT reviewers for draft-kompella-mpls-larp.

>

>     Note to authors: You have been CC'd on this email so that you can know

>     that this review is going on. However, please do not review your own

>     document.

>

>     Reviews should comment on whether the document is coherent, is it

>     useful (ie, is it likely to be actually useful in operational networks),

>     and is the document technically sound?

>

>     We are interested in knowing whether the document is ready to be

>     considered for WG adoption (ie, it doesn't have to be perfect at this

>     point, but should be a good start).

>

>     Reviews should be sent to the document authors, WG co-chairs and WG

>     secretary, and CC'd to the MPLS WG email list. If necessary, comments

>     may be sent privately to only the WG chairs.

>

>     If you have technical comments you should try to be explicit about what

>     needs to be resolved before adopting it as a working group document, and

>     what can wait until the document is a working group document and the

>     working group has the revision control.

>

>     Are you able to review this draft by 14, 2015? Please respond in a

>     timely fashion.

>

>     Thanks, Loa

>     (as MPLS WG chair)

>     --

>

>

>     Loa Andersson                        email: [e-mail]<mailto:[e-mail]>

>     <mailto:[e-mail]>

>     Senior MPLS Expert [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>

>     Huawei Technologies (consultant)     phone: [phone]

>     <tel:%2B46%20739%2081%2021%2064>

>

>

>

>

> --

> Kireeti