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

[Markus Jork <[e-mail]>]

I have reviewed draft-pdutta-mpls-tldp-hello-reduce-03 and have some concerns and suggestions.	

I believe the draft would benefit from a more rigorous definition and examination of its proposed procedures. RFC 5036 has the basic assumption that an LDP session with a peer has at least one or more hello adjacencies. It is not entirely clear to me whether the draft proposes to maintain this rule or to change it by no longer requiring the existence of a hello adjacency to maintain the LDP session.

Most sections of the draft seem to imply that the hello adjacency continues to exist once the infinite hold time has been agreed upon. That is suggested by statements like this:

>   After the
>   session is operational the periodic Targeted Hellos between the LSRs
>   become redundant, as session Keepalives in turn serves the intent of
>   each LSR to maintain its adjacency to its peer.

But when the hello adjacency continues to exist, that means each side can send an updated hello message at any time. That hello could request a short hold time again which is in apparent contradiction to the draft's claim that it helps mitigate DoS attacks based on spurious hellos.

I believe the draft should define the exact nature and extent of the hello adjacency:
- does it really continue to exist after the hold time is set to infinite?
- is it maintained by the fact that the LDP session still exists?
- is it maintained because the hold time is infinite and thus it actually will never cease to exist at all?
- does the loss of the LDP session trigger the deletion of the hello adjacency or does it just modify the nature of the hello adjacency?
- what is the treatment of new hello messages received after the targeted LDP hello reduction has been negotiated (i.e. the hold time is infinite)? 

Once this is done, I think various implications will become clearer and might expose problems. The hello adjacency does not just exist to enable the initial bring-up of the LDP session and to check connectivity to the peer. It also conveys other information such as configuration changes.

At this time, without further clarification of the procedures, I am concerned that the draft would cause an overall decrease in robustness of the LDP protocol.


Apart from these technical concerns, I also wonder about the need for this draft. Reducing signaling overhead to improve scaling is generally a good thing. However, sending of UDP hellos is not typically a pain point as there are well known implementation techniques to deal with that. And if reducing the hellos involves changes to the well established and proven LDP protocol machinery, then I'm kind of doubtful that it's worth it.

-Markus


_____________________________________________
From: Ross Callon 
Sent: Tuesday, July 17, 2012 2:50 PM
To: Markus Jork; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; Ross Callon; Martin Vigoureux; Dutta, Pranjal K (Pranjal); Giles Heron; Thomas Nadeau
Subject: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03


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.