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

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

Please find the responses line. Please let me know if I had answered all concerns and if further clarification needed.

Thanks,
Pranjal

-----Original Message-----
From: Markus Jork [mailto:[e-mail]] 
Sent: Friday, July 20, 2012 7:07 PM
To: Dutta, Pranjal K (Pranjal); Giles Heron; Thomas Nadeau; [e-mail]; VIGOUREUX, MARTIN (MARTIN)
Cc: [e-mail]
Subject: RE: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

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

<Pranjal> Thanks for review and your suggestions. </Pranjal>

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.

<Pranjal> This draft does not change or violate procedures defined in RFC 5036. It proposes an OPTIONAL method of reduction of "targeted' hellos (only - as the name of the draft suggests) and the proposed method is backward compatible with procedures defined in RFC 5036. The method uses the hello timeout negotiation procedures as per RFC 5035 without any changes in negotiation procedures.

The method proposed in the draft reduces the hellos (precisely the rate of hellos) required to be exchanged periodically to maintain the hello adjacency between two targeted peering LSRs. Hello adjacencies are maintained as is as per RFC 5035. There can be only one targeted adjacency to a peer. If one t-ldp peer supports the hello reduction procedures but the other peer does not, then the procedures result in no hello reduction and state of LDP session, adjacency remain as defined in RFC 5036. Implementations supporting the hello reduction procedures in the draft have been deployed with non-compatible peering implementations.  </Pranjal>

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.

<Pranjal> That is correct. Hello adjacencies continue to exist. </Pranjal>

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.

<Pranjal> That is correct. Hellos are connection less and a peer MAY update the hello message anytime and any of its parameters (configSeqNum, Hello HoldTime etc). If we refer to RFC 5036 procedures of Hello negotiations, respective timers (both hello tx and adj timeout) would get re-adjusted by both peers if any of the participating peers decide to change the hold time
On the fly.

This draft does not claim to prevent DoS attacks (It can't!). The reduction of hellos provides probabilistically better resiliency on maintenance of hello adjacency during sporadic DoS attacks. Sporadic DoS attacks on UDP port 646 can result in loss of "good" hello packets for certain period of time and thus leading to loss of existing adjacencies. We can certainly claim that it is "implementation specific" and implementations can do proper flow control of existing hello adjacencies (up and running) with H/w assisted flow control/filtering etc and penalizing only the hellos classified as "culprit" by such techniques. The draft does not keep a uniform view of LDP "implementations". I wouldn't intend to go too deep into various proven techniques already out there for years, but note that there are various cost functions associated with such techniques. Not all kinds of systems/implementations would like to implement such H/w assisted techniques. There could be systems that interfaces with large number of t-ldp peerings in mobility backhauls or access/aggregation networks(e.g 10K t-ldp peers) but does not need to deliver core data path functionalities (number of ldp tunnels, pseudowires per t-ldp peering are relatively small)
and so is the h/w assisted supported for faster hellos. </Pranjal>

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?

<Pranjal> Yes, we can clarify that in detail in the draft. I agree that it may not be apparent that RFC 5035 procedures are retained as is. The Hello adjacencies continue to exist "as is" as per RFC 5036.  </Pranjal>

- is it maintained by the fact that the LDP session still exists?

<Pranjal> That's correct. If hello adjacencies exist then sessions would continue to exist as long as session "keeplives" keep the sessions alive. </Pranjal> 

- is it maintained because the hold time is infinite and thus it actually will never cease to exist at all?

<Pranjal> It depends on case by case. The draft doesn't say that implementation is MANDATORY. 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". The draft intends to provide generic building block.

</Pranjal>

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

<Pranjal> This draft does not differ from RFC 5036 on this aspect. However 
Hello reduction procedures would restart (would fall back to hold time as 
Configured in peers) when there is loss of session or loss of adjacency. Thus the procedures allow fast/aggressive hello timers to be configured in 
large scale deployments (5K T-LDP peers) for faster discovery/session set-up,  but results in reduced hellos while sessions/adjacencies are being maintained. Section 4 point 3 mentions that hello reduction procedures start only after LDP session is established. 

Further section 4 states below:

"4. If the LDP session between two LSRs fails leading to tearing down
      of adjacency, then each LSR reverts to advertising their
      configured hello hold time and repeats procedure 1 to 3."


</Pranjal>

- 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)? 

<Pranjal> It would help if you could clarify what is meant by "new hellos". 
AFAIK, there can be only one targeted hello adjacency with a t-ldp peer that 
is identified by a unique LDP LSR-ID. The procedures does not apply to link 
Hello adjacencies since link hellos are continued to be sent over an interface at "configured rate" in order to keep discovering new hellos/peers over a broadcast interface. 
</Pranjal>

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.

<Pranjal> The draft does not say that any updates in hellos must not be reflected while reduction is in process. A t-ldp peer can reflect the any changes in hello parameters immediately and that doesn't break hello reduction if already in progress.  We can clarify that in the draft.  An update in config seq number doesn't necessitate that configured hold time be re-advertised rather than reduced hold time (reached at the time of change), unless the configured hold time itself is changed. If configured hold time is changed, the procedures can be restarted by advertising the updated hello hold time by the t-ldp peer.
        
</Pranjal>

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.

<Pranjal> Hello reduction procedures are working in production networks with compatible and non-compatible implementations. Since you are raising 
the question of "decrease in robustness of the LDP protocol", it would be great if you could precisely lay down the issues, algorithms in RFC 5036 
that are violated by this draft that would lead to degraded LDP. The draft further says that the procedures are OPTIONAL. In order to participate in hello reduction both t-ldp peers need to support the reduction procedures but when there is asymmetric case the procedures fall back to as described in RFC 5036. The draft is simply using hello timer negotiation techniques as defined in RFC 5036 to achieve reduction. In the draft we didn't intend to 
re-describe the Hello Negotiation procedures in RFC 5036 since it makes a 
normative reference to the latter anyway. 

</Pranjal>


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.

<Pranjal> I would like to re-iterate the fact that the draft doesn't introduce any "new" negotiation procedures to achieve hello reduction. 
It "reuses" the hello reduction procedures as per RFC 5036 and thus it is 
backward compatible. I already mentioned that the draft does not take uniform view of LDP implementations. 

Excepts from the draft - 

   "large number of LDP sessions (in thousands) to targeted peers, it
   is an additional burden to send and receive Targeted Hellos for all
   peers at periodic intervals. In MPLS deployments at access or
   mobility backhaul, there can be very large volume of LDP sessions
   with targeted LDP adjacencies. Moreover additional mechanisms such as
   centralized BFD [BFD] may be used to track liveliness of ldp
   sessions."

When there are deployments that can use BFD to track T-LDP peers, the Hellos 
become almost redundant after initial discovery and session set-up. It is definitely a pain when you configure aggressive hello timers for faster session set-up (which is a mandate in certain deployments for fast failure recovery with ~ 10K t-ldp peers after a network outage) and yet need to maintain the adjacencies thru hellos when BFD (or likewise) techniques are used to track reachability of existing adjacencies "after" adjacencies are formed. While it can be still be achieved by sending aggressive hellos at start but with larger hold time (thus both peer would have a very large timeout), but note that aggressive timeouts are desirable as well to tear down spurious hellos ASAP.

</Pranjal> 

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