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

[Lizhong Jin<[e-mail]>]

Hi Pranjal,
Thank you for the clarification. I am clear now, and the draft should add 
these technical cautions, so as to let the operator be very clear before 
deploying this feature.

Regards
Lizhong
 

"Dutta, Pranjal K (Pranjal)" <[e-mail]> wrote 
2012/07/25 00:22:42:

> Hi Lizhong,
> 
> 
> [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.
> 
> Yes, you are correct. If there is a bug in S/w that closes port 646 
> accidentally and then with hello reduction it would take long time 
> to detect. But if a port 646 is closed accidently by a peer but 
> without gracefully shutting down LDP session then don’t we already 
> have a bigger problem? In that way we can contest 
> against many solutions that has a bottom line for resilience against
> bugs. This is a good point you raised and we would mention it 
> explicitly in the draft. Note
> that when LDP is deployed in large scale MPLS access, aggregation, 
> seamless MPLS etc the priority is resilience for adjacencies. There 
> are special
> techniques that an implementation can adopt (e.g H/w assisted) to 
> provide such resilience but there are cost functions associated with
> and we may not 
> be able to take uniform view of LDP in general. 
> 
> Thanks,
> Pranjal
> 
> 
> From: Lizhong Jin [mailto:[e-mail]] 
> Sent: Tuesday, July 24, 2012 1:17 AM
> To: Dutta, Pranjal K (Pranjal)
> Cc: Giles Heron; [e-mail]; VIGOUREUX, MARTIN (MARTIN); Markus Jork;
> [e-mail]; Ross Callon; [e-mail]; Thomas.
> [e-mail]; Thomas Nadeau
> Subject: RE: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03
> 
> 
> 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 
andsecretary,
> > > 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. 
> > >