The MPLS WG Archive

["Sanford, Bill" <bills@netplane.com>]

Eric, 

If a PATH message has looped (given that RRO is used), either the loop will
be detected and the LSP will fail, the LSP will be established or the RRO
will be dropped mid-stream and loop before reaching the destination node.
If the RRO is to big and not looping, the intermediate node should send an
error to the Ingress and drop the RRO from the LSP and keep it moving to the
destination node.  If the LSP gets into a loop and causes the RRO to grow to
beyond the MAX MTU, the RRO should have detected it and stop at the first
instance of the loop.  If the RRO is dropped and the LSP loops before
reaching the destination node, how could you then tell if a loop has occured
if the MAX MTU isn't increased to go to the destination node?

If a RESV message has looped, the last paragraph in 4.4.4 of
draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, "For Resv messages containing a
forwarding loop, the router simply drops the message.  Resv messages should
not loop if Path messages do not loop."

> -----Original Message-----
> From: Eric Gray [mailto:EGray@zaffire.com]
> Sent: Friday, June 30, 2000 11:52 AM
> To: 'Sanford, Bill'; 'George Swallow'
> Cc: 'mpls@UU.NET'
> Subject: RE: Need for RRO Object in the Error Mesg. 
> 
> 
> Bill,
> 
> 	This is probably a good idea - though one
> reason for including the RRO is that it might be
> a good way to tell if the cause is that a message
> has looped undetected for some reason.
> 
> --
> Eric Gray
> 
> > -----Original Message-----
> > From: Sanford, Bill [mailto:bills@netplane.com]
> > Sent: Friday, June 30, 2000 5:41 AM
> > To: 'George Swallow'
> > Cc: 'mpls@UU.NET'
> > Subject: RE: Need for RRO Object in the Error Mesg. 
> > 
> > 
> > In 4.4.2 of draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, the three 
> > possible uses
> > for the RRO are loop detection, up-to-date detailed path information
> > hop-by-hop about RSVP sessions, and to populate the 
> > EXPLICIT_ROUTE object.
> > In all my interoperability testing, all of these scenarios 
> > are handled by
> > the PATH and RESV message types.  
> > 
> > We should let the "RRO too large for MTU" subcode return in 
> > the ERROR SPEC
> > object without having to return the RRO.
> > 
> > Bill
> > 
> > > -----Original Message-----
> > > From: George Swallow [mailto:swallow@cisco.com]
> > > Sent: Thursday, June 29, 2000 3:41 PM
> > > To: Markus Jork
> > > Cc: mpls@UU.NET; swallow@cisco.com
> > > Subject: Re: Need for RRO Object in the Error Mesg. 
> > > 
> > > 
> > > > arumugamr@future.futsoft.com said:
> > > > > This message is regarding to the need of RRO object in 
> > the PathErr
> > > > > message  & ResvErr Mesg if the size of the RRO exceeds 
> > the Maximum
> > > > > MTU. Is it not enough to send the error message alone to 
> > > the Ingress
> > > > > of the  tunnel to get it removed? 
> > > > 
> > > > I also don't see much value in including the RRO object in the
> > > > error message and think this requirement should be removed from
> > > > the spec.
> > > > In addition, this part of the spec conflicts with section 3 and
> > > > section 4.4 of the same spec 
> (draft-ietf-mpls-rsvp-lsp-tunnel-05)
> > > > which say that an RRO is only included in Path and Resv 
> messages.
> > > > 
> > > > Markus
> > > 
> > > Seems that a number of folks would like to see this 
> disappear.  Does
> > > anyone want to argue for keeping it?  If not I'll remove 
> it from the
> > > next rev (which will be out before the cut-off).
> > > 
> > > ...George
> > > 
> > > ==================================================================
> > > George Swallow       Cisco Systems                   
> (978) 244-8143
> > >                      250 Apollo Drive
> > >                      Chelmsford, Ma 01824
> > > 
> > 
>