Hi Gerry, Happy new year.
In terms of where the liaisons are, not sure. I checked the link as well, and couldn't find any of the liaisons that was sent from ITU-T Q.14/15 to IETF CCAMP WG. In terms of the intentions of the draft Recommendations G.7713.x series, these draft Recommendations are targetted to support the ASON control plane network. There is a difference between what IETF is working on and what ITU is working on, and these are mainly targeted for large incumbent carriers such as your company (and many of these requirements are driven by large carriers). For example, one obvious difference is the support of only IP addressing within the GMPLS. In the ITU ASON extensions, the G.7713.x protocols include support for not only the IP addresses, but also NSAP addresses. Another obvious difference is that when ITU was developing ASON and IETF developing GMPLS, there was a position within CCAMP (during GMPLS development) that there is an inherent sharing of information between a user of the network and the network itself (the overlay vs. peer discussion). The ITU has always taken the approach that we need to support a range of information sharing, from fully sharing info (the I-NNI interface) to flexible info sharing (the E-NNI interface) to no sharing of info (the UNI interface). The majority of the extensions (NOTE these are extensions and not competing protocols) are to support these fundamental network design decisions. Another example of the difference in design philosophy is in the area of routing. Within the CCAMP, routing extensions are made to the existing protocols to support additional link attributes for GMPLS. However, the concept of multiple domains and hierarchies are not really provided (not beyond what the existing protocol provides). These concepts (domains and hierarchies) are again driven by the large carriers (such as AT&T and BT). What we (as ITU-T participants) did were to listen to these requirements and added extensions that supports the carriers' requirements. In terms of your question about interoperability, the protocol extensions from the ITU is designed as optional/additional "tools" as part of the GMPLS toolkit. If a vendor chooses to support the ITU's ASON application, they will implement. Otherwise they will only implement the core GMPLS and no more. Which vendor decides to implement what really depends on what carriers (such as your company) are going to ask for. The carriers have set the requirements in ITU and those requirements have driven the protocol extensions. The protocol design within the IETF were driven from a different direction (or a different set of companies -- more the enterprise customers). Hope this answers your questions and concerns, and hope others will chime in with their opinion on this... Zhi -----Original Message----- From: Ash, Gerald R (Jerry), ALASO [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 3:48 PM To: Loa Andersson; Adrian Farrel Cc: Ash, Gerald R (Jerry), ALASO; [EMAIL PROTECTED]; Osama Aboul-Magd; [EMAIL PROTECTED]; Lin, Zhi-Wei (Zhi); [EMAIL PROTECTED] Subject: RE: CORRECTION: Last Call: CR-LDP Extensions for ASON to Informational Adrian> I am saying that it sounds to me from the discussion that Adrian> the ITU has not yet reached consent. It seemed to me that Adrian> if the draft is intended to document the ITU preferences as Adrian> informational, it would be as well to wait until the ITU has Adrian> fully signed off. I don't see any rush for this. Loa> ok - I can see the difference - and it seems that you are correct. If Loa> the ITU discussion still has some way to go before the discussion Loa> settles and the preferences better known - wouldn't it be Loa> appropriate to wait until this happens? ASON Signaling Recommendations G.7713.2 (GMPLS RSVP-TE) and G.7713.3 (GMPLS CR-LDP) are proposed for consent at the upcoming SG15 meeting, 20-31 January (Geneva). A Liaison was sent to the IETF containing Recommendation text, but I can't find it on http://www.ietf.org/IESG/LIAISON/. Both documents propose detailed protocol specifications including new TLVs (e.g., crankback TLV in G.7713.3). The intent of these Recommendations is unclear. If these are statements of 'ITU preferences/requirements' which are made known to the IETF through the Informational RFCs, such as Osama's and Zhi's, then fine. IETF can then take up the 'preferences/requirements' and consider them for upgrading RSVP-TE and CR-LDP protocols (although CR-LDP is capped). However, if they are intended as alternative protocol specs competing with the IETF specs, then that's a problem. Which spec does a vendor implement and an operator use, given interoperability needs, etc.? It would be analogous to the IETF specifying their version of G.709. A clarification of the intent of these Recs. would be helpful. Jerry Ash
