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

From: Stephen Trowbridge <[email-masked]>
Date: Mon, 03 Mar 2003 09:30:29 -0700

Loa,
(snip)
> I don't discus liasions, simply because it
> was and is
> my opinion that they are not in the picture then it comes to handling
> changes to the
> (g)mpls protocols.
So, if another SDO thinks that an IETF protocol (possibly with extensions)
would be a good solution to their problem, they would ask for this how?
Regards,
Steve

---

From: Scott Bradner <[email-masked]>
Date: Mon, 3 Mar 2003 11:48:58 -0500 (EST)

Steve,
	Note that Loa is correct as to the impact of liasions, I-Ds
or presentations by folk representing otehr SDOs within the IETF
standards process - they carry just as much weight as the statemnts
of any individual and there is currently no reason to have them
treated as having some special status in the change-process ID.
(see RFC 3356 sec 3.2.2 & RFC 2418 sec 1))  That said, I do think it would be 
good to mention that the use of liasion statements is common in other
SDOs and that such statements should be not ignored when directed to
IETF working groups.

	There are strong arguments that maybe the current assumptions
should change butthis mailing list is not the place to discuss it - I 
would suggest that this dicussion be redirected to the problem-statement 
mailing list.

Scott

---

From: Stephen Trowbridge <[email-masked]>
Date: Mon, 03 Mar 2003 10:10:45 -0700

Scott,
There is no doubt that liaisons CURRENTLY have no more wieght than
individual IDs (perhaps even less - by the Bala flowchart, the fact
that an idea arrives via liaion may even work to the detriment of
a proposal (yes Loa, I know this is a joke!)).
But it is my opinion that the lack of a liaison process is really
the ROOT CAUSE of difficulties like what we saw in January.

There are some on this thread who seem to feel that the root cause
of the problem is that ITU-T is permitted to use or apply the IETF
protocol to their problem at all.

But I daresay that if we had had a good back-and-forth discussion
between the groups (with liaisons not only being considered seriously,
but responded to), that people would have understood far better what
the ITU-T was trying to do, and that there would not have been the
last minute arguments about whether ITU-T should be able to do it.

I have remarked on this before: some of our members (in ITU-T) are
interested in using the PNNI protcol to implement ASON instead of
the GMPLS protocols. The PNNI protocol also required extensions - it
did not meet the ASON requirements as-is.

I think that the primary reason that the job was so much easier with
PNNI and the ATM forum is not so much that PNNI is any better suited
to solving the problem, but that ATM forum took the liaison statements
seriously. They tried to understand the ITU-T problem and actively
tried to help solve it in the best way with their protocol.

If IETF ccamp had done the same (all the way back to Oct. 2001), the
arguments of January would never have happened.
Regards,
Steve

---

From: Scott W Brim <[email-masked]>
Date: Mon, 3 Mar 2003 12:11:01 -0500

> would suggest that this dicussion be redirected to the problem-statement 

Or a new one (I hope).  Problem-statement deserves not to be de-focused.

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 03 Mar 2003 13:49:02 -0500

Steve,

They would bring the topic up on the appropriate WG mailing list and
submit an internet-draft.

Your prior example of ASON is analogous IETF creating document that
change the underlying SONET model and creating extensions to SONET
outside of ITU (for example: using the loosely defined or undefined
portion of the SONET overhead) specificly to support IP and then
claiming that it was for IP so ITU should just accept it without
questioning it.  There is no reason for the IETF to accept ASON as a
requirement for MPLS/GMPLS.

Curtis

---

From: Stephen Trowbridge <[email-masked]>
Date: Mon, 03 Mar 2003 12:24:00 -0700

Curtis,
I think you are missing my point.

