The MPLS WG Archive

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

Nagendra/Sumit/Vijay,

    LDP did not include discussion of timeouts as this is out of scope
for the specification.  The Label Request Abort message does allow
an implementation to use a timeout.

    Since LDP relies on routing, it is assumed that a routing loop is a
transient condition. By not forwarding a Label Request in which a
loop has been detected, looping of the LSP control messages is not
continued.  It is not necessary to remove a loop created by Label
Request messages since such a loop cannot produce a loop in the
data path.  This is not true for Label Mappings - therefore, in the
Label Mapping case, it is a good idea to release the mappings and
clean up state.

    In the Label Request case, when the loop is resolved, recognize
new nexthop will ensure that wrong state is cleared up and the
rest of the Label Request process reaches completion.

--
Eric Gray

You wrote:

> Yeah, actually I missed that point!
> --tomar
>
> On Tue, 12 Jun 2001 suchauhan@hss.hns.com wrote:
>
> >
> >
> > hi nagendra!
> >      In case we are using Loop Detection in a MPLS domain (or for that matter
> > over an LSP) and then in the case considered above the Loop Detection when
> > detected at a LSR shall be the first to detect it and hence it is before the
> > loop has actually occurred further down the LSP. We have still not reached the
> > receiver as this is an Intermediate LSP. Hence there should not be a loop if we
> > send back a notification to the source.
> >
> > regards
> > sumit
> >
> >
> >
> >
> > Nagendra Singh Tomar <nagendras@netbrahma.com> on 06/12/2001 08:55:44 AM
> >
> > Please respond to nagendras@netbrahma.com
> >
> > To:   Bob Thomas <rhthomas@cisco.com>
> > cc:   nagendras@netbrahma.com, Sumit Chauhan/HSS@HSS, mpls@UU.NET
> >
> > Subject:  Re: Error in RFC 3036??
> >
> >
> >
> >
> > Bob!
> >      I am sorry if I did'nt put it correctly, but by saying that the
> > Loop Detected Notification might in turn Loop, I meant that since a loop
> > was detected on the label request received, there is a very  high
> > possibility that the return path (from the receiver of the label request
> > to the sender of the Label request) for the notification message might as
> > well loop so its better to silently discard it.
> >
> > Is'nt it because of this Bob ?
> >
> > regards
> > tomar
> >
> >
> > On Mon, 11 Jun 2001, Bob Thomas wrote:
> >
> > > Tomar,
> > >
> > > > If the node detects a loop in the label request message, the  its wise not
> > > > to send the loop detected notification, because that might in turn loop
> > >
> > > Note that the Loop Detected Notification is not propagated by the
> > > receiver, and therefore will not loop.
> > >
> > > Bob
> > >
> > >
> > > > and make the network conditions worse. In the LRq.2 case the loop is not
> > > > detected in the label request message so we are sure that the return path
> > > > for the notification message has no loop, so it is safe to send a
> > > > notification in that case.
> > > >
> > > > --tomar
> > > >
> > > > On Mon, 11 Jun 2001 suchauhan@hss.hns.com wrote:
> > > >
> > > > >
> > > > >
> > > > > yup sorry! LRq.4 it is. typo ;o)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "zze-PELLE Thierry StagiaireFTRD/DAC/ISS"
> > <thierry.pelle@rd.francetelecom.fr> on
> > > > > 06/11/2001 03:27:43 PM
> > > > >
> > > > > To:   Sumit Chauhan/HSS@HSS, mpls@UU.NET
> > > > > cc:
> > > > >
> > > > > Subject:  RE: Error in RFC 3036??
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > IMHO, should it not be
> > > > > >      If Loop Detected , got to LRq.5
> > > > >
> > > > > LRq.4 and not LRq.5 I think....
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > >
> > > >
> > > >
> > ------------------------------------------------------------------------------
> > > >  Nagendra Singh Tomar
> > > >
> > > >  Residence:
> > > >  369 KHB Colony
> > > >  5th Block Koramangala
> > > >  Bangalore 95
> > > >  INDIA
> > > >  Phone : 5524839
> > > >  email : nagendras@netbrahma.com
> > > >
> > > >
> > > > "Sometimes quantity becomes quality"
> > > >                             --Gary Kasparov,
> > > >  When he played against Deep Blue. He said this after looking at a
> > > >  computer which found a forced mate in 249 in an endgame, after calculating
> > > >  all the possible moves with only 5 pieces left on the board.
> > > >
> > ------------------------------------------------------------------------------
> > > >
> > >
> >
> > --
> >
> >
> > ------------------------------------------------------------------------------
> >  Nagendra Singh Tomar
> >
> >  Residence:
> >  369 KHB Colony
> >  5th Block Koramangala
> >  Bangalore 95
> >  INDIA
> >  Phone : 5524839
> >  email : nagendras@netbrahma.com
> >
> >
> > "Sometimes quantity becomes quality"
> >                             --Gary Kasparov,
> >  When he played against Deep Blue. He said this after looking at a
> >  computer which found a forced mate in 249 in an endgame, after calculating
> >  all the possible moves with only 5 pieces left on the board.
> > ------------------------------------------------------------------------------
> >
> >
> >
> >
> >
> >
>
> --
>
> ------------------------------------------------------------------------------
>  Nagendra Singh Tomar
>
>  Residence:
>  369 KHB Colony
>  5th Block Koramangala
>  Bangalore 95
>  INDIA
>  Phone : 5524839
>  email : nagendras@netbrahma.com
>
> "Sometimes quantity becomes quality"
>                             --Gary Kasparov,
>  When he played against Deep Blue. He said this after looking at a
>  computer which found a forced mate in 249 in an endgame, after calculating
>  all the possible moves with only 5 pieces left on the board.
> ------------------------------------------------------------------------------