RE: fatal flaw and RFC3474

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

Hi Lou,

It sounds to me as if the reverse is the case, RFC 3474 represents the
agreement between ITU and IETF on the assignment of codepoints but
G.7713.2 is now slightly out of phase because the issue was not
identified back to SG 15.

I think Kireeti did in fact bring up the issue of ResvErr treatment
at the ITU Rapporteur's meeting in Chicago, but at the time it was
not clear that this was related to the "flaw".  If the
people that brought up this issue can contribute details it can be
addressed through ITU, maybe through an amendment.

BTW, 3474 already references G.7713.2.

Cheers,

Lyndon



-----Original Message-----
From: Lou Berger [mailto:lberger@movaz.com]
Sent: Wednesday, November 12, 2003 9:05 AM
To: Wijnen, Bert (Bert)
Cc: Ccamp-wg (E-mail)
Subject: Re: fatal flaw and RFC3474


Bert,
         I think you make a good point.  While RFC3474 was positioned as 
"Documentation of IANA assignments" it is clearly more than that.   This 
leads to our current confusing state of affairs where we have to worry 
about standard GMPLS interworking with recommendation G.7713.2 as well as 
GMPLS interworking with the informational RFC 3474.  Others have made the 
point that 3474 = G.7713.2, but as you point out, this isn't the case.

Given that the only ASON signaling documents that have standards 
organization standing is G.7713.x, what do you think about working on an 
RFC update that lists assignments and ether (a) references G7713.2 and 
omits any technical discussion or (b) incorporates G7713.2 verbatim?

This will make it clear that we're focusing on G7713.2 support/interworking 
rather than on RFC3474.  Furthermore it'll clear up what document should be 
reference by the ongoing ASON support documents, i.e., G.7713.2.

Lou

At 11:35 AM 11/12/2003, Wijnen, Bert (Bert) wrote:

>I hear that I may have caused confusion with my statement
>in the ccamp session earlier this week.
>
>The "fatal flaw" was in this text in the I-D that became RFC3474
>    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.
>That text has been removed after lots of discussions. So that "fatal flaw"
>is not in RFC3464 itself. But it still exists in the ITU-T spec that this
>RFC refers to. This RFC3474 is just the "supportive document for the
>RSVP-TE assignments made by IANA". The base protocol spec is an ITU-T
>doc (G7713.2) and that was not modified (and still has not been modified
>as far as I know).
>
>My understanding was that CCAMP had send a liaison about this to ITU-RT SG15
>but I cannot find it on our ietf web page with liaison statements.
>
>So Kireeti... was it send as liaison statement or was it communicated
>otherwise. If the former, we must get it added to web pages at IETF,
>if the latter, then I wonder if it should not become a formal communication.
>
>Appology if I was not clear at the meeting.
>Bert