IETF has one set of requirements for the kinds of networks that they
envision and are within their charter. They develop an architecture and
protocol solutions to support those requirements.
ITU-T has an (overlapping but different) set of requirements for the
kinds of networks they envision (including lots of TDM & WDM traffic
that doesn't necessarily carry IP, etc.).
Nobody says that the additional ITU-T requirements are valid for
the IETF application, or that IETF must solve the ITU-T requirements
with IETF developed protocols (they can choose to, but there is no obligation).

When the ITU-T brings these requirements to the IETF's attention, there
are a variety of perfectly reasonable responses:
- The IETF can say "That requirement is important for us also, let's work
  toward a common solution".
- The IETF can say "That requirement is not important for the IETF scope
  of work, but we can see how it is important for yours. From our
  experience with the protocol and our desire for sanity in the protocol
  and all of its extensions, we can offer you the following advice about
  how the protocol can best solve your problem ..."
- The IETF can say "That requirement is not important for the IETF scope
  of work and we are not particularly interested in helping with a solution -
  you are on your own, but please assign any protocol codepoints through
  IANA and document your extensions as an info RFC so that we can prevent
  any conflict with other extensions.
They could EVEN say "We think you might have misunderstood the requirements:
do you think that the following restatement of the problem would allow your
needs to be met with the current protocols: ..."

But the answer that I would have trouble with would be the IETF saying "That
requirement is not important for the IETF scope of work, and therefore no
solution should be developed for your problem AT ALL. After all, if it is not
important for IETF, it must be irrelevant for everybody."

Of course, without a liaison process, I don't know how we get any of these
responses. Incoming liaisons seem to hit the dustbin before they get serious
consideration regarding which of the above response types might be most
appropriate.
Regards,
Steve

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 03 Mar 2003 15:05:19 -0500

Steve,

Lets consider what the IETF should do if it were 1985-1995 again and
the ITU or ATM Forum (1993 on) or Telco research personnel came to the
IETF and told them that connectionless protocols will never be
successful because there is no way to charge for them on a per packet
basis.  Should the IETF have changed the underlying IP model to be a
stateful connection oriented network and provide the AAA that ITU et
al insisted were absolute requirements.

Lets also consider what the IETF did do.  The IETF quietly ignored
those "outside requirements".  No official response came out of the
IESG or IETF.  No liason statement was sent to ITU.  The IETF simply
continued to go about their business ignoring an ITU requirement that
they collectively felt had no merit.

The IETF did not undertake a "connection oriented extension or
alternate transport to IP" in the 1990s.

I believe the same treatment would be appropriate for ASON today.  The
response "we do not agree with those requirements" would have been
entirely appropriate in the mid 1990s and is entirely appropriate now.

Curtis

---

From: Zhi-Wei Lin <[email-masked]>
Date: Mon, 03 Mar 2003 19:08:12 -0500

Hi Kireeti,

Just responding to your point (e) below. As someone pointed out in some
previous email exchanges (seems like an age ago), when I submitted my I-D
around the June timeframe, the IETF CCAMP WG were not particularly
interested. However, I did work with and gotten quite good feedback
privately. Among the folks were Adrian, Jerry, Dimitrios, Dimitri, Nick,
Greg, Lyndon, Bala, Yangguang. Of course not everyone agreed with some of
the particular solution but I don't think anyone questioned that there were
technical issues with it...

And also as someone pointed out, many of the critical players in the GMPLS
arena were also players in the OIF. I think the root cause is maybe not the
liaison process but the intent of people working in the topic area? Just a
guess...

Thanks
Zhi

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Kireeti
> Kompella
> Sent: Monday, March 03, 2003 5:26 PM
> To: Stephen Trowbridge
> Cc: [email-masked]; [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
>
> Hi Steve,
>
> On Mon, 3 Mar 2003, Stephen Trowbridge wrote:
>
> > individual IDs
> This might be a fundamental difference between the IETF and
> other SDOs,
> the ITU in particular.  However, that still doesn't mean that this
> policy of the IETF's is wrong.  I happen to think that taking
> everything
> at its own merit rather than considering where it came from
> is the most
> democratic, equal opportunity means of handling it -- but that's a
> personal philosophy, not necessarily echoed by the IETF.
>
> That said, if liaisons truly have lower priority than individual IDs,
> it is more the vehicle (emails, notes posted to the liaison web page,
> etc.) than the source or the content.  One the advice of a
> wise person,
> I have started (belatedly) posting to the CCAMP list that
> such liaisons
> exist.  Note that I don't need to do that for IDs -- the
> authors generally
> do that, and there is a mailing list that one can subscribe for this.
>
> If we really do a root cause analysis, it comes down to this (IMO):
> a) CCAMP gets a liaison statement stating that certain changes are
>    requested in the GMPLS specs (doesn't get posted to the
> list, though).
> b) CCAMP doesn't officially respond (mechanisms not in place).
> c) CCAMP WG gets requirements via Zhi's and Osama's drafts.
> d) CCAMP mailing list hosts discussions about whether these
> requirements
>    make sense in the IETF context.
> e) In the interest of quick allocation of code points, these two docs
>    are made Informational, and go through without much review.
> f) Various folks (CCAMP, RSVP, MPLS, ...) are very concerned about the
>    changes made to RSVP and CR-LDP.
>
> (The intent here is not to point fingers, although I've
> already claimed
> my share of the blame.)
>
> I see (b) and (e) as the most serious breakdowns in the process.  The
> GMPLS change doc should help alleviate (e), and hopefully help (a) as
> well.  And if we get started on the liaison doc, that should help (b).
>
> Or we could keep talking :-)
>
> Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 3 Mar 2003 14:26:06 -0800 (PST)

Hi Steve,

> There is no doubt that liaisons CURRENTLY have no more wieght than

