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

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Thu, 27 Feb 2003 17:19:46 -0500

agree...

I suggest the liaison process should be a separate document. And update this if it needs updating. For people outside of IETF or new to IETF, it is useful to have these process descriptions. And they are two different subjects (with common links).

For Steve, Eve, etc, I think there are two (at least) discussions on-going (1) the liaison process (which will have the "hooks" to this document and vice versa), and (2) the "what if scenario" (for non-USA, this is our new shuttle terminology): how this document relates to if an sdo (or individual) works outside this process (info rfcs). It would be good (considering the discussion level) to add some clarification text to the chng proc draft.

One option suggested by Kireeti "this is where the SDO can decide, as you point out, that it can do it on its own, but changes the name of the protocol so that innocent bystanders can tell the difference." The SDO protocol is not IETF (as this chng proc draft states) and not (G)MPLS. And as Kireeti suggested the assignments by IANA should distinguish. Another option, suggested by Steve, is that IETF should be a clearinghouse. And discussion is on-going on the interpretation of clearinghouse. 

Steve, your email may be mis-interpreted, e.g.:
"A better approach would be for the IETF to PROMOTE the use of its
protocols for new applications, and, when another Standards Development
Organization wishes to apply (G)MPLS protocols to an application domain
outside of the scope of IETF, that IETF will (1) assist with the development
of any necessary extensions; and (2) to facilitate documentation of
such new applications and extensions in a central place (e.g., by
informational RFC, even for extensions that are developed outside of
IETF) and to insure that code points are assigned in a coherent manner
through IANA to avoid collisions where different extensions may use
the same code points to indicate different things."

I don't think you are requesting IETF to simply endorse another sdo's work without review (unless the interpretation of assist=review), and I am not so sure about the promotion either. In T1X1/ITU, just at this last meeting, many have voiced concern with new applications (suggested within the group) for GFP: PON, switched layer. The concern is on extending GFP beyond what it was designed. What if another forum decided to do switched GFP? And they liaisoned to ITU to incorporate the necessary extensions? Remember the difficulties we have with IEEE 10G WAN. It calls itself SDH, but it is not SDH (as we know SDH is more than just G.707). And it is already causing confusion among the innocent. And remember "SONET Lite". Here, in IETF, they have the same concern if the name GMPLS is used. GMPLS is more than just extensions.

Some possibilities: at minimum, if IANA assignment is requested by a sdo, the name should at least distinguish it as non-IETF. And in the scope clarify it is outside of the IETF process. Or change the rfc name "informational" as it can be mis-interpreted. In ITU rec'ds, we have appendices which are informational, but they are part of the "ITU process" i.e. reviewed/agreed.

