The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <6DEA508A9A0ED31192E80000F6CC176E2CA2DF@monk.datcon.co.uk>, Adrian F
arrel writes:
> 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.


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


> 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


Sounds worthwhile.


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


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