The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

oops, meant to send to the list

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray

---

• From: Eric Gray <eric.gray@sandburst.com>
• Date: Fri, 18 Jan 2002 13:38:06 -0500

Vijay,

    Yes.  You should probably stick to the terminology used in the LDP
specification, rather than using the terminology from the Architecture.
There is a mapping, but it does not aid in understanding to have to be
making that mapping several times in just a few short sentences.

    The combination of downstream unsolicited and conservative retention
is not very useful in  general because it results in excessive amounts of
label release messages.  The confusion below should not occur in a good
implementation, but the fact that it can occur in general is attributable
to the use of an unreasonable combination of operating modes.

You wrote:

> I faced a similar problem some time back
>
> I think the problem comes because of the configuration of the LDP label
> distribution mode, control mode and Request mode.
>
> Particularly here the request node is REQUEST_NEVER though the distribution
> mode is DuS. If router B were 'Request When Needed' then it would have
> requested A for a label when A becomes its next Hop then the problem would
> have been overcome by A sending the mapping again after receiving the
> request. I wonder if DuS Ind control with 'Request Never' is not a good
> configuration choice
>
> Please correct me if I am wrong.
>
> Regards,
> Vijay
>
> -----Original Message-----
> From: John.Brennen@marconi.com [mailto:John.Brennen@marconi.com]
> Sent: Friday, January 18, 2002 8:53 AM
> To: mpls@UU.NET
> Subject: LDP protocol problem?
>
> I think I have found a serious protocol problem in LDP (RFC 3036).
> The best way to describe it is to give an example...
>
> Consider the following set of events, in chronological order
>  (all messages refer to the same FEC/Label pairing; the session
>  supports unsolicited label mappings; and Router B is using
>  conservative label retention):
>
>   Router A                          Router B
>   --------                          --------
>
>   Sends Label Mapping
>                                     Receives Label Mapping
>                                     Sends Label Release
>                                      (because Router A is not the next hop)
>   Sends Label Mapping
>    (because the hop count changed)
>                                     Router A becomes the next hop
>   Receives Label Release
>                                     Receives Label Mapping
>
> The problem here is that the Label Mapping message which updates the
> hop count and the Label Release message are sent more or less
> simultaneously.
>
> The result in the scenario above is that Router A thinks that there is no
> valid Label Mapping advertised to Router B.  Router B thinks that it
> has a valid Label Mapping.
>
> At least three problems can come from this.  First, Router B can put traffic
> onto a label which Router A has reused for another purpose.
>
> Second, Router A may try to readvertise the FEC in the future.
> Router B will not accept any such Label Mappings (LMp.10, Appendix A,
> RFC 3036), unless Router A is fortunate enough to use the same
> label which was originally used.
>
> Third, if Router B tries to release the label, Router A may
> report an error.
>
> Is this analysis correct?  Is this a real problem with the protocol?
> If so, is it already known?  How can this problem be solved?
>
>     Jack Brennen

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray

---