Subject: Re: LDP protocol problem?

From: [email-masked]
Date: Fri, 18 Jan 2002 02:16:49 -0500 (EST)

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

The problem also manifests itself if the session is
"Request-when-Needed" and "Downstream-on-Demand."  Example:

  Router A                          Router B
  --------                          --------

                                    Router A becomes the next hop
                                    Sends Label Request
  Receives Label Request
  Sends Label Mapping (Label 1)
                                    Router A becomes NOT the next hop
                                    Sends Label Abort Request
  Receives Label Abort Request
   (which is ignored)
                                    Receives Label Mapping (Label 1)
                                    Sends Label Release (Label 1)
                                     (because Router A is not the next hop)
  Sends Label Mapping (Label 1)
   (because the hop count changed)
                                    Router A becomes the next hop
                                    Sends Label Request
  Receives Label Release (Label 1)
                                    Receives Label Mapping (Label 1)
  Receives Label Request
  Sends Label Mapping (Label 2)
                                    Receives Label Mapping (Label 2)
                                    Sends Label Release (Label 2)
  Receives Label Release (Label 2)

The final outcome is the same.  Router B believes that a
Label Mapping exists; Router A believes that no Label Mapping exists.

The problem seems independent of distribution, control, or retention
modes.  The crux of the problem is that when Router A sends a
Label Mapping message which is an "update" message (the same FEC
and Label as a previous message, usually sent to change the
hop count and/or path vector) and then subsequently receives a
Label Release message for that FEC and Label, one of two
situations can exist:

  * If Router B sent the Label Release after receiving the
    "update" message, then Router B is not keeping the label

  * If Router B sent the Label Release before receiving the
    "update" message, then Router B may in fact keep the
    label if his situation changed between sending the
    Label Release and receiving the "update" message.
    (The most likely reason for the situation to change
    would be Router A becoming the next hop for the FEC.)

Router A simply cannot reliably determine which of these
two situations exists on Router B.

---

From: Abhijit Gadgil <[email-masked]>
Date: Fri, 18 Jan 2002 16:27:01 +0530 (IST)

>  Router A                          Router B

Key point missed here is, LRl. 1. and the note at the end of it.

>modes.

Not really, if B is using liberal retention it wont release the mappings
received as soon as next-hop changes.

-- 
-abhijit

Abhijit Gadgil
Graduate Student,
Dept. of Electrical Engineering,
IIT, Bombay.

---

From: Jack Brennen <[email-masked]>
Date: Fri, 18 Jan 2002 10:10:12 -0500

> Key point missed here is, LRl. 1. and the note at the end of it.

No, that is not relevant to this problem.  Router A is only
re-advertising the label mapping when it receives a label
request from Router B, just as the Note 1 of LRl.1 specifies.
Note that Router A is sending the "update" Label Mapping before
it sees the Label Release from Router B.

> received as soon as next-hop changes.

Okay, but Router B may release the first (original) mapping due
to a loop-detection problem, and keep the second (update) mapping
due to the loop-detection problem going away.  It may have nothing
to due with a next-hop change on Router B.

Try this scenario in liberal unsolicited mode:

  Router A                          Router B
  --------                          --------

  Sends Label Mapping
   (Path Vector=<B,C,D,A>)
                                    Receives Label Mapping
  Router A gets a new next hop
   for the FEC
  Sends Label Mapping
   (Path Vector=<E,F,G,A>)
                                    Sends Label Release
                                     (loop detected)
  Receives Label Release
                                    Receives Label Mapping

The specification calls for resending of Label Mapping messages
when the Loop Detection information changes.  These resent messages
look just like first-time Label Mapping messages.  If a resent
Label Mapping message from Router A "crosses on the wire" with a
Label Release message from Router B, we have the unfortunate situation
where Router A thinks that the Label Mapping has been released and
not readvertised, but Router B thinks that the Label Mapping has been
released _and readvertised_.

I can't see how to fix this without changing the specification.
Fortunately, the fix can be easy; simply mark all resent ("update")
Label Mapping messages as such.  Then the receiving router will
never confuse an "update" Label Mapping with a re-advertisement.
If an "update" Label Mapping is received which doesn't correspond
to any currently held label, it is silently ignored.

   Jack Brennen