Subject: [mpls] RFC 4875 Notify forwarding by transit LSRs (section 8.1)

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

Hi all,

This is the second potential problem in RFC 4875 I'd like to raise.
Please let me know if this is a concern for anyone, or if I've
misunderstood something.

Section 8.1 (http://tools.ietf.org/html/rfc4875#section-8.1) defines the
rules for handling Notify messages for P2MP LSPs.  They include the
following.

-  All LSRs which change the sub-group originator ID in a Path message
need to intercept both upstream and downstream Notifies so that they can
re-write the sub-group identifiers in them then forward them on to the
original Notify requestor.  They achieve this by re-writing the Notify
node address in the NOTIFY_REQUEST object.

-  All branch LSRs which receive muliple NOTIFY_REQUESTs in Resvs on
different downstream branches need to intercept Notifies being sent
downstream, duplicate them, and send a copy to all downstream Notify
requestors.  Again, they achieve this by re-writing the Notify node
address.

As a result, Notify messages for a P2MP LSP are likely to travel via a
number of transit LSRs rather than being sent directly to the original
Notify requestor.

The purpose of the Notify message is to enable "expedited notification
of failures and other events to nodes responsible for restoring failed
LSPs" (RFC 3473 section 4).  For example, the Notify message is used by
GMPLS end-to-end protection (RFC 4872) for communicating LSP failures
between ingress and egress LSRs and co-ordinating protection switching
to a recovery LSP.

The requirement to have Notify messages forwarded by transit LSRs for
P2MP LSPs is going to make them much less useful.  For example, if an
LSR which has re-written the sub-group originator IDs fails, causing a
data plane fault in the P2MP LSP, it will be impossible to use Notifies
to quickly communicate that failure between source and leaf LSRs.

I think this is a significant degradation to the usefulness of Notify
messages that is worth addressing.  Arguably this is a wider issue that
also applies LSPs traversing NNIs between different domains, where the
border routers also intercept Notifies.  However, it may still be worth
considering a solution to just the P2MP LSP problem for now, to
facilitate the use of existing protection techniques for P2MP LSPs.

Is anyone else interested in addressing this?

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:13:17 +0100

Nic,

The problem you describe applies to many protection domain problems (such as 
segment protection).

It is solved by the concept of "nested" Notify Requesters. See RFC4873.

Adrian
----- Original Message ----- 
From: "Nic Neate" <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 07, 2008 4:32 PM
Subject: [mpls] RFC 4875 Notify forwarding by transit LSRs (section 8.1)

Hi all,

Thanks,

Nic Neate
Data Connection Ltd.

--------------------------------------------------------------------------------

---

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

Hi Adrian,

I agree that nested Notify Requesters are a good solution here, but that
does require changes to RFC 4875 along the following lines.

-  When processing a NOTIFY_REQUEST object, transit and branch LSRs MUST
NOT change the Notify node address.  Further, branch LSRs MUST forward
all NOTIFY_REQUEST objects received in Resvs from different downstream
branches.

-  Notify messages for P2MP LSPs MUST be sent to the Notify node
addresses from all NOTIFY_REQUEST objects received in Resvs, as they may
be on different downstream branches.  (This is different to the
procedures for multiple Notify Requesters in RFC 4873, which specifies
that a single Notify is sent to the address in the first NOTIFY_REQUEST
object.  Interactions with segment protection will need to be thought
through.)

-  When processing a received Notify message, the sub-group identifiers
in SENDER_TEMPLATE and FILTER_SPEC objects MUST be ignored, and MUST NOT
be used in matching the Notify to local LSP state.

Do you think a draft to formalize that would be appropriate?

Nic

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Aria - Adrian Farrel Personal
Sent: 14 July 2008 15:13
To: Nic Neate; [email-masked]
Subject: Re: [mpls] RFC 4875 Notify forwarding by transit LSRs (section
8.1)

Nic,

The problem you describe applies to many protection domain problems
(such as segment protection).

Adrian
----- Original Message -----
From: "Nic Neate" <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 07, 2008 4:32 PM
Subject: [mpls] RFC 4875 Notify forwarding by transit LSRs (section 8.1)

Hi all,

Thanks,

Nic Neate
Data Connection Ltd.

------------------------------------------------------------------------
--------