This might be a fundamental difference between the IETF and other SDOs,
the ITU in particular.  However, that still doesn't mean that this
policy of the IETF's is wrong.  I happen to think that taking everything
at its own merit rather than considering where it came from is the most
democratic, equal opportunity means of handling it -- but that's a
personal philosophy, not necessarily echoed by the IETF.

That said, if liaisons truly have lower priority than individual IDs,
it is more the vehicle (emails, notes posted to the liaison web page,
etc.) than the source or the content.  One the advice of a wise person,
I have started (belatedly) posting to the CCAMP list that such liaisons
exist.  Note that I don't need to do that for IDs -- the authors generally
do that, and there is a mailing list that one can subscribe for this.

   requested in the GMPLS specs (doesn't get posted to the list, though).
d) CCAMP mailing list hosts discussions about whether these requirements

(The intent here is not to point fingers, although I've already claimed
my share of the blame.)

Kireeti.

---

From: [email-masked]
Date: Tue, 04 Mar 2003 12:06:06 +0100

zhi,

let's be very clear here, intent was to gather feedback
from the ccamp community during the yokohama meeting, i
have to say that the achieved consensus (as previously
explained was more than satisfactory imho) when you have
decided to go on the info track it has been based on the
expectation to get code points on time, now that you have
received them, i more than strongly suggest that you put 
this document over the table and that we discuss it... at 
the end i've got the impression that you don't want to 
discuss it at all anymore... is there something to hide 
here ?

ps: some of the critical oif players you refer in your
below e-mail are seriously questioning what has been done
over time ... and from this perspective only implementation
will decide about the relevance of these extensions

thanks,
- dimitri.

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

---

From: Yangguang Xu <[email-masked]>
Date: Tue, 04 Mar 2003 08:18:07 -0500

Dimitri,

> will decide about the relevance of these extensions

FYI, I've been writing code for all the time when you are talking... 

Yangguang

---

From: [email-masked]
Date: Tue, 04 Mar 2003 15:38:32 +0100

as from our side we are done with the oif stuff, 
we've took the time to make some charts explaining
some of the issues related to this implementation
agreement (just to be sure that the next version 
will be more easy to develop)

http://psg.com/~dpapadimitriou/slides02.ppt

---

From: Yangguang Xu <[email-masked]>
Date: Tue, 04 Mar 2003 09:46:17 -0500

You don't get it, do you?

BTW, this is IETF. I was talking about IETF stuff.

---

From: Stephen Trowbridge <[email-masked]>
Date: Mon, 03 Mar 2003 15:57:38 -0700

Kireeti,

snip
> do that, and there is a mailing list that one can subscribe for this.
I saw this, and I think it is definitely a step in the right direction. Thanks!

>    requested in the GMPLS specs (doesn't get posted to the list, though).
Perhaps we didn't get an email out the instant something appeared in
http://www.ietf.org/IESG/liaison.html, but I think that (at least for
liaisons to ccamp from ITU-T SG15 since Oct. 2001) there was always
an email from the presenter (Wesam or myself) at the occasion of the
next IETF meeting with reminders about the location of the liaison information
and the slides presented in the meeting to explain them. So within a
window of time, I think all incoming liaisons were advertised.

> well.  And if we get started on the liaison doc, that should help (b).
Personally, I think that if we had done a good job at getting the bi-
directional communication channel going at (b), we wouldn't have run
into problems at (e). Either ccamp would have been actively involved in
producing the solution, or people would have understood the reasons
why it was being done outside and been OK with it at (e).

What happened at (e) was a step to try to unblock some ITU-T work that
was stuck because we didn't get the right communication to happen at (b).
I think what some of us worry about here is that if we remove the flexibility
we had at (e) without fixing the communication problem at (b), then IETF
ends up (intentionally or unintentionally, depending on who in this thread
you believe) putting up roadblocks to the progress in other organizations.
This is why we feel that the liaison process has to be either a prerequisite
(or a co-requisite) of the change control process.

> Or we could keep talking :-)
I'm sure we'll do this anyway ...

Regards,
Steve

---

From: [email-masked]
Date: Tue, 04 Mar 2003 16:00:42 +0100

true, i took a look at

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-signaling-survey-03.txt

and i don't get you as well !

---

From: Alex Zinin <[email-masked]>
Date: Tue, 4 Mar 2003 12:38:49 -0800

<regular ietf'er hat on>

> personal philosophy, not necessarily echoed by the IETF.

Bingo!

It seems to me that this is the only way to ensure fairness in the
IETF, actually. Once we start introducing any sorts of preferences or
"weights", it may become a too attractive backdoor around the IETF
process.

Also, what does "weight" of a liaison or an ID really mean in a
_consensus_ based organization? That we should suddenly have a worm
and fuzzy feeling about that doc? And how does this "weight" compare
to, for example, the weight of the consensus within the IETF to not do
what's proposed, if that happens?

Alex