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

From: Maciek Konstantynowicz <[email-masked]>
Date: Tue, 12 Jul 2011 14:16:19 +0100

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

---

From: Eric Rosen <[email-masked]>
Date: Tue, 12 Jul 2011 10:41:37 -0400

> session negotiation  section 4.3.

If AN1 has a label for AN2, and AN2 goes down, this means that AN1 may not
get a new label for AN2 until two minutes after AN1 comes back up.  Is that
considered acceptable?

A different approach would be for AN1 to provide the AGN with a list of
prefixes for which it needs a label, and then to use the DU procedures,
applied to those specified prefixes only.  That would meet the goal of
keeping unnecessary labels out of AN1, while maintaining the faster
responsiveness of the DU procedures.  I understand that you don't want to
configure the AGN with the set of prefixes for which the AN needs labels,
but the AN could pass this information dynamically in an "outbound label
filter".

Was this approach considered?

> grow to a maximum delay of 2 minutes.

I'm not sure I understand the reference to "exponential backoff algorithm as
specified in RFC5036".

Let me ask a couple of other questions about draft-beckhaus-ldp-dod.

Section 4.1:

   "For the LDP DoD Advertisement mode on AN an ordered label
    distribution mode and conservative label retention mode MUST be
    supported."

The ordered/independent distinction only applies when you need to send a
label that is bound to a prefix for which you are not the LSP egress.  Does
this even apply to an AN?

Why do the ANs need to support conservative label retention mode?  If an AN
is homed to a pair of AGNs, what's wrong with it requesting a label from
each one?

   "The DoD mode is explicitly mentioned in the description of the
   conservative mode in RFC5036"

That's because conservative mode doesn't make much sense unless you are also
using DoD mode.  The converse is not necessarily true.

---

From: Kishore Tiruveedhula <[email-masked]>
Date: Tue, 12 Jul 2011 14:55:46 -0400

Eric,

  Please see below inline ..

>-----Original Message-----
>From: Eric Rosen [mailto:[email-masked]]
>Sent: Tuesday, July 12, 2011 10:42 AM
>To: Maciek Konstantynowicz
>Cc: [email-masked]; Nicolai Leymann; [email-masked]; Thomas Beckhaus;
>Kishore Tiruveedhula; Bruno Decraene
>Subject: Re: [mpls] LDP DoD and PW Signalling ...
>
>

[Kishore] This is kind of mixing both DU and DOD procedures and need to propose the distribution modes (DU, DOD and both) per fec independent of session distribution mode and requires protocol changes. 

>I'm not sure I understand the reference to "exponential backoff

[Kishore] Below is from section 2.5.3 in RFC 5036. This is the one referring in the above sentence and will add this reference section number in next revision. 

   The session establishment setup attempt following a NAK'd
   Initialization message MUST be delayed no less than 15 seconds, and
   subsequent delays MUST grow to a maximum delay of no less than 2
   minutes.  The specific session establishment action that must be
   delayed is the attempt to open the session transport connection by
   the LSR playing the active role.

>this even apply to an AN?

[Kishore] I think the ordered/independent applies to AGN, probably not for the egress case. I agree.

>using DoD mode.  The converse is not necessarily true.

[Kishore] I think the conservative mode doesn't restrict sending label requests to multiple peers in case of ECMP.

The conservative description in RFC 5036 says:

"If operating in Downstream on Demand mode, an LSR will request label
   mappings only from the next hop LSR according to routing."

Thanks,
Kishore

---

From: Eric Rosen <[email-masked]>
Date: Tue, 12 Jul 2011 16:04:07 -0400

>  This is kind of mixing both DU and DOD procedures and need to propose the
>  distribution modes (DU, DOD and both) per fec independent of session
>  distribution mode and requires protocol changes.

It does require a protocol extension to enable the AN to send its list of
"interesting prefixes" to the AGN.  Once that's done, it would really be DU
mode.

A couple of relevant drafts would be:

 draft-raza-mpls-ldp-applicability-label-adv-01.txt
 draft-raza-mpls-ldp-olf-00.txt

I think it's worth considering protocol extensions, as the DoD procedures
were really intended for a different application and may not be the best fit
for the requirements.

> I think the conservative mode doesn't restrict sending label requests to
> multiple peers in case of ECMP.

I wasn't thinking of the ECMP case, but of a case where the AN is using only
one route at a time.  Even if it is using only one route at a time, it may
want to be prepared to switch to the other route quickly if circumstances
change.  So if the AN is using DoD mode, it may still make sense to use
liberal label retention mode.  The number of extra labels for it to maintain
would not be large, and the latency to change paths is lowered.

---

From: Sami Boutros <[email-masked]>
Date: Mon, 25 Jul 2011 08:09:08 -0700

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:
>We wrote a separate draft with a detailed description of LDP DoD 
>behaviours in the context of Seamless MPLS

---

From: Sami Boutros <[email-masked]>
Date: Thu, 28 Jul 2011 06:29:49 -0700

Thomas,

I am not suggesting higher value for the timer, I do agree with you 
that smaller timer would be preferable but this could lead to more 
label requests being sent.

The question is wether it is acceptable to wait for up to 2 minutes 
to get the label binding for the egress node of the service after 
this node becomes reachable, since this would delay the convergence.

Thanks,

Sami
At 12:47 PM 7/27/2011, Thomas Beckhaus wrote:
>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,
> >