Re: WG dcoument status

[[e-mail]]

Stephen,

IMHO, your e-mail raises two issues 1) Procedural 2) Technical

Procedural:

The first question to ask yourself is "WHY does the CCAMP community 
has to consider this abstract control plane model as a "de facto" 
architecture that has to be integrated into GMPLS?"

So "Why should we have "special cases" for ITU people, requirements
or models, why aren't they proposing contributions as any other 
IETFer does?"

Technical:

AFAIK, G.ASON is based on a fundamental assumption: no routing 
information exchange between the client and server layer. GMPLS 
does not have such stringent restriction. Consequently, this makes 
the call/connection separation (while mandatory per requirement in 
the stringent G.ASON model) not at all necessary in the IETF scope 
since the "routing exchange" fulfills the role played by the call 
operation. Moreover since you ask for clear separation, any impact 
on the "connection" part (ie the referenced WG docs) is precluded  
by your own definition. So no impact on "existing" WG docs by adding 
your optional processing for call purposes i.e. there shouldn't be 
any backward compatibility issue with these WG docs.

Also in light with your "liaison" document: the restart capability 
issues have been addressed on this mailing list - at least 3 times - 
The conclusion (let's refresh people mind) was that what you are 
additionally asking here is more than clearly (i would say luminous)
outside of the scope of a "standard" since strictly related to an 
internal system processing, implying that just rough guidelines have 
to be added (but nothing more). No backward compatibility issue here. 
Btw, CCAMP should probably sent as liaison a summary of the mailing 
list discussions to the ITU SG15. This would help to achieve faster
results.

Considering that "crankback" is a broader scope than just the abstract
G.ASON model, i don't think we have to worry too much about your 
announced obsolescence of GMPLS I-Ds ;-)

Conclusion: 

GMPLS scope being much more larger than ITU-T G.ASON overlay model, 
while optional G.ASON related addition MUST NOT impact the existing 
content of the WG documents, i strongly suggest to consider here 
your SECOND option only as we did by the way for OIF extensions. 
This makes your optional extensions still feasible while keeping 
the existing document ongoing... and so the original document won't 
be obsolete AT ALL (as they will never be btw). More important from
an IETF perspective, i don't see any valuable reason to delay the 
two documents under discussion here (or at least not due to this 
liaison statement).

PS: 

when you say
"I am aware that it may not be the goal of everyone that these drafts
meet all of these requirements in the first version. But I think it is
our long term goal that these protocols and the ITU-T requirements
converge to the same solution."

You should probably rephrase it as "I am aware that it may not be the 
goal of everyone that these drafts meet all of these requirements in 
the first version. But I think it is MY (AS INDIVIDUAL ???) long term 
goal that these protocols and the ITU-T requirements converge to the 
same solution." 

When will you understand that NOBODY anymore knows who speaks: Steve
Trowbridge (as individual), ITU-T SG15 Vice Chair (as representative), 
"Sub-IP directorate" delegate ???

So thanks to sign your e-mails with the appropriate "name".
- dimitri.

Stephen Trowbridge wrote:
> 
> Kireeti,
> Regarding the WG last call on the documents:
>         draft-ietf-mpls-generalized-cr-ldp-05.txt
>         draft-ietf-mpls-generalized-rsvp-te-06.txt
> Please note that there is a communication statement from ITU-T Q.14/15
> which can be found at: http://www.ietf.org/IESG/LIAISON/ITU-OIF.html
> which is relevant to these drafts. In particular, this statement gives
> four examples of requirements from ITU-T Recommendations G.807/Y.1302,
> G.8080/Y.1304 and G.7713/Y.1704 which are not met by the current versions
> of the drafts.
> 
> I am aware that it may not be the goal of everyone that these drafts
> meet all of these requirements in the first version. But I think it is
> our long term goal that these protocols and the ITU-T requirements
> converge to the same solution.
> 
> In light of the communication statement, can we have some discussion
> about the way forward toward this goal? Some possible approaches are:
> - It seems for the moment, WG last call has not completed on another
>   of 4 drafts that are proposed to advance as a set. While we are
>   working to resolve the issues with: draft-ietf-ccamp-gmpls-sonet-sdh-02.txt,
>   is it possible to also address the requirements gaps in these other
>   two drafts?
> - If these two drafts are advanced as is to a proposed standard RFC, can
>   the requirement gaps be addressed with one or more new documents which
>   provide only additions, without obsoleting the original RFC?
> - If not, I presume we look forward to some new documents on ASON compliant
>   GMPLS which, when advanced, would obsolete the original RFCs.
> 
> Regards,
> Steve
> 
> Kireeti Kompella wrote:
> >
> > Here's a status update.
> >
> > The signaling drafts:
> >         draft-ietf-mpls-generalized-cr-ldp-05.txt
> >         draft-ietf-mpls-generalized-rsvp-te-06.txt
> >         draft-ietf-mpls-generalized-signaling-07.txt
> >         draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
> > have finished WG Last Call, and will be sent on to IETF Last Call.
> > They are on the track for Proposed Standard.
> >
> > Bert Wijnen (AD) has suggested that there should be an implementation
> > statement before these move on to IETF Last Call; the WG chairs and
> > draft editors agreed.  One note: the SDH/SONET label issue must be put
> > to rest before the SDH/SONET draft can move forward.  All other issues
> > are now closed.
> >
> > The LMP draft:
> >         draft-ietf-ccamp-lmp-02.txt
> > has gone through one round of WG Last Call comments and, once a
> > new version has been produced incorporating these comments, will
> > go through a final WG Last Call.  This is also targeted as a
> > Proposed Standard.
> >
> > The following draft, a companion to the above LMP document, is
> > also targeted at Proposed Standard, and is still being worked on:
> >         draft-ietf-ccamp-lmp-mib-00.txt
> >
> > The routing drafts:
> >         draft-ietf-ccamp-gmpls-routing-02.txt
> >         draft-ietf-ccamp-ospf-gmpls-extensions-04.txt
> > are awaiting WG consensus for going into WG Last Call.  These
> > are also targeted for Proposed Standard.  (Note that the ISIS
> > draft is owned by the ISIS WG.)
> >
> > The following drafts are Informational:
> >         draft-ietf-ccamp-gmpls-architecture-01.txt
> >         draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt
> > They are awaiting final touches from the editor before they
> > progress.
> >
> > The following two documents are also being worked on:
> >         draft-ietf-ccamp-oli-reqts-00.txt
> >         draft-ietf-ccamp-lmp-wdm-00.txt
> > The first is an Informational document; the second is aimed
> > at Proposed Standard.
> >
> > The MIBs are being reworked in response to comments from the AD.
> > When the new versions are ready, the WG will then be asked for
> > consensus to make them WG docs.
> >
> > Kireeti.

-- 
Papadimitriou Dimitri 
E-mail : [e-mail] 
Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
Address: Alcatel - Optical NA, Fr. Wellesplein, 1 
         B-2018 Antwerpen, Belgium
Phone:   Work: [phone] - Home: [phone]