Subject: Multi-LSP Notify in GMPLS

From: Adrian Farrel <[email-masked]>
Date: Wed, 27 Sep 2000 22:40:23 +0100

Lou, Peter, et al.

I have been talking with John Drake, Jonathan Lang, Ayan Banerjee and
(briefly) Yakov Rekhter about whether it is correct to apply bundling to the
Notify message or whether there are other optimizations that can be made.

The case we were considering involved the failure of a single link or node
that impacted very many LSPs where potentially large numbers need to be
notified to the same target.  The current version of the draft requires that
a single Notify message is built for each failed LSP, but allows these to be
bundled together for dispatch to a common target.

Building on the Summary Refresh construct in
draft-ietf-rsvp-refresh-reduction, I am proposing a solution where a single
Notify carries information about more than one failed LSP.  The restrictions
are
- all LSPs reported on one Notify must be for the same Notify target
- the same error spec must apply to all LSPs reported on the same Notify

Using this approach there is a saving of at least 40% in line usage compared
with bundling.  There are also definite advantages in terms of buffer usage
in a normal implementation.

Note that none of this predicates against "Non-Adjacent Message Bundling"
which could still be used with this form of Notify message.

I have taken the liberty of redrafting section 5 of the draft and tidying
some of the wording as I went along.  I would welcome your comments.

Regards,
Adrian

5. Notification

   This section defines a signaling extension, the Notify message, that
   enables expedited notification of failures and other events to nodes
   responsible for restoring failed LSPs.  This extension is RSVP
   specific although similar extensions could be defined for CR-LDP.

5.1. Notify Message

   The Notify message provides a mechanism to inform non-adjacent nodes
   of LSP related events.  This message differs from the currently
   defined error messages (i.e., PathErr and ResvErr messages of RSVP)
   in that it can be "targeted" to a node other than the immediate
   upstream or downstream neighbor and that it is a generalized
   notification mechanism.  In particular, the Notify message does not
   need to follow the hop-by-hop route of the Path since this may be
   inappropriate in cases of link failure.

   The Notify message does not replace existing error messages, but may
   initially be sent instead of existing error messages where the intent
   is that the Notify recipient should take remedial action before the
   network has recourse to the normal error processing.

   The Notify message is sent addressed to the target node without the
   router alert option (see 5.1.1).  This means that at transit nodes
   the IP packet may be forwarded by IP without being passed to the
   RSVP protocol code.  If a Notify is passed to the RSVP protocol code
   on a node which is not the destination of the Notify message, that
   node MUST forward the message, unmodified, towards the target.
   If it is known or suspected that the transit nodes will unnecessarily
   intercept Notify messages, they MAY be sent encapsulated in a second
   IP header.

   A Notify message may inform the destination of the an event on
   multiple LSPs.  This is achieved using a technique similar to the
   Summary Refresh in [RSVP-RR].

   To support reliable delivery of the Notify message, an Ack Message
   [RSVP-RR] is used to acknowledge the receipt of a Notify Message.  A
   node that receives the a Notify message MUST send an Ack message
   confirming receipt of the Notify message.

   Note: for CR-LDP there is not currently a similar mechanism. In CR-
   LDP, when a failure is detected it will be propagated with
   RELEASE/WITHDRAW messages radially outward from the point of failure.
   Resources are to be released in this phase and actual resource
   information is fed back to the source using the feedback mechanisms
   of [FEEDBACK].  In this manner the source will have an accurate view
   of available resources and can start rerouting much sooner.

5.1.1. Required Information

   The Notify message is a generalized notification message.  The IP
   destination address is set to the IP address of the intended
   receiver.  The Notify message is sent without the router alert
   option.

   <Notify message> ::= <Common Header> [<INTEGRITY>] <MESSAGE_ID>
                        <ERROR_SPEC> <notified session>

   <notified session> ::= <SESSION> [<sender descriptor>]
                          [<notified session>]

   <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
                           [<ADSPEC>] [<RECORD ROUTE>]

   The INTEGRITY object would normally be omitted since it provides hop-
   by-hop validation which is not appropriate for a multi-hop message.
   Compare with the ResvConf message which must be processed at each hop
   along its path.

   The MESSAGE_ID object is mandatory. All LSRs implementing support for
   Notify messages must also include support for this object and the
   Ack message.  The MESSAGE_ID object is defined in [RSVP-RR].

   The ERROR_SPEC object specifies the error and includes the IP address
   of either the node that detected the error or the link that has
   failed.  The error reported applies equally to all LSPs reported on
   the same Notify message.  See ERROR_SPEC definition in RFC2205.

--
Adrian Farrel  mailto:[email-masked]
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 27 Sep 2000 22:08:18 -0400

In message <[email-masked]>, Adrian F
> bundled together for dispatch to a common target.

It would be much better to flood the loss of the adjacency and let the
various ingress each figure out that the LSPs that relied on that
adjacency have to be rerouted.  If down transitions are flooded
immediately and only IGP up transitions delayed, then this works fine.

[aside: One of the neat things about layer-2 style bundling is that
you don't lose any LSPs, you just lose aggregate capacity on the
bundle.  If you are tight and reducing max-reservable puts you over
the limit, then preemption kicks in and the least favorite (highest
numeric holding priority) get kicked out first.  If you configured for
overbooking no LSPs are kicked out, no RESV TEARs at all are needed,
and a good adaptivity implementation will cause LSPs to move in
make-before-break fashion if the reservable bandwidth is at an
uncomfortable level.]

> - the same error spec must apply to all LSPs reported on the same Notify

Sounds worthwhile.

>    intercept Notify messages, they MAY be sent encapsulated in a second

It was pointed out earlier that routers can capture and examine RSVP
regardless of whether router alert is set.  [Maybe good advice would
be "if it hurts, don't do that".]

Curtis

---

From: Markus Jork <[email-masked]>
Date: Thu, 28 Sep 2000 12:01:47 -0400

Adrian,

it seems to me the invention of the Notify message in GMPLS was not
such a great idea. It's only purpose is to reduce the latency of
error message delivery back to the LSP ingress. So instead of the
slow path forwarding of the PathErr message by the router software
you now get fast path forwarding of the Notify message by the router
hardware.
Does this gain justify the circumvention of RSVP's authentication
mechanism (RFC 2747)? RSVP security is based on message authentication
between neighbors but the Notify message is not send hop-by-hop
through neighboring routers that are configured to trust each other.
You now also point this out in your rewrite of section 5.1.1.

There is also no discussion of backwards compatibility.
In your modified version of section 5, you write:

Because the Notify message is sent instead of a regular PathErr
message, a node that receives the Notify but does not support it
will not get any error indication from RSVP signalling at all!

I suggest to remove the Notify message from the GMPLS draft.
If not, the "Security Considerations" section needs to be updated:
the Notify message *does* introduce new security issues.

Markus

---

From: Lou Berger <[email-masked]>
Date: Thu, 28 Sep 2000 12:26:10 -0400

See below.

>will not get any error indication from RSVP signalling at all!

I think it's worth pointing out that Adrian's version differs from the most 
recent draft, which says "The Notify message does not replace existing 
error messages. "  I think any attempt to replace base RSVP messages with a 
notify would be misguided.  I don't know if this is what Adrian meant to 
imply.  (Although this is one reading of the his text.)

>I suggest to remove the Notify message from the GMPLS draft.

This would be fine with me particularly since a PathErr message doesn't 
modify state.  (I'm sure some of my co-authors will disagree with me on 
dropping it.)

Lou