Subject: RE: Multi-LSP Notify in GMPLS

From: "Bryskin, Igor" <[email-masked]>
Date: Thu, 28 Sep 2000 16:56:14 -0400

Adrian,

I was wondering why do we need  the <sender descriptor> in the GMPLS Notify
message ? My understanding is that the Notify message is meant to notify
upstream nodes about certain events such as FIS, FRS without tearing down
the LSPs. It would be reasonable for the Notify message to have the ResvTear
like format (with FILTERSPEC list), because it will better suit the
protection/restoration schemes especially for the MPT LSPs.

Would it be better to have instead of 

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

		this

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

   <notified session> ::= <SESSION> <RSVP_HOP> <STYLE> <flow descriptor
list>
		                          [<notified session>] 
		 ?

________________________
Igor Bryskin
Chief Architect of IP Software,
VIRATA Corporation,
65 Boston Post Road, suite 106,
Marlborough, MA, USA,
Tel: (508)-786-1920, ext. 103

		-----Original Message-----
		From:	Adrian Farrel [mailto:[email-masked]]
		Sent:	Wednesday, September 27, 2000 5:40 PM
		To:	[email-masked]
		Cc:	'Lou Berger'; Kireeti Kompella (E-mail); Yakov
Rekhter (E-mail); Ayan Banerjee; Jonathan Lang; [email-masked]; Peter
Ashwood-Smith
		Subject:	Multi-LSP Notify in GMPLS

		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: Adrian Farrel <[email-masked]>
Date: Fri, 29 Sep 2000 12:58:15 +0100

>> >>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 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.)
>>
>>Not my intention (except with consent of the LSRs involved).
>>see my response to Markus.
>
>The exception is surprising.  Why would you want to remove 
>base (rfc2205 specified) error messages?

If there is no value in sending them.

In some circumstances, the Notify obsoletes the PathErr.

You would send one PathErr for each failed LSP and process it hop-by-hop.
This is excessive, especially when a large number of LSPs fail.

If a multi-LSP Notify flows it can replace the need for the PathErr.

If the Notify is targeted at a non-ingress repair point, we would have to
change the rules for PathErr processing to achieve the same function (o/w
the PathErr would be forwarded all the way to the ingress where it might
produce a different effect).

My suggestion is that the node requesting Notify is able to say whether it
wants the node that generates the Notify to use PathErr or not.

Adrian

---

From: John Drake <[email-masked]>
Date: Fri, 29 Sep 2000 08:13:26 -0700

Another point.  With link bundling, a significant number of component links
might fail without causing an IGP flooding event.

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]]
Sent: Friday, September 29, 2000 6:15 AM
To: Markus Jork
Cc: Jonathan Lang; 'Lou Berger'; [email-masked]; Adrian Farrel
Subject: Re: Multi-LSP Notify in GMPLS 

In message <[email-masked]>, Markus Jork
writes:
> Jonathan,
> 
> > Lou,
> >   As we've discussed before, latency is clearly an issue.  Imagine a
fiber
> > cut where 80+ wavelengths are affected...
> >   Why would you want intermediate nodes processing messages that aren't
> > intended for them?
> > 
> > -Jonathan
> 
> I thought I gave an answer to this question in my original message...
> That's just how RSVP works and on what it bases its authentication
> mechanism.
> 
> Markus

Both happen.  RSVP tears go out and the IGP advertises the loss of an
adjacency.

The hierarchy of tunnels can have an impact on restoration.  In the
optical domain, if the lambdas are in use a number of LSC tunnels have
been set up and over these a number of PSC-1 tunnels have been set up.

The 80+ RSVP tear messages go to the ingress of those tunnels and the
IGP advertisement goes out to declare the LSC hop down.  If there is
restoration in the optical domain, at the ingress or at any midpoint,
the LSC tunnels remain up.  Any PSC tunnels that use the LSC tunnels
rather than rely on the optical hop by hop are unaffected.

If there is no restoration in the optical domain, the PSC-1 tunnel may
provide restoration through some means such as having a backup path.
Alternately the PSC tunnel may reroute at the time of failure if the
(rather long by SONET standards) restoration time of this method is
acceptable to the traffic that is tunneled through it.

If the PSC-1 tunnel can be restored the tunnels that go through it are
unaffected.

By unaffected here I hean that no rerouting occurred at that level in
the hierarchy (for example a PSC-2 tunnel was not rerouted).  Some
loss occurred if a fiber was cut and restored no matter how it gets
restored.

The last thing you want to happen is to notify each of the thousands
of MPLS edge to edge tunnels that go through those 80+ fibers.  The
lower down in the hierarchy that the restoration occurs the better.
Ideally it impacts 80+ tunnels and no more.  The Notify doesn't really
help much because optimizing at that level misses the point.

Curtis

---

From: Jonathan Lang <[email-masked]>
Date: Fri, 29 Sep 2000 11:45:36 -0700

Lou,
  To clarify, it is not our intent to have the Notify message replace the
PathError message.

-Jonathan

> From: Lou Berger [mailto:[email-masked]]
> Sent: Friday, September 29, 2000 4:40 AM
> To: Adrian Farrel
> Cc: Lou Berger; [email-masked]
> Subject: RE: Multi-LSP Notify in GMPLS 
> 
> 
> At 05:51 AM 9/29/00, Adrian Farrel wrote:
> Lou

---

From: "Peter Ashwood-Smith" <[email-masked]>
Date: Fri, 29 Sep 2000 19:26:00 -0500

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

	I'm running a few days late on my email ... sigh ... but I would not
disagree with the removal of the Notify either. 

	Peter

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 29 Sep 2000 17:45:14 -0700 (PDT)

Hi Lou,

> >1) Re Notify direct to the failure handling LSR (or head-end) vs.
> >    hop-by-hop: definitely direct.  The difference in speed between
> >    hardware forwarding and software looking at the packets is huge.
> 
> We've been here before.  I don't mind if it goes away, but clearly the 
> majority of the authors wanted it in the first place and want to keep 
> it.  So it stays.  (Unless the WG says otherwise.)

Good.

> >2) Re Notify superceding the need for PathErr: No.  Send both.
> >    Even if the PathErr is redundant -- what's the cost?
> >3) Re intermediate LSRs processing the Notify even if router alert
> >    is not set: allow double IP encaps, but make it a MAY (NOT a
> >    MUST or a SHOULD) (i.e., agree with Adrian here).
> 
> This *is* what the original version said.  (Geeze, you should read your own 
> document!)

I'm not arguing what the original version said.  I'm stating my
position in the context of the current debate.  (Geeze, I thought
writing drafts was enough -- now you're asking me to read them? :-))

> >5) Re Multiple LSPs in a Notify: definitely (Adrian's restrictions
> >    seem reasonable).
> 
> Why is this something that needs to be optimized.  In the n LSPs / fiber 
> breakage case it makes more sense to send a notify for a single LSP with an 
> error code indicating a link failure and have the target of the Notify 
> message correlate the error with other LSPs going through the same 
> link.

I think that that is a lot of work for the target -- if there are
loose hops in the LSPs, there may not even be enough info to correlate
LSPs with links.  Whereas for the node sending the Notify, it is easy
to conjure up a list of LSPs that failed.

Kireeti.