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

[Stephen Trowbridge <sjtrowbridge@lucent.com>]

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

Curtis Villamizar wrote:
> 
> In message <3E638325.D254FF0F@lucent.com>, Stephen Trowbridge writes:
> > 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
> 
> 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