RE: ASON RSVP-TE extensions

["Ong, Lyndon" <LyOng@Ciena.com>]

Hi Kireeti,

The cutoff for uploading documents for the ITU meeting in
Chicago is this Monday - given the short time I wonder if 
you couldn't just submit this as a contribution from 
yourself and Ron as co-chairs of CCAMP (considering that
you were invited to participate).  I'm copying this to
Kam Lam as well for his feedback.

Cheers,

Lyndon


-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@juniper.net]
Sent: Friday, May 30, 2003 3:46 PM
To: ccamp@ops.ietf.org
Cc: Stephen Trowbridge; Wijnen, Bert; zinin@psg.com; Ronald P. Bonica;
Kireeti Kompella
Subject: ASON RSVP-TE extensions


Hi All,

We would like to send the following as a Liaison to the ITU-T from
the CCAMP WG.

Please comment on the text.  Ideally, we would like to send this out
before the interim meeting in Chicago, and discuss it there.

It would be helpful in this context to know what it means procedurally
that a document "has been consented" in the ITU.

Kireeti.
----------------------------------------------------------------------
 To: ...
 From: ...

Following up on the code point allocations in RFC 3474, we (the CCAMP
WG) seek clarification on some further points.

Regarding the following paragraph in the Introduction of the
pre-publication draft of RFC 3474 which reads:

   Note that from the perspective of the ASON model ResvErr and ResvTear
   messages are not used. For backwards compatibility, when an ASON-
   compliant GMPLS node receives either a ResvErr or ResvTear as a
   response during the setup phase of message exchange, the GMPLS-ASON
   node should instead issue a PathTear message downstream and a PathErr
   (with Path_State_Removed flag set) message upstream. This is so that
   RSVP states are immediately removed upon error during the setup
   process.

Removing this is a vital step in keeping the base semantics of the
RSVP protocol intact.  In particular, it would be unexpected and
possibly fatal if as a consequence of a node issuing a ResvErr (and
expecting the removal of Resv state alone), Path state were to be
removed as well due to the "translation" of a ResvErr to a PathErr
(with Path_State_Removed flag set) plus a PathTear.  We thank you
that you did so in RFC 3474 prior to publication.

We understand that RFC 3474 is based in part on G.7713.2.  In G.7713.2,
we see no similar paragraph.  The closest is the following, from
Appendix III Protocol Elements Not Used (p. 46), which says in part:

- ResvErr

  This message is modified from definitions in RFC 2205 and RFC 2961,
  with further extensions to support distributed connection management.
  This message is used to

  - Respond to a Resv connection setup request (when encountering problems
    with setup); however, note that in the GMPLS implementation where a
    connection setup error requires releasing the connection, and since
    ResvErr does not remove Path states, the PathTear is used for GMPLS
    connection-oriented network to remove Path states, i.e., ResvErr is
    not used during setup and release.

G.7713.2 is silent on what is to be done if an implementation were in
fact to receive a ResvErr or ResvTear message.  We believe the
Recommendation is incomplete without describing what should happen in
this event.  Is it intended that the behaviour of a node receiving a
ResvErr/ResvTear be left unspecified, or is an explicit statement is
forthcoming?

Sincerely,
Ronald Bonica and
Kireeti Kompella,
CCAMP WG chairs