Subject: Review Call: draft-andersson-rtg-gmpls-change-00.txt

From: Alex Zinin <[email-masked]>
Date: Wed, 5 Jan 2005 16:29:00 -0800

Folks-

 We'd like to solicit your comments on this document before Last-Call'ing it.
 Please send your comments to the routing-discussion mailing list.

 http://www.ietf.org/internet-drafts/draft-andersson-rtg-gmpls-change-00.txt
 
                     MPLS and GMPLS Change Process
               draft-andersson-rtg-gmpls-change-00.txt
Abstract

   The MPLS and GMPLS protocol suites have become quite popular for a
   growing number of applications and deployment scenarios.  One result
   of this popularity is a large number of suggestions for modifications
   and extensions.

   The IETF needs to be flexible and responsive in how it handles these
   suggestions, and has a responsiblity to supervise the growth and
   evolution of MPLS and GMPLS protocols.

   This memo describes the process through which individuals, working
   groups and external standards bodies can influence the development of
   the MPLS and GMPLS standards.  This process means that extensions and
   changes to protocols specified by these working groups can only be
   made through the IETF, the body that created the (G)MPLS
   ((Generalized) Multiprotocol Label Switching) technologies.

-- 
Alex
http://www.psg.com/~zinin

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: dimitri papadimitriou <[email-masked]>
Date: Sun, 09 Jan 2005 12:46:35 +0100

alex, several comments here below

1. section 2.4

"Traffic Engineering Working Group (te-wg).  These working
    groups have not specified any protocols, but have been a source of
    requirements to be considered by the (G)MPLS working groups."

that is not necessarily true - see "Protocol extensions for support of
Differentiated-Service-aware MPLS Traffic Engineering "

<http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-proto-08.txt>

2. section 3.2.1

"The mailing list to use will in most cases be the Routing Area maililng 
list, as this is the Area containing working group that has specified 
the protocol being changed and that will likely be the rewg. The IESG or 
the Routing Area ADs may decide to use a specific working group mailing 
list for this discussion."

so if well understand the routing area mailing list becomes the 
"default" starting point for most discussion ? but the question is that 
section 3.2.1 requires to write down a document detailing - ditto
"Anyone who intends to use one of the existing (G)MPLS protocols, but
thinks that it  will not satisfy their needs MUST write an Internet-
Draft (ID) explaining the problem they are trying to solve and why
the existing (G)MPLS  protocols will not work.  This Internet-Draft -
the problem statement ID - MUST include a detailed set of
requirements that (G)MPLS would need to meet to solve the particular 
problem." therefore is the targeted protocol not known before-hand 
making the above decision limited to a restricted number of problem 
statements rather than being the general case ? this comment seems 
in-line with the following section 2.3 statement "An entity or 
individual that wishes to propose extensions or changes to (G)MPLS 
should first decide to which Working Group (MPLS or CCAMP) it will bring 
the proposal." so why shall this discussion happen elsewhere ? any 
further clarification would be helpful here

3. section 3.2.4

"In this case the rewg will evaluate and refine the requirements,
merging them with other rewuirments if warranted. The result of
these deliberations will be captured in a requirements RFC."

as i understand the process for each "solution" we would now have a 
"requirement RFC" why is the usage of a motivation section in the 
solution document not considered for items with limited impact ?

4. section 5.

there are two classes of WG I-Ds/RFCs that are part of the (G)MPLS 
protocol suite that are not catalogued as outcome of the "(G)MPLS 
working groups" 1) routing extensions: RFC 3630, OSPFv3-TE, RFC 3784, 
GMPLS IS-IS TE and 2) the signaling protocol documents from which 
RSVP-TE has been derived but that still make abundantly usage of: RFC 
2205, 2210, 2961 (and to a less extend 2211, 2212, 2215) - are these 
part of the set mentioned in this section ?

5. General comment - does this document applies de-facto to new WGs that 
would potentially make use of the protocols of the (G)MPLS WGs such as 
the PCE WG for inst. (if the WG creation is approved), section 2.4 lists 
potential candidates but does not assume anythng specific for such 
situations

6. General comment - does this document assumes possible revision or 
refinment of the process based on its feedback and usage ?

7. edits: there are several typos in this document - for instance:

"One exeception to this rule is when other IETF working groups has
    been appointed, in accorance with the process descrbide in this
    document, to handled extensions and/or changes to the protocols
    specified by the MPLS working group."

---

From: Eric Rosen <[email-masked]>
Date: Tue, 11 Jan 2005 11:38:54 -0500

I'll have to say that this document puzzles me quite a bit. 

It's already  true that nobody  can turn a  protocol extension into  an IETF
standard unless there is IETF consensus.  So I don't understand why any more
process is needed.

What  this  draft  seems  to  be  saying  is that  no  one  can  publish  an
Informational RFC  documenting a proprietary (or  non-IETF) extension unless
there is IETF consensus. 

That  seems very  foolish to  me.   Anyone who  wants to  deploy a  non-IETF
extension will  not be dissuaded from doing  so by the fact  that they can't
publish an RFC about it.  The only  effect of such a publication ban is that
it will be  a lot less convenient  for the IETF community to  find out about
it.  It's hard to see how this helps the IETF or the Internet. 

There  are a  number of  statements  about what  other SDOs  "MUST" do  when
extending IETF  protocols, but I don't  think the IETF has  any authority to
tell other SDOs what they "MUST" do. 

I  do think  it  makes sense,  within  the IETF,  to  require that  protocol
extensions  be approved  by  the WG  that  "owns" a  protocol,  even if  the
extensions  are  only  needed by  an  application  that  is specified  by  a
different WG.   However, I don't think we  need to add layers  and layers of
process here: one WG sends requirements to the other, then the other decided
whether they want to modify their charter, then the IESG decides whether the
charter should  be modified, then  solutions work begins from  scratch, etc.
Generally the first  WG will already have a  solution fairly well specified,
and usually the two WGs will have significant overlap in participation.  All
this process  then becomes nothing but  a waste of everyone's  time.  Not to
mention  becoming  another  oppportunity  to  introduce  politics,  marking,
inter-company rivalries, etc.

Sure,  the protocol-owning  WG should  be able  to critique  the  other WG's
solution, even  rejecting it if there  is good enough cause.   But let's not
have  a process  in which  we have  to pretend  that the  protocol-owning WG
should be starting the solutions work from scratch. 

>   The Pseudo Wire Emulation End to End (PWE3) working group is a
>   working in the Internet Area that also uses the (G)MPLS protocols in
>   its specifications.  Should the PWE3 specifications require extension
>   and/or changes to the (G)MPLS protocols these changes and/or
>   extensions SHALL be submitted to the (G)MPLS working group that
>   originally specified the protocol in the form of an Internet-Draft. 

This  is a  good  example.  PWE3  has  done a  fair amount  of  work on  LDP
extensions.  While  the LDP extensions need  to be approved by  the MPLS WG,
there is certainly  no need to start up a heavyweight  process in which PWE3
first has to send MPLS a requirements document! 

If you  make the process  too heavyweight, folks  will find a way  around it
anyway.  For  instance, instead of  specifying a new protocol  element, they
will just reinterpret an old one, and then claim that since there are no new
protocol  elements, there  has  been  no protocol  extension.   In terms  of
architectural  coherence, this  can be  much worse  than specifying  the new
protocol element.