The MPLS WG Archive

[Abhijit Gadgil <gabhijit@ee.iitb.ac.in>]

Jack,

Yes I agree to you, a simple solution to this problem could be as follows

Label Release message will carry mesg-id (mandatory)to indicate exactly
this is an ack for which message, this can work for withdraw messages as
well. So there is no need to change the semantics of original mappings and
updates.

The LSR which receives this release, can check the message-id and take a
decision on to what can be done with it. If the mesg-id is older than the
most recently used message-id (to the peer, for that fec), it may ignore
the Release message, silently.

If the Release is as a result of some internal event at LSR, it may use
the message-id field of all zero's to indicate the internal event. (If the
release is being propagated, it can still be interpreted by downstream LSR
as internal event at upstream LSR). In such case, the downstream LSR
should not silently ignore this.

I tried working this scheme for two or three scenario's which you have
specified, it works correctly.

Also as Eric has pointed out on this thread a label release is an ack to
label withdraw message, its not quite unreasonable to send it as nack for
"a specific mapping" message. It doe not complicate the processing of
label mapping message and any LSR does not have to do extra work to check
whether a mapping received is updated mapping or not. An LSR when it needs
to do so, can simply release with proper mesg-id.

Does this sound alright?

-abhijit

Jack Brennen wrote :

>> > But the problem has nothing to do with DoD mode.  It occurs in DU mode as well:
>> >
>> >   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
>> >
>> > At the end of this scenario, Router B holds a label which he believes was
>> > validly advertised by Router A.  Router A believes that Router B released
>> > the label.
>>
>> This is a smallish sort of window, which may be sorted by simply
>> having Router A send a Label Withdraw when it receives packets
>> that are labeled with the labels that Router B mistakenly thinks
>> are valid.  I think that a robust LSR implementation will do
>> that in any case.
>>
>
>But Router A believes Router B to have released the label, so he may
>reuse it for another purpose.  When Router B eventually puts traffic
>onto the label (which may occur hours later), there is no reason to
>believe that the label will still be unassigned.
>
>And it is a smallish sort of window, but I'm not bringing this to the WG's
>attention because of a theoretical concern.  This problem is being observed
>in our lab under stress conditions.  It really happens in the real world.  :-(
>
>Another way to look at this, which I hope *clearly* demonstrates the
>intractable nature of this problem.  Consider these three protocol
>conversations:
>
>   Conversation 1                           Conversation 2
>   --------------                           --------------
>
>   Router A            Router B             Router A        Router B
>   --------            --------             --------        --------
>   Send LMap                                Send LMap
>                       Recv LMap                            Recv LMap
>                       Send LRel                            Send LRel
>   NHOP Changes                             Recv LRel
>   Send LMap                                NHOP Changes
>   Recv LRel                                Send LMap
>                       Recv LMap                            Recv LMap
>
>
>   Conversation 3
>   --------------
>
>   Router A            Router B
>   --------            --------
>   Send LMap
>                       Recv LMap
>   NHOP Changes
>   Send LMap
>                       Recv LMap
>                       Send LRel
>   Recv LRel
>
>These conversations are all legal according to the LDP spec,
>and all are reasonably likely to happen.  Note that Router B can't
>tell the difference between Conversations 1 & 2, and Router A can't
>tell the difference between Conversations 1 & 3.
>
>  Conversation 1:  A ends up with no label allocated, B has a label
>  Conversation 2:  A and B both end up with a label allocated
>  Conversation 3:  A and B both end up with no label allocated
>
>Clearly, Conversation 1 leads to problems, but neither Router A nor
>Router B can distinguish this from the valid Conversations 2 & 3.
>
>This is a deficiency in the protocol, and we can brainstorm any number
>of methods to work around the problem, but the problem is there,
>and should be addressed.
>
>   Jack
>

-- 
-abhijit

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