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

From: John Drake <[email-masked]>
Date: Thu, 27 Feb 2003 17:50:27 -0800

Snipped...

> 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?)

JD:  I'm assuming that in your worldview that the Yokohama CCAMP meeting
never happened?

> 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?

JD:  Is that a threat or a promise?  BTW, call & connection separation
doesn't exist in PNNI either, at least up to the point that I stopped
attending the ATM Forum.

---

From: Stephen Trowbridge <[email-masked]>
Date: Fri, 28 Feb 2003 07:21:33 -0700

John,

> doesn't exist in PNNI either, at least up to the point that I stopped
Interesting that you should mention this.

We sent liaisons to the ATM forum, just as we did to IETF ccamp.
The reaction we got from the ATM forum was a great deal of help to
extend the PNNI protocols to meet our requirements. They provided
us numerous, helpful comments all through the process of development
of G.7713.1.

What we got from IETF ccamp was ignored (until we finally did the
work somewhere else and tried to get code points assigned).

We seem to have different understandings of what the problem is that
needs to be solved. My belief is that the problem is that we don't
have a good process for dealing with liaisons in IETF, and this
inhibits the kinds of productive relationships between IETF and other
SDOs that exist between many other (non-IETF) SDOs.

Some others on this thread seem to think that the problem is those
other pesky SDOs: after all, how could there possibly be a valid
problem statement or requirement that wasn't conceived of and developed
entirely within IETF? Every possible measure should be taken to
prevent that any work is done to address such requirements.

What is your perception of the problem?
Steve

---

From: [email-masked]
Date: Fri, 28 Feb 2003 15:45:16 +0100

stephen

i am resending you the e-mail sent to john because
i am not sure you have red it "> What we got from 
IETF ccamp was ignored (until we finally did the
work somewhere else and tried to get code points 
assigned)."

---
1) in order to initiate an action a clear under
standing of the problem must be achieved by the 
ccamp wg community in order to make this happen 

2) expect that ietf community would understand 
the terminology used in g.8080 (and subsequently
the issue) by sending a liaison was probably 
a bit too optimistic -> thus the idea was to
initiate a sort of "decoder ring" (just to be sure
that when we say a "table" we are all in common
agreement on what a table is)

3) instead of request changes to gmpls it would 
have been much more constructive to know really 
what are the architectural aspects covered by 
itu that are the key in enabling signalling for 
optical networks -> from that *clear* perspective 
the ccamp wg was expecting a "functional spec" 
i-d ... since the idea here was to understand 
the functional requirement outside of any specific
signalling protocol (thus make abstraction of 
what was included in g.7713.x in a first phase)

4) once terminology + functional aspects would
have been understood by the ccamp wg deliver the 
right answer using the ccamp community tools and
protocols
---

last it is not the ccamp wg consensus that has
pushed itu editors to go to the info track ...

thanks,
- dimiti.

-- 
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: [email-masked]
Date: Fri, 28 Feb 2003 16:03:07 +0100

john,

i worry about the fundamental reasons behind "I'm 
assuming that in your worldview that the Yokohama 
CCAMP meeting never happened?" which is for me 
a very sensible and relevant point

because it means imho that independently of the 
real quality and level of details of the (future)
liaison process, clearly there are some "centrifuge" 
forces that tends to discourage a good collaboration 
(meaning is there somewhere reasons and interest 
in not making this happening - why ?), consensus
made during this yokohama meeting was unformal and
had been overridden thus why the formal one would
work better and preclude such situations to happen
once again ? since at the end of the day people 
behind the process make the decision (and since 
we speak about the same group of people...)

in a sense the yokohama meeting is not just about it
went to an info track ... it is to know *which* were
the technical and non-technical reasons for the i-d
editors in deciding to go the info track and not 
working in the scope of the working group ? 

as long as this question is not solved i really
worry about the real intent behind the current 
thread.

thanks,
- dimitri.

---

From: Stephen Trowbridge <[email-masked]>
Date: Fri, 28 Feb 2003 08:17:41 -0700

Dimitri,
I have to respond in the same flavor that I responded to John.

Why is it that when we send the same type of request to ATM
forum, the result is that they spend effort to try to understand
the problem we are trying to solve and provide a great deal
of helpful input directed at solving the problem we have raised?
They have been genuinely interested in trying to figure out how
their protocol can be applied and extended to solve our problem.

You mention needing a "decoder ring" to decipher G.8080 terminology,
yet this terminology is certainly as foreign to ATM forum as it
would be to ccamp (perhaps even moreso, since I think there is
far more overlap in attendance between ITU-T SG15 and ccamp than
there is between ITU-T SG15 and ATM forum). Yet ATM forum had no
difficulty to understand what we were trying to do and to help us
to develop the solution.

I do not think that this is because people in the ATM forum are
so much more intelligent than those in ccamp: in fact, many people
I have met in ccamp are absolutely brilliant. So if it is not the
ability of the people that prevents this kind of productive work,
I have to believe it is a shortcoming of the process.

IETF stands nearly alone in the community of International standards
development organizations in not taking incoming liaisons as a
very serious input. It is only recently that we even had a place
to post incoming liaisons for IETF (http://www.ietf.org/IESG/liaison.html).
Now it is important to develop a process to make sure that those liaisons
are considered.

In addition, IETF needs to be able to generate liaison statements
in order to effectively influence the work of other SDOs. IETF has
historically taken the view that they don't need to send anybody
anything because any information related to IETF can be found
on their web site or seen on the mailing list. But as a practical
matter, for most SDOs, input documents include contributions from
members, documents (like agendas and reports) prepared by those with
official positions, and LIAISON STATEMENTS. Surely you don't expect
that most SDOs will consider as serious input something that somebody
found on a web site or saw on a mailing list. To make IETF output
be an input to another SDO, in most cases IETF will need to formally
send it to the other SDO in the form of a liaison statement.
To date, IETF has been unsuccessful in doing this.
Regards,
Steve