RE: Last Call: CR-LDP Extensions for ASON to Informational

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@ftp.itu.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@lucent.com]

Sent: dinsdag 21 januari 2003 16:42

To: Kireeti Kompella

Cc: Bob Braden; iesg@ietf.org; ietf@ietf.org

Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational

Inline

> -----Original Message-----

> From: Kireeti Kompella [mailto:kireeti@juniper.net]

> Sent: maandag 20 januari 2003 22:49

> To: Wijnen, Bert (Bert)

> Cc: Bob Braden; iesg@ietf.org; ietf@ietf.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.