The MPLS WG Archive

[Lou Berger <lberger@labn.net>]

At 02:02 PM 9/29/00, Kireeti Kompella wrote:
>Sorry, I should have been following this thread, and weighed in
>earlier.  I'll attempt to summarize my position briefly; if some
>of my points are passe', forgive me.
>
>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.)

>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!)
 From draft-ashwood-generalized-mpls-signaling-00.txt:

    ... The Notify message may be sent either (a) normally,
    where non-target nodes just forward the Notify message to the target
    node, similar to ResvConf processing in [RSVP]; or (b) encapsulated
    in a new IP header who's destination is equal to the target IP
    address. ...

>4) Re IGP for failure notification: does not compute.
>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.  This scales far better than any packing scheme.

Lou

>I hope the brevity makes up a bit for the tardiness.
>Kireeti.