Subject: [mpls] RFC 4875 re-merge procedures (section 18)

From: "Nic Neate" <[email-masked]>
Date: Mon, 7 Jul 2008 16:31:31 +0100

Hi all,

Section 18 the RFC 4875 (http://tools.ietf.org/html/rfc4875#section-18)
defines the procedures for an LSR that receives multiple Path messages
for the same P2MP LSP from different PHOPs.  The intention is to prevent
data duplication in that scenario.

I think the procedures in the RFC are insufficient for the following
reasons.  The key point here is that an LSR following the procedures
defined in the RFC may cause data loss during sub-group re-optimization.

-  Section 18 discusses dynamic reroute and make-before-break but not
sub-group re-optimization.  The latter (defined in section 14.2) is
another case where an LSR could receive multiple Path messages for the
same P2MP LSP from different PHOPs.

-  LSRs are told to differentiate re-merge and cross-over cases from
dynamic reroute by checking whether the sets of S2L sub-LSPs in the
upstream Path messages overlap.  If they do not then it is
re-merge/cross-over (see section 18.1 paragraph 2).  However, both
dynamic reroute and sub-group re-optimization could cause an LSR to
receive a new Path message containing a set of S2L sub-LSPs that does
not overlap with its existing path state.  Consider the case where
re-optimization causes an LSR to become on the path for one S2L sub-LSP
and be removed from the path of another S2L sub-LSP.

-  Having falsely identified a sub-group re-optimization (or dynamic
reroute) as a re-merge, an LSR may (if so configured) send a PathErr for
its existing path state with the Path_State_Removed flag set (section
18.1.1).  That will cause data loss if the new, re-optimized sub-tree
has not yet been fully set up.

-  Finally, as a separate point, it's worth noting that if the
downstream interfaces for two Path messages are the same, but the
downstream labels are not, then that is cross-over rather than re-merge
and needs to be handled as such.  That case is omitted by the RFC, which
only discusses downstream interfaces (section 18.1 paragraph 3).

I'd appreciate comments on whether this is indeed a problem that needs
solving.  (If it is then I have some ideas on how that might be
achieved.)

Thanks,

Nic Neate
Data Connection Ltd.
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 14 Jul 2008 15:07:34 +0100

Nic, again.

> has not yet been fully set up.

No, I don't think that responding to a Path message with a PathErr will 
cause data loss as no Resv has yet flowed.

Note that a little thought by the node performing the reoptimization makes 
sure that this situation does not arrise.

> solving.  (If it is then I have some ideas on how that might be

I don't believe there is a problem here.

Adrian

---

From: "Nic Neate" <[email-masked]>
Date: Fri, 18 Jul 2008 11:43:01 +0100

Hi Adrian,

Thanks for your emails.  I agree that data loss can be prevented by a
thinking re-merge node.

However, the re-merge node is still sabotaging an upstream LSR's
re-optimization attempt by removing path state.  So there is a protocol
bug here:

-  An upstream LSR on the P2MP LSP wants to re-optimize the path of a
sub-tree passing through it.  It does this using sub-group based
re-optimization (RFC section 14.2) and sends a new Path message for the
S2L sub-LSPs it is re-optimizing in a new sub-group with a new ERO.

-  At some point downstream, an LSR that is already on the P2MP LSP
receives a new Path message for the re-optimized route.  It arrives on a
new incoming interface and describes S2L sub-LSPs that it does not have
any existing state for.  Following the rules in section 18 of the RFC,
the LSR mistakes this for a re-merge.  Wishing to correct the re-merge,
it responds to the Path with a PathErr.

-  The re-optimization attempt has now failed.  The upstream LSR will
receive the re-merge PathErr message.

You suggest that this could be fixed by "a little thought by the node
performing the re-optimization".  That may not be possible if the ERO
contains loose hops, and could prevent re-optimization in some
topologies.

My preference would be for LSRs to be forbidden from sending re-merge
PathErr messages at all.  That would fix this flaw in the
re-optimization mechanism.  Upstream LSRs could still detect and correct
re-merge conditions by analyzing RROs and rerouting.  Given that the RFC
already mandates that LSRs have a configuration option to disable the
re-merge PathErr processing, I don't think this would be a major
protocol change.

Nic

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Aria - Adrian Farrel Personal
Sent: 14 July 2008 15:08
To: Nic Neate; [email-masked]
Subject: Re: [mpls] RFC 4875 re-merge procedures (section 18)

Nic, again.

> Section 18 the RFC 4875 
> (http://tools.ietf.org/html/rfc4875#section-18)

> for the same P2MP LSP from different PHOPs.  The intention is to 
> prevent data duplication in that scenario.
>

> re-optimization causes an LSR to become on the path for one S2L 
> sub-LSP and be removed from the path of another S2L sub-LSP.
>
> reroute) as a re-merge, an LSR may (if so configured) send a PathErr 
> for its existing path state with the Path_State_Removed flag set 
> (section 18.1.1).  That will cause data loss if the new, re-optimized 
> sub-tree has not yet been fully set up.

Note that a little thought by the node performing the reoptimization
makes sure that this situation does not arrise.

> downstream labels are not, then that is cross-over rather than 
> re-merge and needs to be handled as such.  That case is omitted by the

> RFC, which only discusses downstream interfaces (section 18.1
paragraph 3).

Adrian