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

[Lizhong Jin<[e-mail]>]

Hi Pranjal,
Thanks for the prompt response. See inline below.

Regards
Lizhong
 

"Dutta, Pranjal K (Pranjal)" <[e-mail]> wrote 
2012/07/24 10:37:54:

> 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.
[Lizhong] My concern is tracking of T-LDP hello source address by BFD or 
LDP session (on condition that transport address is same as hello address) 
could not substitue the liveness of the UDP connection of hello adjacency. 
For example, when LDP session is setup, and hello adjacency has negotiated 
to infinite time, althought the hello address is IP reachable, but if UDP 
port '646' is incorrectly closed or some other UDP problem accured, the 
hello adjacency in fact is down, but you could not detect this with 
infinite hold time. Then I mean hello reduction should be used with 
caution that the UDP will not accure any potential problem. Maybe I missed 
something.

> 
> 
> 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. 
[Lizhong] It is clear now, thank you.

> 
> 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.
[Lizhong] Thank you.

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