The MPLS WG Archive

[Kireeti Kompella <kireeti@juniper.net>]

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.