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

From: Lucy yong <[email-masked]>
Date: Tue, 14 Jul 2015 14:45:07 +0000

Hi All,

I reviewed draft-kompella-mpls-larp as the member of MPLS Review Team and have the following comments:

is the document coherent?

Yes. It specifies LARP protocol to advertise label binding for IP host address, which extends MPLS to Hosts. Definitely MPLS related.

is it useful (i.e., is it likely to be actually useful in operational networks)?

Technically speaking, this protocol can be implemented. I am not a (DC) operator so not sure if the operator wants to deploy this protocol in DC or between access nodes and first hop MPLS-enabled device. The protocol may help automation at mpls edge. One question: beside label binding to host address, what other MPLS benefits will hosts gain compared to current architecture? For example, if MPLS OAM features can be extended to hosts, i.e. end-to-end?

is the document technically sound? 
Yes, LARP is used between host and MPLS network to convey label binding to IP host address. The draft provides a solution in control plane and data plane to achieve this purpose.

is the document ready to be considered for WG adoption?
Not yet.  IMO: LARP protocol should work in a practical environment where hosts and an MPLS device are connected via an intermediate bridge (IEEE.1Q). Current draft only considers the case that host directly connects to MPLS device. In addition, it is necessary to address some items listed in section 4 ahead, which helps validate the feasibility in operational environment. For examples, 1) client and service in sync; 4) if there are many servers, which one to pick? 

Regards,
Lucy

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Tuesday, June 30, 2015 12:18 PM
> To: Lucy yong; Kamran Raza (skraza); Sriganesh Kini; Aissaoui, 
> Mustapha (Mustapha); [email-masked]; 
> [email-masked]
> 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: [email-masked]
> Senior MPLS Expert                          [email-masked]
> Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Wed, 15 Jul 2015 17:27:07 +0000

Dear all,
I reviewed this draft and I have compiled a list of comments below.

The proposed mechanism while not as robust as a label signaling protocol, it has the advantage of being simple and can be used in networks where the requesting node (ARP client) is one IP hop away from the responding node (ARP server). 

The document is coherent except for Section 4 as the authors seem to suggest that the listed issues may not be addressed in the initial version of this document when it turns into an RFC. I hope this is not the case as some of those issues are fundamental for anyone wanting to implement this and for interoperability.

There a few more details which need to be incorporated to clarify the behavior as per the comments below. I believe the document will be ready for working group status once these comments are addressed.  

Regards,
Mustapha.
--------------------
I. Section 3.1
1. The following sentence is not entirely accurate. The ARP server must issue an update of the binding via an unsolicited L-ARP message for changes impacting the reachability of destination prefix as explained in Section 3.2: 
"
Once an L-ARP server has advertised a label binding, it MUST NOT change the binding until expiry of the binding's validity time.
"

2. It is not clear from the description of the behavior if the server must have a MPLS tunnel to reach the destination prefix (the tunnel does not need to terminate on the destination prefix) before it can issue a label stack in L-ARP replies to clients or if IP reachability is sufficient. I believe this is an important point and maybe both modes of operations are allowed. It just needs to be clarified.

3. There is no description of what T3 does what it receives a packet destined to H3. Does it generate a L-ARP request to learn the label to reach H3?

4. There is no description about what happens if the destination prefix is in the local subnet. Assume H3 is in the same subnet as H1. Will H3 reply with a label?

II. Section 3.2
1. The authors propose that the support of the unsolicited L-ARP is optional. While this is true for gratuitous ARP in many existing implementations,  the classic ARP is about passing only the hardware address for a target prefix as long as the ARP server owns the prefix or has reachability to the prefix. The hardware address does not change when the resolution of a prefix changes at a server as long as the prefix is still reachable. 
With the L-ARP, there is the fact that the assigned labels as well as the attributes can change when reachability changes and these need to be communicated to the client. I cannot see how the unsolicited L-ARP mechanism can be made optional in this case.

2. The authors should clarify what is meant by "reachability" in the below paragraph. Is it rachability using a MPLS tunnel or just IP reachability? Also, in my view any change to the label stack TLV or attribute TLV must trigger an unsolicited L-ARP from the server for that binding.

"
As long as
   the server has at least one interested client for a prefix, the
   server sends unsolicited (aka gratuitous, though the term is less
   appropriate in this context) L-ARP replies when a prefix's
   reachability changes.

"

III. Section 3.3:
1. I am not sure I understand the intent of this section. Should not all the issues listed resolved by mandating the use of the unsolicited L-ARP mechanism from Section 3.2?

IV. Section 3.4:
1. I do not think seamless MPLS is the general case for the use of this mechanism as described in the below paragraph. The general case is anytime a node needs a MPLS label to reach remote destination prefix via a gateway node which is one-hop away from IP perspective, i.e., the node does not have reachability beyond the gateway node.

"
More generally, L-ARP can be used between
   an "access node" and its first hop MPLS-enabled device in the context
   of Seamless MPLS [reference].
" 

IV. Section 5:
1. What is the intent of including the Entropy Label Capable flag? I means this mechanism works only if the client and server one IP hop away from each other and thus there cannot be a LSR in between. Could you elaborate?

---

From: Sriganesh Kini <[email-masked]>
Date: Thu, 16 Jul 2015 01:11:26 +0000

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 [[email-masked]]
Sent: Tuesday, 30 June 2015 9:18 AM
To: Lucy yong; Kamran Raza (skraza); Sriganesh Kini; Aissaoui, Mustapha (Mustapha); [email-masked]; [email-masked]
Subject: MPLS-RT review of 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?

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