Subject: [mpls] RFC 4875 ERO processing details

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

Hi all,

This is the last of four emails querying P2MP LSP behavior in RFC 4875.
Could someone please help me with the following questions on ERO
processing?

(1) Explicit label processing details

Explicit labels could be included in an ERO/SERO to specify two S2L
sub-LSPs with the same next hop but different labels (for example, in an
optical network where different wavelengths are required to reach
different leaf nodes).  Both S2L sub-LSPs could be signaled in a single
Path message (although ERO compression for the next hop would not be
possible).

In the reverse direction, separate Resv messages must be used for each
S2L sub-LSPs because a single Resv MUST use the same label in all
filterspecs for the same P2MP LSP (section 6.2).

Is it therefore allowed for S2L sub-LSPs in the same sub-group to be
signaled in different Resvs with different labels, or should the
upstream LSR signal them in different sub-groups, and therefore
different Path messages?

(2) ERO compression details (section 4.5)

Last paragraph in section 4.5 of the RFC states the following:

                                                      All LSRs need to
   process the ERO corresponding to the first S2L sub-LSP.  An LSR needs
   to process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP
   only if the first hop in the corresponding SERO is a local address of
   that LSR.  The branch LSR that is the first hop of an SERO propagates
   the corresponding S2L sub-LSP downstream.

I think that implies the following ERO compression technique.
-  In Path messages sent by the source, all SEROs are specified right
from the first branch point in the P2MP LSP.
-  At each branch point, SERO hops that come before the next branch
point are stripped off before Path messages are forwarded.

Thus, at any point in the P2MP tree, the hops to the next branch point
are only specified once in the ERO, but thereafter all SEROs are fully
specified even if they have large sections in common.

That is not the ERO compression technique described in the example
earlier in section 4.5, and also not optimal for RSVP Path message size.
That suggests that the statement that "An LSR needs to process an S2L
sub-LSP descriptor for a subsequent S2L sub-LSP only if the first hop in
the corresponding SERO is a local address of that LSR" is inaccurate.
Instead
-  each LSR needs to check the first hop of all SEROs
-  if an LSR is the first hop of any SERO then it is a branch point
-  a branch point needs to further analyze all SEROs to determine which
branch each S2L sub-LSPs belongs to.

Further, failure to do that could lead to routing errors.  Is that
understanding correct?

Thanks,

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

---

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 7 Jul 2008 18:01:36 -0700 (PDT)

Hi Nic,

On Mon, 7 Jul 2008, Nic Neate wrote:

> different leaf nodes).

In this case is it not the responsibility of the branch LSR to replicate
the incoming label onto two different outgoing labels?

rahul

  Both S2L sub-LSPs could be signaled in a single

---

From: "Nic Neate" <[email-masked]>
Date: Tue, 8 Jul 2008 12:16:38 +0100

Hi Rahul, 

> > sub-LSPs with the same next hop but different labels (for 
> example, in 
> > an optical network where different wavelengths are required 
> to reach 
> > different leaf nodes).
> 
> In this case is it not the responsibility of the branch LSR 
> to replicate the incoming label onto two different outgoing labels?
> 
> rahul
> 

Sure, this is definitely a branch point in the data plane.  My question
is whether it also needs to be a branch point in the control plane.  Do
the S2L sub-LSPs need to be signaled in different Path messages, given
that their next hop is the same?

My reading of section 6.2 of the RFC is that it is not necessary.  If a
single Path message is used then the downstream LSR can still use
different Resvs for each S2L sub-LSP to signal the different labels even
though both S2L sub-LSPs are in the same sub-group.

On the other hand, the RFC states that the downstream LSR SHOULD use the
same label across multiple Resv messages for the same P2MP LSP - which
is not possible in this case.

What do you think the correct way to signal this is?

Do you have an opinion on the ERO compression question below as well?

Thanks,

Nic

> >                                                       All 
> LSRs need to
> > sub-LSP descriptor for a subsequent S2L sub-LSP only if the 
> first hop 
> > in the corresponding SERO is a local address of that LSR" 
> is inaccurate.
> > Instead
> > -  a branch point needs to further analyze all SEROs to determine 
> > which branch each S2L sub-LSPs belongs to.
> >

---

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

Hi Nic,

I think I was driving this function with some support from Igor when the RFC 
was still a draft.

As you observe, the point at which one label splits into two labels (even 
with the same outgoing interface) is a branch in the data plane.

You are also correct that two Resv messages will be required because each 
can carry just one Label object.

Now, if the node that is the branch in the data plane wishes to control 
which label is used on the two downstream segments, it must signal this to 
its neighbor. This would certainly be the case in the example you cite, 
where the labels are included in the ERO/SERO. But, the way that the label 
is conveyed from an upstream node to its neighbor is in a Label_Set or 
Suggested_Label object and you will observe that we only allow one of these 
on a Path message.

QED you need two Path messages from the branch point.

Cheers,
Adrian

---

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

Nic,

> point are stripped off before Path messages are forwarded.

I think you should re-read the example in the RFC.

Each SERO runs from a branch point to a leaf. Compressed SEROs do not share 
any hops when the S2L LSPs they describe share resources. if two S2L LSPs 
follow the same path from some branch point LSR-A, and diverge downstream at 
LSR-B, one of the SEROs will begin at LSR-A and the other at LSR-B.

Thus, there is no stripping of SEROs to be performed.

> specified even if they have large sections in common.

As above. Look at the example in the RFC.

I don't see any contradiction with the section 4.5 text.

Adrian

---

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

Hi Adrian,

You've clarified what the correct interpretation of ERO compression in
section 4.5 is, thanks.  I think that means you agree with my SERO

That is contradictory to the statement in the RFC that "An LSR needs to
process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP only if
the first hop in the corresponding SERO is a local address of that LSR".

A branch point C might be faced with SEROs C-D-E, C-F and E-G-H.  It
needs to look at all the hops here, not just the first ones, to
establish that the first and third S2L sub-LSPs are in one branch and
the second is in another.

Nic

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Aria - Adrian Farrel Personal
Sent: 14 July 2008 14:58
To: Nic Neate; [email-masked]
Subject: Re: [mpls] RFC 4875 ERO processing details

Nic,

Each SERO runs from a branch point to a leaf. Compressed SEROs do not
share any hops when the S2L LSPs they describe share resources. if two
S2L LSPs follow the same path from some branch point LSR-A, and diverge
downstream at LSR-B, one of the SEROs will begin at LSR-A and the other
at LSR-B.

> sub-LSP descriptor for a subsequent S2L sub-LSP only if the first hop 
> in the corresponding SERO is a local address of that LSR" is
inaccurate.

Adrian