The MPLS WG Archive

[Rahul Aggarwal <rahul@juniper.net>]

Hi JL,

On Thu, 22 Jun 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.
>

I think this is reasonable. If it is desriable to fix remerge in the
control plane this is a reasonable tradeoff. Else the spec has the option
to fix remerge in the data plane.

> Would that make sense?
>

Would you like to propose the modified text ?

Thanks,
rahul

> 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