Deborah

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Thursday, February 27, 2003 11:59 AM
To: Brungard, Deborah A, ALABS
Cc: Wijnen, Bert (Bert); Kireeti Kompella; Scott W Brim;
[email-masked]; [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Deborah,

I suggested earlier that we describe (short) in the draft how we will 
handle liasions
comeing into the IETF with request for changes or requirments related to 
the (g)mpls
protocols. It needs to be understood that the internal IETF process is 
specified for
IDs, and in some way we need bridge that gap. IETF and its working 
groups modifies IDs,
and I don't think it is good idea to start modifying liasions from other 
SDOs.

That we define the liasion process so it becoes crips and clear, and if 
when we are doing
find that it has an impact on the change process, we updte or 
re-organize the the
documents at that time.

Would that work? I guess that the answer is - yes, but only as much 
(little) as needed.

/Loa

Brungard, Deborah A, ALABS wrote:

>Maybe lets go back to my hopefully simple question, will the liaison process be included in this draft or not? I (thought) the answer was no. Maybe best to clarify. And not that it is not important, all the mail agrees it is important. Then we can work from this draft with comments, recognizing the liaison process will be separate, e.g. where the draft discusses other sdos, we can add text to clarify.
>
>One comment on all of this from an ITU/T1X1 history, it is difficult to say apriori how a liaison will be processed. We do not have such a process either. Several ways exist to respond:
>1. simple thank you for the information
>2. here's the answer/clarification based on current work
>3. for a quick answer, at the meeting, have a breakout group to address a proposal
>4. for new work, send a response saying we invite contributions to our future meetings to progress
>   - if no contributions, not anything is done (yes we have done this too)
>   - at the next meeting, send several proposals to the other group for their review
>
>I had understood this draft as including option 4. Other mails are raising the concern, as in the past, if no response to the other sdo, the other sdo can not determine the status of the work. That can be part of the liaison process.
>
>Let's first clarify, do we want this draft to include the liaison process or should we do it separate (in parallel?)?
>
>Deborah
>
>
>
>-----Original Message-----
>From: Wijnen, Bert (Bert) [mailto:[email-masked]]
>Sent: Thursday, February 27, 2003 10:47 AM
>To: Kireeti Kompella; Wijnen, Bert (Bert)
>Cc: Scott W Brim; [email-masked]; [email-masked]
>Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
>
>Inline
>
>  
>
>>-----Original Message-----
>>From: Kireeti Kompella [mailto:[email-masked]]
>>Sent: donderdag 27 februari 2003 10:09
>>To: Wijnen, Bert (Bert)
>>Cc: Scott W Brim; [email-masked]; [email-masked]
>>Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>>
>>
>>Hi Bert,
>>
>>On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote:
>>
>>    
>>
>>>No of course NOT. Many Liasons will want an answer.
>>>So we need a process to follow up and to track if a timely
>>>response has been (or will be) send.
>>>      
>>>
>>Is the IETF process for replying to liaison statements (and of
>>generating them) written down, say in some RFC?  If so, could you
>>send me a pointer?
>>
>>    
>>
>Unfortunately, I don't think the process for that has been defined.
>That is why I said that "we need a process..."
>We do not have it yet (I think... at least I do not know it either).
>I think we were all just hoping people would take responsibility and
>do the right things... but as we know that is how things fall through
>the cracks.
>
>  
>
>>>But the Liasons communication between ITU and CCAMP/MPLS has not
>>>been going smoothly so far (even though we had good intentions).
>>>Responses have not gone out in time (or in some cases at all).
>>>      
>>>
>>I'll take full responsibility for that.
>>
>>    
>>
>W.r.t. CCAMP I will share some of the responsibility too. I should 
>also have kept a better eye on it.
>
>Bert
>  
>
>>Thanks,
>>Kireeti.
>>
>>    
>>
>
>
>
>
>  
>

---

From: Stephen Trowbridge <[email-masked]>
Date: Thu, 27 Feb 2003 15:57:44 -0700

Deborah,

> I don't think you are requesting IETF to simply endorse another
> sdo's work without review (unless the interpretation of assist=review),
> and I am not so sure about the promotion either.

This is not quite what I am trying to say -
Presumably the other SDO starts communication at the problem statement
phase (e.g., the Oct 2001 liaisons SG15 to ccamp). IETF is free to decide
if it makes sense for IETF to be involved in development of the solution.

If they decide not to be involved and the other SDO goes ahead with
developing their own solution, they don't need to bless the extension,
or even like it, but they do need to accept it. At this point we may
as well document it in an info RFC (not standards track for IETF) and
make sure the codepoint assignments are done in a way that avoids conflict
or overlap with other extensions.

There is another subtlety that perhaps I failed to capture in
enough detail. If the IETF does decide to be involved, their involvement
is in applying their protocol expertise in determining HOW to solve the
problem that the other SDO has raised. I am uncomfortable with a
process that leaves the IETF as the sole arbiter of WHETHER the problem
will be solved or whether the requirements developed by the other SDO
are valid. The application domain being addressed by the other SDO
may very well be different than the one being addressed by IETF, and
the validity of what the other SDO sees as their requirements for
their application domain is not for IETF to decide.

I am also a concerned with the following:
> One option suggested by Kireeti "this is where the SDO can decide,
> as you point out, that it can do it on its own, but
> changes the name of the protocol so that innocent bystanders can tell
> the difference."
This seems like a road to chaos. You end up with a proliferation of
(G)MPLS-like protocols which are all slightly different whenever there
is a requirement of another SDO that IETF doesn't accept or understand.
I think if we can come up with something more of the "clearinghouse"
flavor, we can at least keep a common umbrella over the family of
IETF and non-IETF developed extensions (based on whether IETF had
the interest or expertise to be involved in any particular extension),
to understand (as Stephen Shew pointed out) which extensions can
co-exist, to avoid conflicts, etc.

Regards,
Steve

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 27 Feb 2003 15:04:03 -0800 (PST)

Hi Steve,

On Thu, 27 Feb 2003, Stephen Trowbridge wrote:

> or even like it, but they do need to accept it.

Going back to the examples that Deborah brought up: what if other SDOs
produced variants of SDH -- would you say that the ITU "do need to
accept it"?

Kireeti.

---

From: Stephen Trowbridge <[email-masked]>
Date: Thu, 27 Feb 2003 16:18:54 -0700

Kireeti,
I'm not sure that this is the same.
IETF develops control plane technology that can control SONET/SDH
equipment used to carry physical layer connections supporting an
IP network. Presumably SONET/SDH doesn't need to change for this
application as long as virtual concatenation, etc. support the
necessary pipe sizes.

If SONET/SDH did not have what was required for this application,
I assume that IETF should first come to T1X1/ITU-T for the needed
extensions (much as ITU-T first came to IETF for the needed extensions-
remember?). If ITU-T then was not interested to help and if standardized
SONET/SDH did not meet the requirements, I suppose
that IETF would have the right to do what it needed for its
application and inform ITU-T what it had done.

ITU-T wants to apply the control plane technology to a general
purpose (not necessarily IP) transport network. In contrast to
the IP network, you have demarcation points User/Network and
between network operators for billing purposes, etc. This
leads to some new requirements (e.g., call & connection separation)
not met by the base protocol. Is it reasonable that we want to
use the (G)MPLS protocols as a base and (inside or outside of
IETF) define the minimum set of extensions to meet the requirements,
or should we just have stuck with PNNI?
Regards,
Steve

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 27 Feb 2003 18:56:41 -0500

> produced variants of SDH -- would you say that the ITU "do need to

It really becomes a practical matter.

For example, SONET scrambling was changed because the original was too
short and too easy to send an IP packet containing the entire reverse
scramble sequence leading to all same bit after scrambling, causing a
SONET framing error.  The ease of doing this was demostrated by a BBN
engineer in network operations.  Although the push came from the IETF
to change this and there was resistance it was changed when it was
obvious that customers were going to insist on the change in products,
whether or not any SDO blessed the change.

The opposite is true in the case of ITU requirements for QoS published
in the mid 1990s.  IETF didn't like it.  No one implemented.  No
customers asked for it.  End of story.

An example where the SDO didn't accept changes and the SDO became
irrelevant wrt those specs is ISIS, where nearly 100% of implemented
and deployed ISIS is according to the IETF defined extensions to ISIS
which began with rfc1195.  ISO has never quite recognized the IETF
extensions, but no one really cares much what ISO thinks about this.

A few things have been jammed through the IETF that never went any
where.  For example, guarenteed services in RSVP, NHRP (and everything
the ROLC and ION WGs did, and most of what IPATM did), QoS routing
extensions for OSPF.  The requirements documet first is a means of
insuring better quality control over what emerges from the IETF.  (Not
in terms of "to the letter perfect" documents, but useful protocols).

The emphasis on running code and rough consensus rather than study
groups and voting has worked quite well.  There is not reason to
change it or to consider a liason comment or contribution and
different from any other contribution.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 27 Feb 2003 19:52:40 -0500

> or should we just have stuck with PNNI?

Steve,

Go right a head and use PNNI.  Don't forget to run it over CLNP on a
cell based infrastructure.  :-)

