Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Wed, 5 Mar 2003 20:25:13 -0500

It seems that progress has been made on this thread in initiating a liaison process, etc.

However, a problem still not addressed is:

'problem ga': GMPLS/ASON requirements were put forward by ITU-T but did not get adequate attention/evaluation in IETF, with the unfortunate outcome that now 2 'GMPLS/ASON signaling' (RSVP-TE) standards have emerged, 'itu-gmpls' & 'ietf-gmpls', most likely with interoperability issues.

'itu-gmpls' would appear to be a 'major extension' in the context of http://www.ietf.org/internet-drafts/draft-iesg-vendor-extensions-00.txt.  As such, none of the following recommendations seem to have been followed:

"- All major extensions to IETF protocols should be done with direct involvement of the IETF
-  The decision on whether an extension is major or minor should be done with the direct involvement of the IETF
- Extensions should be done by IETF working groups using normal IETF processes
- Major extensions should be ... checked by the IETF community to be sure that the extension does not defeat safeguards designed into the protocol, such as security functions, or undermine its architectural integrity
- No individual, vendor, SDO or forum should be able to create what is viewed to be a major extension to an IETF protocol on its own and legitimately be able to claim that implementations that implement the extension are compliant to the IETF specification."

Could these recommendations now be addressed, perhaps by a team of SMEs, to evaluate/recommend a course of action?  It doesn't matter whether or not this is a formally sanctioned design-team, or a self-organized team of SME's who represent the component SDO interests, as long as a good technical solution emerges.  I've observed that a 'team' of SME's has now 'organized' on this list (on this thread), and in a sense is addressing problem ga, although they're somewhat adversarial in tone at the moment :-).  Could this energy/creativity be targeted at positive technical solutions in terms of the above recommendations?

It's unclear if this kind of problem fits within the scope of the 'problem statement' of draft-andersson-mpls-g-chng-proc, which BTW provides no 'problem statement' as the I-D itself requires.

In any case, problem ga is still there, and to me should at worst not be repeated, and at best be solved & not repeated.

Jerry Ash

---

From: Scott Bradner <[email-masked]>
Date: Wed, 5 Mar 2003 20:51:32 -0500 (EST)

> In any case, problem ga is still there, and to me should at worst not be 
> repeated , and at best be solved & not repeated.

agree

Scott

---

From: Don Fedyk <[email-masked]>
Date: Thu, 06 Mar 2003 08:48:36 -0500

Along the lines of Jerry's comments.

When we put together GMPLS the first drafts were under specified 
intentionally to capture the essence of GMPLS. We put aside many 
arguments saying lets specify at a high level and fill in the details 
later. The discussions on this thread are in two major veins one 
attempting to fill the details and the other containing and controlling 
the changes. GMPLS needs to be specified more accurately and in my 
opinion it needs to be decomposed to a more layered approach.  I think 
if we applied GMPLS at at some layers (L3/2), (L1/L0) for example,  
independently but self similar it would offer a mechanism to move 
forward where some legacy systems could be specified to be GMPLS 
friendly. For example signaling for Layer 3/2 can be tunneled through 
the a lower layer. We already have some work in this direction. 
 Similarly traffic engineering information for L1/L0 in a TE database 
 would need different  attributes than a the TE database at L3/2. I 
don't think you want to burden a L3/L2 system with these attributes in 
an overlay model. The expertise for these layer is not all contained in 
the IETF. I think we should put a plan forward to make this happen 
within the IETF process. After this was accomplished  I think some 
people are thinking of collapsing layers even more but the logical 
partitioning of layers may help keep the protocols and databases 
simpler.   Right now were are treating GMPLS like a big bowl of jelly 
when it should look more like a layer cake.

Regards,
Don