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

["Lam, Hing-Kam (Kam)" <hklam@lucent.com>]

Hi all,

The Q14/15 liaison statements can be found from
http://www.ietf.org/IESG/LIAISON/ as follow:

Click on "ITU-tsg15opt.html (21-Oct-2002 17:44)", which leads you to
http://www.ietf.org/IESG/LIAISON/ITU-tsg15opt.html,

then click on "Common Control and Measurement Plane (ccamp) Working Group" which leads you to
ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/ccamp/index.html,

then clcik "I accept", it leads you to
ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/ccamp/IETF_ccamp.html,

the Q14/15 liasison is the last entry of the first table
"11 October 2002 Signalling protocol work in Q.14/15"
ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/ccamp/IETF_ccamp_sigprotocol_Oct2002_Q14.html.

The draft of G.7713.2 and G.7713.3 are available there for download.

Regards,
Kam  



> -----Original Message-----
> From: Lin, Zhi-Wei (Zhi) 
> Sent: Wednesday, January 08, 2003 4:19 PM
> To: 'Ash, Gerald R (Jerry), ALASO'; 'Loa Andersson'; 'Adrian Farrel'
> Cc: 'iesg@ietf.org'; 'Osama Aboul-Magd'; 'ietf@ietf.org'; Lin, Zhi-Wei
> (Zhi); Lam, Hing-Kam (Kam); 'Monica Lazer (E-mail)'; Varma, 
> Eve L (Eve);
> 'Stephen Shew (E-mail)'; 'Alan McGuire (E-mail)'
> Subject: RE: CORRECTION: Last Call: CR-LDP Extensions for ASON to
> Informational
> 
> 
> 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:gash@att.com]
> Sent: Wednesday, January 08, 2003 3:48 PM
> To: Loa Andersson; Adrian Farrel
> Cc: Ash, Gerald R (Jerry), ALASO; iesg@ietf.org; Osama Aboul-Magd;
> ietf@ietf.org; Lin, Zhi-Wei (Zhi); hklam@lucent.com
> 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
>