Subject: Re: [mpls] [MPLS] LDP DoD and PW Signalling ...

From: Thomas Beckhaus <[email-masked]>
Date: Wed, 27 Jul 2011 21:47:10 +0200

Sami,

do you have any concerns regarding the 2 minutes? For the general AN scenario (only very limited number of FECs), I could imagine also a smaller number to get a faster recovery time. I do not see a need to get a higher value. But I am not sure to change the RFC5036 value because of this.

Best wishes to Quebec City
Thomas

Am 25.07.2011 um 17:09 schrieb Sami Boutros:

> Maciek,
> 
> Will the 2 mins back off be acceptable? or will you address this aspect in your draft? and if so how?
> 
> Thanks,
> 
> Sami
> At 06:16 AM 7/12/2011, Maciek Konstantynowicz wrote:
>> Eric,
>> 
>> Regarding your question about handling unreachable FEC becoming reachable again:-
>> 
>> We wrote a separate draft with a detailed description of LDP DoD behaviours in the context of Seamless MPLS
>> http://tools.ietf.org/html/draft-beckhaus-ldp-dod-00
>> 
>> In this draft, #section-4.4.3 describes the behaviour in case specific requested FEC is unreachable:
>> 
>> 4.4.3.  Label Request Retry Procedure
>> 
>>   If AN or AGN receives a "No route" Notification in response to its
>>   label request message, it should retry with exponential backoff
>>   algorithm similar to the backoff algoritm mentioned in the LDP
>>   session negotiation  section 4.3.
>> ...
>>   AN should follow the exponential backoff algorithm as specified in
>>   the (RFC5036 [RFC5036] with delay of 15 seconds and subsequent delays
>>   grow to a maximum delay of 2 minutes.
>> 
>> Maciek
>> 
>> 
>> 
>> 
>> On 29 Jun 2011, at 15:56, Eric Rosen wrote:
>> 
>> >
>> >> For a more long term approach we are in favour of a change to RFC5036 by
>> >> defining a new TLV which denotes the DU/DoD mode per FEC type.
>> >
>> > Does that mean you expect every FEC type to be able to work in both modes?
>> > If you only anticipate needing DoD for address prefix FECs, a more
>> > conservative solution might be to just clarify that the negotiated session
>> > mode applies only to address prefix FECs.
>> >
>> > While on the topic, I do have a question about the use of DoD for address
>> > prefix FECs.
>> >
>> > From draft-leymann-mpls-seamless-mpls-03:
>> >
>> >   the AN will use LDP DoD to only request the label bindings
>> >   for the FECs corresponding to the loopback addresses of those egress
>> >   nodes to which it has services configured.
>> >
>> > Suppose one of the configured egress nodes is down or otherwise unreachable
>> > at the time the AN asks for a label binding.  How does the AN get the label
>> > binding when the egress node becomes reachable?  Is the AN expected to ask
>> > periodically for the binding?  Is the periodic interval expected to be
>> > configurable?  The draft should say something about this.
>> >
>> > I don't think RFC 5036 requires the AGN to remember what the AN has asked
>> > for, so that it can reply when and if the egress becomes reachable.
>> >
>> >
>> > _______________________________________________
>> > mpls mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/mpls
>> 
>> _______________________________________________
>> mpls mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls
> 
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Eric Rosen <[email-masked]>
Date: Fri, 05 Aug 2011 10:59:09 -0400

> do you have any concerns regarding the 2 minutes?  For the general AN
> scenario (only very limited number of FECs), I could imagine also a
> smaller number to get a faster recovery time  ... I am not sure to change
> the RFC5036 value because of this.

The backoff scheme described in RFC 5036 has to do with connection setup
attempts.  I assume an AN won't try to set up a TCP connection with its AGN
unless it has an operational link to the AGN.  The exponential backoff
protects an AGN that is just coming up from getting repeatedly bombarded
with connection requests at a faster rate than it can respond to.

In this thread, we are discussing something entirely different.  The LDP
connection is already set up, the AN has already asked the AGN for a label
bound to a particular FEC, and there is a routing change that affects the
AGN's ability to reach the FEC.  The issue is how the AGN should communicate
this routing change to the AN.  Generally the timeframe for communicating
routing changes is very small, much smaller than two minutes, and generally
information about routing changes is pushed rather than pulled.

I understand that each AN only needs to know about a small number of address
prefixes.  So it would seem that a good solution would work as follows:

- A particular AN tells AGN "I want to register to receive information about
  the following set of prefixes".

- The AGN then pushes the current information about those prefixes to the
  the ANs that have registered for those prefixes.

- Routing changes regarding those prefixes are pushed quickly to the ANs
  that have registered for those prefixes.

This seems like a simple paradigm that does not require per-service
configuration on the AGN, that does not require periodic polling from the
ANs, and that does not suffer from slow recovery due to exponential
backoff.  I'm not sure why you'd want to do periodic polling when you've
already set up a TCP connection.

The DoD procedures in LDP were designed around the assumption that the LDP
peers are already engaged in a routing protocol with each other.  If the AN
and the AGN, for example, were running a routing protocol between
themselves, the AN would quickly learn via routing whether a given FEC is
reachable via the AGN, and the AN could request a label as soon as the FEC
becomes reachable.  RFC5036 really assumes that even in the DoD case,
routing changes get pushed.