I agree with Zhi-Wei's points below. On the matter of concensus I think the
original email implied "agreement" as opposed to the ITU-T meaning of
"consent". The existence of the G.8080 and G.7713 (which are ITU-T
"consented") do mean that call and connection separation are agreed to in
the ITU-T. This is why the notion is contained in all three signalling
draft recommendations (G.7713.x). The call/connection architecture is well
established in ISDN and B-ISDN documents and so I think there is very wide
agreement on this concept.
As far as the call being carried by the connection, this is one of two call
setup models and has been called "logical separation". In the second model,
the call is in fact separated from connection setup. In either case, the
separation is useful for ASON services in that allows the transport network
to support calls with capabilities like redialing for restoration and setup
of diverse virtually concatenated connections.
-----Original Message-----
From: Lin, Zhi-Wei (Zhi) [mailto:zwlin(_at_)lucent(_dot_)com]
Sent: Wednesday, January 22, 2003 14:09
To: 'iesg(_at_)ietf(_dot_)org'; 'ietf(_at_)ietf(_dot_)org'; Wijnen, Bert
(Bert); Scott Bradner
(E-mail); 'kireeti(_at_)juniper(_dot_)net'
Cc: Shew, Stephen [SKY:QW33:EXCH]; Lyndon Ong (E-mail); Betts, Malcolm
[SKY:1ID0:EXCH]; Lam, Hing-Kam (Kam); Alan McGuire (E-mail); Lin, Zhi-Wei
(Zhi); 'sjtrowbridge(_at_)lucent(_dot_)com'; Dimitrios Pendarakis (E-mail)
Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational
Hi,
I wanted to respond to some of the comments raised by Kireeti.
With respect to the issue re call and connection separation, call and
connection separation is an architectural requirement that is fully
documented within Rec. G.8080. Rec. G.8080 was liaised to the IETF quite
some time ago (it was Approved end '01; Consented Oct. '01), and at every
meeting of the IETF for the past few meetings, there have been status
updates provided on associated ITU-T work efforts. As you may recall, Kam
sent out an email earlier in reply to some other comments on where these
documents can be obtained. Rec. G.7713, which also reflects call and
connection separation, was also sent to the IETF almost a year ago upon it's
Approval end of '01
To find the information that has been transmitted from ITU-T to IETF on this
subject (from 26 October 2001), see:
ftp://sg15opticalt:otxchange(_at_)ftp(_dot_)itu(_dot_)int/tsg15opticaltransport/COMMUNICATION
S/index.html
<ftp://sg15opticalt:otxchange(_at_)ftp(_dot_)itu(_dot_)int/tsg15opticaltransport/COMMUNICATIO
NS/index.html>
In terms of the formatting of the CALL_ID, Kireeti raised a question as to
why IP addresses only were not sufficient. The answer to this illustrates
one difference between the IETF and ITU-T scope. The focus of the IETF is
upon IP-based client services while ITU-T has a multi-service focus,
including not only IP but also other types of services (such as ATM). As
such, it cannot be assumed that all NEs have IP addresses associated with
them. In addition, it cannot be assumed that, even if the NE has an IP
address, that those IP addresses are globally unique. As such, it was
necessary to come up with a identifier format that does not assume the
global uniqueness of an address. The selected approach was to re-use
existing identifier formats (e.g., from the TTI format such as G.709) that
provides "free" globally unique identifiers.
As mentioned in the documentation for G.7713.x, the CALL_ID IS and NS is
used only when "global" uniqueness is needed. In the event that networks are
just been deployed or it's a single carrier's network where their addressing
space is unique, then they can use the "operator specific" CALL_ID format.
In this format the CALL_ID is essentially the IP address (if the type is
4-byte or 16-byte variety).
In terms of the "didn't hear a clear consensus on the need for this", the
text was published in Report COM15-24 (Part IIA of the report of WP 3/15).
According to ITU-T practice, inclusion in part IIA indicates that the text
is "agreed", although not at the point of "consent" ready to issue for a
Last Call. The agreement to place text in part IIA of a report occurs at the
final plenary of the Study Group meeting. This meeting was attended by
approximately 300 participants. The reason that the text was not put for
consent at the May 2002 meeting of Study Group 15 was to provide time for
comments on the text in response to liaisons sent to IETF ccamp and the ATM
forum, and to allow IANA assigned codepoints to be included in the document.
A clear U.K. national position paper was contributed to the meeting
currently underway (delayed contribution 483), supporting that all three of
the ASON signaling Recommendations should be put for consent at this
meeting.
Hope this helps...
Zhi
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen(_at_)lucent(_dot_)com]
Sent: dinsdag 21 januari 2003 16:42
To: Kireeti Kompella
Cc: Bob Braden; iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational
Inline
-----Original Message-----
From: Kireeti Kompella [mailto:kireeti(_at_)juniper(_dot_)net]
Sent: maandag 20 januari 2003 22:49
To: Wijnen, Bert (Bert)
Cc: Bob Braden; iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational
Hi Bert,
On Sat, 18 Jan 2003, Wijnen, Bert (Bert) wrote:
Yes they are from the "IETF Consensus space".
Now can you be more specific as to why you do not consider this doc
ready for publication?
There are a large number of nits and typos -- so much so that in my
opinion, this document should not have been sent to IETF Last Call
without another round of edits. However, I will ignore those and
concentrate on the substance.
It would be great if you can send a list of nits and typos to the
author and copy Scott and Myself, possibly aslo the RFC-Editor.
I would like to know what the intent is in not granting "the right
to produce derivative works",
Did Steve Trowbridge not answer the first question?
and whether the IETF should progress a
document that is a derivative of IETF protocols with this clause.
I think you meant a colon after "clause" and not a priod?
The main thrust of the document is the "separation of call and
connection";
there is one short paragraph that describes this, and
a reference to an ITU document.
Well, the ITU document should document the details. I don't think
we just want them to copy all their documentation into RFCs, do we?
In my discussions with people who
go to the ITU, I didn't hear a clear consensus on the need for this.
Well, then they should speak up in ITU I think. The ITU-T SG15 is
discussing this in their meeting this week, and the technology is
up for consent. Any "people who go to the ITU" (to use your words)
and who do NOT agree with it should then speak up in ITU SG15,
don't you think so?
An *IETF* document that describes the background, needs and how this
is to be used would be very useful. This is especially important as
the very next paragraph says that separation can be achieved "where
the call set up request is always accaccompanied by a connection
request", which (to my naive understanding) hardly is separation.
Why would we need them to replicate their own documentation into an
IETF document?
Secondly, there is a real paucity of detail in the description and
use of the new messages: the Call Setup Message refers to the OIF
UNI document for formating and doesn't say much about when and how
it is to be used; there is no justification for the format of the
Call ID (why is there an International Segment, etc.? Won't IP
addresses do? Is this to be used for telephone calls??? My
recollection is that Fred Baker (then IETF chair) said that using
CCAMP for telephony was a no-no ....)
I will leave it to the "ITU" folk to answer the details.
But your main point seems to be that you have not seen enough
documentation. ITU-T did a Liason Statement to us, and I believe
even specifically to CCAMP WG (that you co-chair) and so can you
tell me if you read their documentation that they have made
(freely) available to us to check? And after reading that, do
your points still hold. If so, then maybe we (CCAMP) should answer
the Liason Statement and explain to them how and where they should
add more detail and ask specific questions based on what they
document in their "drafts" (or documents) to which they point.
Call Release can be "sent by any entity of the network". This surely
can't be correct.
Will let ITU-folk answer that.
The Call Capability TLV is completely undocumented beyond the format
of the TLV.
How about in the documents in OIF and ITU that they point to?
As someone else pointed out, crankback for CR-LDP has already been
defined. Furthermore, this document does not say what procedures
the sender and receiver must follow, and how crankback is to be
effected.
What do you mean by "has already been defined" ??
And are the procedures not documented in the documents they point to?
The "Additional Error Codes" have absolutely no detail about what
they mean, when they are to be sent, and what the receiver should
do with them. They also use a slew of unidentified acronyms.
They do in the documents they point to.
Bert
Kireeti.