The MPLS WG Archive

["LE ROUX Jean-Louis RD-CORE-LAN" <jeanlouis.leroux@orange-ft.com>]

Hi Rahul,

>Would you like to propose the modified text ? 

I can provide some text by the end of the day.

Regards,

JL


> -----Message d'origine-----
> De : Rahul Aggarwal [mailto:rahul@juniper.net] 
> Envoyé : jeudi 22 juin 2006 15:53
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : mpls@ietf.org; Drake, John E
> Objet : RE: [mpls] TR: working group last call 
> ondraft-ietf-mpls-rsvp-te-p2mp-05.txt
> 
> 
> 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