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/COMMUNICATIONS/index.html
<ftp://sg15opticalt:otxchange(_at_)ftp(_dot_)itu(_dot_)int/tsg15opticaltransport/COMMUNICATIONS/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.