Re: [mpls] MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

["Dutta, Pranjal K (Pranjal)" <[e-mail]>]

Hi Lizhong,
                  Thanks for review. Please refer my answers inline.

Cheers,
Pranjal
________________________________
From: Lizhong Jin [mailto:[e-mail]]
Sent: Monday, July 23, 2012 2:13 AM
To: Dutta, Pranjal K (Pranjal); [e-mail]; Thomas Nadeau; Giles Heron
Cc: [e-mail]; VIGOUREUX, MARTIN (MARTIN); Markus Jork; Ross Callon; [e-mail]; [e-mail]
Subject: Re: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03


Hi all,
I've reviewed this draft, and have two comments that need to be clarifed:
1. Target Hello tracks the liveness of hello adjacency, while LDP keepalive tracks the liveness of session. Do you mean it is not necessary to track the liveness of hello adjacency, or substitute it with liveness tracking of session? Hello address maybe different with trasport address.

[Pranjal]  It depends on case by case. For example when transport address of the LDP session is different from the IP addresses used to exchange t-ldp hellos, then probably it is not RECOMMENDED to use hello reduction procedures, since sessions keepallives are not really substitute of "reachability" or "liveliness" of the adjacency. Alternately it is possible to track the reachability of t-ldp sources by means of other fast protocols (e.g BFD and others etc).
In such a case, the t-ldp hellos could be redundant after initial discovery done and session set-up is complete. When peers are asymmetric w.r.t hello reduction support (one peer supports while the other does not), then the situation falls back to what we have with RFC 5036.


2. Target hellos are not only used for liveness track, but also parameter negotiation and updating. When negotiated to infinite, what time interval would be used to send the updated hello (e.g, hello with new Optional Parameters in potential draft-pdutta-mpls-ldp-adj-capability) message? UDP hello is not reliable, would be renegotiated to configured hello hold time first?

[Pranjal] An updated hello can be sent at any time (whenever any param is changed to reflect the change to peer) without any changes in "current"
hold time (e.g infinite) that was advertised in the last hello message. Means it is not necessary to fallback to configured hold time and restart the reduction process (in fact not desirable). For example, it could be changes in one or more hello adjacency capabilities as described in the aforementioned draft or could be any of the existing standard params such as configSeqNum etc. Since hellos are not reliable, after any parameter change an implementation
may send a set of hellos (let's say 5) at configured intervals (or faster) to reflect the change. But those hellos would continue to advertise infinite hold time
and would fall back to reduced rate after those 5 packets are sent.

However, changes like IPV4 or IPV6 transport address etc may restart the session that can result in starting hello reduction from scratch.

I agree that in its current state draft doesn't describe the solution and its flexibilities in adequate detail. We would definitely address those.


Summary of review:
a. whether the document is coherent?
Good description on the motivation, need more detail in technical description (e.g, refer to my second comment).

b. is it useful?
Yes.

d. is technically sound ?
Need some clarification.

e. is ready to be considered for WG adoption ?
After clarification, it should be ready for WG adoption.

Regards
Lizhong


Ross Callon <[e-mail]> wrote 2012/07/18 05:49:55:

> Markus, Lizhong, Thomas;
>
> You have been selected as an MPLS Review team reviewers for
> draft-pdutta-mpls-tldp-hello-reduce-03
>
> 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 secretary,
> and CC'd to the MPLS WG email list. If necessary, comments may be sent
> privately to only the WG chairs.
>
> Are you able to review this draft by August 3, 2012 (ie, the end of the IETF
> meeting in Vancouver)? We understand that this is somewhat short notice and
> that you might have something else to do the week of the IETF, so let us
> know if you need slightly more time.
>
> Thanks, Ross
> (as MPLS WG chair)
>
> PS: I noticed that Tom Nadeau's email address listed in the draft is
> out of date. This email is being CC'd to his updated address.
>