RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

["Lin, Zhi-Wei (Zhi)" <[e-mail]>]

Hi Kireeti,

In terms of overlay and "call vs. connection", they are very much related. An overlay is simply a way to keep information from going from one network to another network. The "call" concept embodies that, but at the same time also adds a service concept to the signaling, as per what operators have requested. (People have concentrated on comparing overlay to UNI; I guess we have to remember that there is also the work on E-NNI). In terms of understanding the call concept, if you're familiar with the SS7 or ATM signaling, then call concept should be very familiar to you as well (it's been part of the telecom network for a long time). I'm not sure whether a clarification for this is needed, since we're all in the telecom industry and many of us have worked with either SS7 or ATM related signaling protocols before. Is this a bad assumption to make?

In terms of "IETF pursue its own standards track documents", of course this decision is up to us as IETF members to decide whether to create a standard for the overlay. However, we should concentrate on what makes the most sense for the industry. A side-note considering the relevance of the GMPLS work is that ITU is not talking about the IP network, but the transport network using this...

Related to your question about standards track vs. informational, the document was planned for standards track. However, as the request from ITU specifically says that there is a time constraint of Jan. '03, and as the standards track takes longer than what was required by the ITU-T, it was changed to informational. Kireeti you were kept in the loop during this process so should have been aware of this. 

For a position, I think the overlay issue has been resolved (and includes an additional component of supporting the service concept -- albeit all done in a different standards body) so should not need to be repeated here. But if IETF wants to repeat it and specify something different, than that can always be done based on the consensus of the body (regardless of whether it helps or hurts the industry)...

Zhi


-----Original Message-----
From: Kireeti Kompella [mailto:[e-mail]]
Sent: Friday, December 06, 2002 1:31 AM
To: Lin, Zhi-Wei (Zhi)
Cc: [e-mail]
Subject: RE: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt


Hi Zhi,

On Tue, 3 Dec 2002, Lin, Zhi-Wei (Zhi) wrote:

> Hi all,
>
> Actually the work been done in the ITU-T deals specifically with the overlay, at least the application that operators have identified as been important to them. These documents are planned to be consented at the Jan ITU-T meeting (G.7713.x series). ITU-T has communicated to the IETF regarding this work for some time now (I'm bad at remembering dates but you can probably trace back the emails or the liaison statements).

I'm probably confused, but I recall the issue that the liaison statement
raised as being "call and connection separation".  Perhaps that's the
same as overlay; if so, it would be useful to clarify that.

> In addition, I have submitted two I-Ds, one on requirements and another on protocol extensions needed to support the overlay. It is my understanding that the protocol extensions document has passed through IESG review and sent off to the RFC editors already?
>
> http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rqts-00.txt
>
> http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rsvpte-04.txt

My understanding was that these documents were to be standards track;
I learned at in Atlanta that their status was changed to informational.
It would have been friendly to state the change on the mailing list for
everyone's benefit.

In any case, as they are to be informational, I think it makes sense
that the IETF pursue its own standards track documents for overlay mode
if it sees fit (i.e., a chartered work item, and rough consensus).  The
CCAMP WG has been careful (with help from delegates from the ITU :-))
not to tread on the ITU's standards jurisdiction in the course of
developing IETF standards; however in this case, the IETF is extending
(or clarifying) its own protocols, and this issue doesn't arise.  One
might ask if the ITU is treading on the IETF's toes in this matter,
but it's a bit late for that.

Zhi, you didn't actually indicate an opinion on the swallow draft.
I will assume you don't have one unless I get mail otherwise.

Thanks,
Kireeti.