The MPLS WG Archive

[Adrian Farrel <AF@dataconnection.com>]

Markus,

>it seems to me the invention of the Notify message in GMPLS was not
>such a great idea.

Jonathan has responded as to why he sees the Notify as useful.

!  You are correct that you don't have agreement with your 
!co-authors on removing the Notify.  The Notify message is a
!new general notification procedure that is NOT restricted to
!be sent to a source/destination node and should not be 
!processed by intermediate nodes.  These features are
!desirable for restoration/protection among other things.

I believe that there was some concern that Notify should flow
direct to the target not only for speed,  but also to 
circumvent possible breaks in the route of the LSP (which you 
obviously can't do if you follow the LSP hop by hop).  This
would, however, be handling a second order error.

A more important point is hidden in Jonathan's answer.  The 
intent is to allow (through suitable signaling) the Notify to
be targeted at other than the initiator/responder of the LSP.
See a separate thread for a some draft text on this subject.

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

Wrt authentication, you are right that some attention should
be given in the draft if Notify is allowed to go anyway other
than hop by hop along the LSP's route.  This is a hole already
opened by RFC2745 (Diagnostic Messages) although it could be
argued that Notify is a more dangerous message than DRep.

As with DRep, it should be possible to disable support for
Notify on any individual LSP if security is deemed to be at 
risk.  However, in private optical networks I suspect that
security is not considered to be threatened and that 
authentication is seldom if ever used.

>There is also no discussion of backwards compatibility.

I have addressed this somewhat in the thread on Control of Notify
target (q.v.).  It is certainly not my intention to break backwards
compatibility (although it is worth noting that much of GMPLS
struggles to work except where all participating LSRs have the same
level of function).

I intended that 
- LSRs that cannot send Notify will send PathErr etc.
- LERs that cannot receiver Notify will not request it (and may
  expect PathErr etc.)
- If a Notify goes un-Ack'ed an LSR should revert to PathErr.
- An LSR sending Notify may optionally also send PathErr.
(but I didn't write much of it down!)

>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 signaling at all!

Covered above, but also consider the transit node that is 
bye-passed by the Notify and doesn't see a PathErr.  In this case
there will either be a PathTear or the fragment of LSP will be 
re-used in a resignaled LSP (or possibly left to time out).

Regards,
Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422