FW: RFC3474-to-be comments - ITU-T ASON use of RSVP

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

As we discussed tonight with some of us, this is the issue
with the ITU-T ASON use of RSVP. We approved this document
(it is now ftp://ftp.rfc-editor.org/in-notes/authors/rfc3474.txt
 which is 48-hour author call from RFC-Editor).

So I asked CCAMP and MPLS WG chairs to check it and suggest
clarifications. Then the "violation of RSVP protocol" came
up again. Kireeti describes it below, George Swallow agreed.

I then asked for contructive proposals on how to fix. No answer
sofar. I also checked with main author what he thinks. That is
the 2nd email below. 

I plan to get these people together at the SanFran IETF for
further discussion.

Thanks,
Bert 

-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@juniper.net]
Sent: zondag 2 maart 2003 5:55
To: Wijnen, Bert (Bert)
Cc: Scott Bradner (E-mail); Ron Bonica (E-mail); Loa Andersson (E-mail);
George Swallow (E-mail); Kireeti Kompella
Subject: RFC3474-to-be comments


Hi Bert,

On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote:

> Kireeti... I think you claimed this a while ago too.

It's not a matter of claiming.  It's right at the beginning of the
draft: Introduction, para 3.

> You have still to prove to me (maybe I am thick here)
> where and how that heppend. Can you point it out to me
> please.

If you haven't had a chance to read it, here is the para:

   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.

It explicitly states that ResvErr and ResvTear are not used.  It
also changes the semantics of these two messages in a fundamental
way.  It glibly states that "RSVP states are immediately removed",
without even realizing that there are separate *Path* states and *Resv*
states, and only the Path states will be removed.  Making fundamental
changes to a protocol like this without really understanding the
protocol, without consulting the experts, without doing a WG/IETF
Last Call is to my mind an unacceptable means of progressing
documents.  I understand that since RSVP doesn't officially have
IANA Considerations, the allocation of code points is FCFS.  But
that doesn't give carte blanche to change the *behaviour* of the
protocol without review.

I think that a WG Last Call would have helped to clarify the
intent and perhaps converge on a solution that doesn't require
modifying RSVP in this way, or find some other way around this.

Perhaps you think I raise this just to be difficult -- your tone
seems to indicate that.  I don't know SNMP well enough to give a
good analogy, but I'll try: If the ITU-T (or Lucent) decides that
traps are no longer needed in SNMP, and for backward compatibility,
when a trap is to be generated, a UDP message is sent to port 6543,
would you allow that to be published as an RFC without discussion?

I am very tired of fighting this battle.  All I am asking is that
these documents go through review -- not by me, but by those who
know RSVP. and by those who understand the requirements.  All I
get is grief from you -- that I am guilty until I am proven
innocent -- and that the Lucent guys are innocent until proven
guilty.  This issue has been raised multiple times, but I don't
see the authors getting grief, just me.

Do you think you are approaching this with an open mind?

Kireeti.
-----Original Message-----
From: Zhi-Wei Lin [mailto:zhiweilin@yahoo.com]
Sent: maandag 3 maart 2003 14:26
To: Wijnen, Bert (Bert)
Cc: zhiweilin@yahoo.com
Subject: Re: RFC3474-to-be


Hi Bert, 
The text does change the fundamental operation of RSVP, but it does not change the fundamental operation of GMPLS RSVP-TE. There are two fundamental changes made to GMPLS that we are simply adopting. These are: 
* The new "Path_State_Removed" flag introduced as part of an ERROR_SPEC object carried by an error message. This flag actually allows a PathErr message to change state (in GMPLS-RSVPTE). In regular RSVP only Path, Resv, PathTear, ResvTear can change state 
* The new "Admin_Status" object also describes a LSP deletion procedure in Section 7.2.1 of GMPLS-RSVPTE. In that procedure is talks of initiating a deletion procedure by setting certain bit fields within the admin_status object. 
Another "fundamental" change that has been made by GMPLS that no one talks about is the way in which a "reservation" is initiated. In RFC2205 (RSVP) a request is initiated by a downstream node. In GMPLS, a request is initiated by an upstream node. 
Yet another "fundamental" change that has been made by GMPLS to the original RSVP is the concept of separation of control from data path. RFC2205 states that the path the Resv message takes must be the reverse of the data, but in GMPLS the path that any message takes is completely orthogonal to the path of the data. 
The above shows that GMPLS is the protocol making the fundamental changes. All RFC3474 did was to re-use these changes and introduce additional procedures for ASON specific extensions. 

Yet another example of why RFC 3474 is not making "fundamental" changes. Here's a paragraph from RFC 2205 section 2.4 "Teardown":
     There are two types of RSVP teardown message, PathTear and
      ResvTear.  A PathTear message travels towards all receivers
      downstream from its point of initiation and deletes path state, as
      well as all dependent reservation state, along the way.  An
      ResvTear message deletes reservation state and travels towards all
      senders upstream from its point of initiation.  A PathTear
      (ResvTear) message may be conceptualized as a reversed-sense Path
      message (Resv message, respectively).
Note that a PathTear message not only removes the Path state but also the dependent reservation states. That's why in GMPLS, we use PathTear, or PathErr with "Path_State_Removed" flag. 
Hope this helps
Zhi
 
 "Wijnen, Bert (Bert)" <bwijnen@lucent.com> wrote: 
Zhi, only checking with you first to try and understand.

I got to handle this:

> If you haven't had a chance to read it, here is the para:
> 
> 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.
> 
> It explicitly states that ResvErr and ResvTear are not used. 
> It also changes the semantics of these two messages in a fundamental
> way. It states that "RSVP st! ates are immediately removed",
> without even realizing that there are separate *Path* states 
> and *Resv* states, and only the Path states will be removed.
> Making fundamental changes to a protocol like this without really
> understanding the protocol, without consulting the experts,
> without doing a WG/IETF Last Call is to my mind an unacceptable
> means of progressing documents. I understand that since RSVP
> doesn't officially have IANA Considerations, the allocation of
> code points is FCFS. But that doesn't give carte blanche to
> change the *behaviour* of the protocol without review.
> 

Pls do not worry about some of the pooha and not having done
WG/IETF Last Call... That is my piece to handle.

I wonder if you can see that you indeed have made a "fundamental"
change to the protocol in the way that Path and Resv states are
dealth with. Pls elaborate... assume no knowledge on my side.
Thanks,
Bert