Curtis

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 27 Feb 2003 18:47:35 -0800 (PST)

Hi Curtis,

> different from any other contribution.

I'm glad to hear this!

It is important, especially as this argument goes downhill fast
(starting with veiled threats and "I'm calling your bluff" responses),
to keep the big picture in mind:

a) There is a half-written, half-implicit and half-in-the-hallways
   process *for the IETF* to change IETF protocols.  It would be good
   to have more of the process written down, at least in the context of
   (G)MPLS.  The primary goal of the (G)MPLS change document is that
   this process is made known to all SDOs (including the IETF!).
b) There are often requirements from other SDOs for changes in IETF
   protocols.  *If* they choose to bring these to the IETF and have
   the IETF do the changes, it is good for them to know the process.
   If, as Steve points out, the SDO chooses to make the changes on its
   own, for whatever reason, that is beyond the scope of the (G)MPLS
   change document.
c) A liaison statement may declare the intent to follow up with the
   requirements or requests for changes in IETF protocols, but should
   not (IMO) be used to effect those changes.  A process for replying
   to (and generating) liaisons statements is needed.
d) The fundamental IETF mechanisms (though some may view them as broken)
   such as rough consensus and running code are *not* in question here.
   Those may be brought up on the general IETF list, or with the IESG
   or IAB.

Kireeti.

---

From: Yangguang Xu <[email-masked]>
Date: Fri, 28 Feb 2003 08:40:39 -0500

Curtis,

> cell based infrastructure.  :-)

Just a minor correction, it's PNNI over SSCOPMCE over anything (include IP).
Yet, I am not saying that I like it :-)

Yangguang