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

["Aissaoui, Mustapha (Mustapha)" <[e-mail]>]

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?

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