The MPLS WG Archive

[Markus Jork <mjork@avici.com>]

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:

   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.

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