The MPLS WG Archive

[Rahul Aggarwal <rahul@juniper.net>]

Hi Lou, JL and all,

On Sat, 24 Jun 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote:

> Hi Lou,
>
> Your proposed update to the remerge text covers my initial LC comment.

Great. Please see inline:

> This requires quite a lot of processing compared to the RRO-based approach I suggested, but it works in all situations (no RRO or partial RRO). Hence it must be kept...
>
> Also please see inline,
>

<snipped>

> >
> >  I agree the text could be clearer.  But I think this is the
> > sole issue.
> >
> > >  Actually there will always be an
> > > > intersection, because the PathErr includes the set of sub-lsp
> > > > objects in the received Path...
> >
> > The text should have stated "... matching P2MP LSP Path state
> > and the set of other-branch SUB-LSP objects in the
> > (added-----^^^^^^^^^^^^, and vvvvvvvvvvvvvvvvvvvvvvv)
> > received PathErr message.  Other-branch SUB-LSP objects are
> > those SUB-LSP objects included, by the node detecting the
> > re-merge case, in the PathErr message that were taken from
> > the matching P2MP LSP Path state.  Such SUB-LSP objects are
> > identifiable as they will not be include in the Path message
> > associated with the received PathErr message.  See Section
> > 11.1 for more details on how such an association is identified."
>
> OK this text is definitely clearer, and easy to understand.
>

The editors will include this in the next rev and consider this LC comment
addressed..

Thanks JL for identifiying the issue and Lou for fixing the text.

rahul

>
> >
> > >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?
> > > >
> > > >
> >
> >
> > Both sets of SUB-LSP objects are required.  Here's why:
> > 1) SUB-LSP objects from the Path message (your point): this
> > is required to cover the case of other branches between the
> > node that detected a re-merge and the node that caused the
> > re-merge.
>
> OK, I see.
>
> > Just moving all the  SUB-LSP objects at the
> > offending branch node is at best unneeded disruption to such
> > (sub) branch destinations and at worst will result in a new
> > re-merge situation.  In the latter case, the result could be
> > permanent instability and oscillation between multiple
> > re-merge points.
>
> OK
>
> > 2) "Other-branch" SUB-LSP objects: These are required to
> > cover the case where a branch node has more than two (or n)
> > outgoing path messages.  Consider the case where there are 3
> > outgoing path messages and one of which results in a
> > (partial) re-merge downstream.  To correct the problem, this
> > branch node needs to identify which of the other 2 (or n-1)
> > outgoing path messages is triggering the re-merge.
> > "Other-branch" SUB-LSP objects provide this identification.
> > Also, as they are already being included, these objects are
> > also used to identify the branch node that caused the re-merge.
>
> OK
>
> >
> >
> >
> > ><End LC comment from JL>
> > >
> > ><Response to the above by Rahul>
> > >
> > > > I believe this was clarified by John Drake offline and no
> > revisions
> > > > were needed ?
> > >
> > ><End of the response to the above by Rahul>
> > >
> > ><John Drake's Comment on the above>
> > >
> > >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"
> >
> > While a different type is a possible solution, I think John
> > is forgetting a detailed discussion that he and I had in
> > which we decided that we could use another object (or c-type)
> > but decided that such identification wasn't really needed for
> > proper processing so we decided not to add the complexity of
> > a new type.
> >
> > >As you can see from the last paragraph, we do need to create a new
> > >object/type.
> > >
> >
> > I think that a new type isn't needed and what is defined (and
> > further clarified above) is sufficient.
>
> A new type would allow easier identification of "other-branch" sub-LSP objects, it would require less processing, but I agree that this works as is.
>
> Regards
>
> JL
>
> >
> > ><End of John Drake's comment on the above>
> > >
> > > > De we really want/need to be making
> > > > such a significant change at this late date (post WG last
> > call!).
> > > > If it were broken, then certain a change would be needed, but I
> > > > haven't heard anyone make such an
> > > assertion.
> > > >
> > >
> > >See above for the assertion.
> >
> > see above.
> >
> > Lou
> >
> >
> > >rahul
> >
> >
>
>

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