The MPLS WG Archive

[Lou Berger <lberger@labn.net>]

JL,

So what happens when no RRO is used (which isn't 
currently required) or portions of the RRO are removed?

Lou

At 02:03 AM 6/22/2006, LE ROUX Jean-Louis RD-CORE-LAN wrote:

>Hi Rahul, all
>
>Actually, after thinking a bit more, it seems to 
>me that a simpler remerge procedure based on RRO analysis could be useful.
>If the RRO is carried in Path messages, the node where the remerge
>occurs could easily identify the node that 
>created the remerge, simply by analyzing the two RROs.
>When a node detect a remerge it sends a PAthErr 
>with a new object (Remerge-Spec object) that 
>identifies the remerge origin. This PathErr 
>carries the set of sub-LSPs received in the Path 
>message that caused the remerge.
>On receipt of such PAthErr, a node that see its own address in the
>Remerge-spec object moves the set of sub-LSPs...
>
>It seems that this procedure would require simpler processing...
>It requires the use of RRO, but this is the price to pay.
>
>Would that make sense?
>
>Best Regards,
>
>JL
>
>
> > -----Message d'origine-----
> > De : Drake, John E [mailto:John.E.Drake2@boeing.com]
> > Envoyé : mardi 20 juin 2006 23:59
> > À : zzx-rahul@juniper.net; LE ROUX Jean-Louis RD-CORE-LAN
> > Cc : mpls@ietf.org
> > Objet : RE: [mpls] TR: working group last call
> > ondraft-ietf-mpls-rsvp-te-p2mp-05.txt
> >
> > Rahul,
> >
> > Snipped, comments inline.
> >
> > Thanks,
> >
> > John
> > > > > 4: Section 18.1.1 Remerge Procedure
> > > > >
> > > > > The text says
> > > > >    "The PathErr message MUST include all of the objects
> > > > >    normally included in a PathErr message, as well as
> > one or more
> > SUB-
> > > > >    LSP objects from the set of sub-LSPs associated with the
> > matching
> > > > >    P2MP LSP Path state.  A minimum of three SUB-LSP objects is
> > > > >    RECOMMENDED. This will allow the node that caused
> > the re-merge
> > to
> > > > >    identify the outgoing Path state associated with the valid
> > > > > portion of
> > > > >    the P2MP LSP. The set of SUB-LSP objects in the
> > received Path
> > > > > message
> > > > >    MUST also be included"
> > > > >
> > > > > And then:
> > > > >
> > > > >    "A node that receives a PathErr message that
> > contains the Error
> > > > > Value
> > > > >    "Routing Problem/P2MP Remerge Detected" MUST
> > determine if it is
> > the
> > > > >    node that created the re-merge case.  This is done
> > by checking
> > > > >    whether there is any intersection between the set of SUB-LSP
> > > > > objects
> > > > >    associated with the matching P2MP LSP Path state and
> > the set of
> > > > > SUB-
> > > > >    LSP objects in the received PathErr message.  If
> > there is, then
> > the
> > > > >    node created the re-merge case."
> > > > >
> > > > > There is an issue here. Actually there will always be an
> > > > > intersection, because the PathErr includes the set of sub-lsp
> > > > > objects in the received Path... IMO for this procedure
> > to work the
> > > > > PathErr MUST only include sub-LSP objects associated with the
> > > > > matching P2MP LSP state on the rermerge LSR and must
> > not include
> > > > > the set of SUB-LSP objects in the received Path message.
> > > > > By the way why are three objects recommended?
> > > > >
> > >
> > > I believe this was clarified by John Drake offline and no revisions
> > were
> > > needed ?
> > Rahul,
> >
> > Here's the e-mail I sent to JL:
> >
> > "JL,
> >
> > The text was originally stated as you stated.  The issue is
> > that the set of sub-LSPs associated with the interface on the
> > node that caused the re-merge condition may have more members
> > than the set of sub-LSPs in the received Path message, and
> > you only want to move the ones that were in the received Path message.
> >
> > Adrian was the one who initially pointed this and he proposed
> > creating a different object/type for the set of sub-LSPs in
> > the received Path message. I think this is reasonable solution.
> >
> > Thanks,
> >
> > John"
> >
> > As you can see from the last paragraph, we do need to create
> > a new object/type.
> >
>
>_______________________________________________
>mpls mailing list
>mpls@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/mpls


_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls