The MPLS WG Archive

[Rahul Aggarwal <rahul@juniper.net>]

Hi Lou,

See below:

On Fri, 23 Jun 2006, Lou Berger wrote:

> JL,
>
> See below.
>
> At 03:20 AM 6/23/2006, LE ROUX Jean-Louis RD-CORE-LAN wrote:
>
> >Hi Lou,
> >
> >When RRO is not used this procedure does not
> >apply and remerge should be fixed in the data plane on the remerge node.
>
> "fixing in the data plane" doesn't work for all
> technologies covered in the spec, e.g., GMPLS optical.
>
> (You're making me think about my favorite HL Mencken quote...)
>
> >IMO full RRO inclusion is the price to pay if
> >you want to fix remerge in a simple manner in the control plane.
>
> Yes, but there is already a defined, documented,
> and agreed to mechanism that will work for all
> the cases.

It doesn't appear that the mechanism for fixing remerge in the control
plane works as defined and hence this discussion. See the email snippets
below outlining the issue:

<Last Call Comment from JL>

> 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?
>
>

<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"

As you can see from the last paragraph, we do need to create a new
object/type.


<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.

rahul

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