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

From: Bob Braden <[email-masked]>
Date: Thu, 2 Jan 2003 18:33:44 GMT

*> A crankback TLV is suggested in Section 4.3.  While crankback is a
  *> desirable extension to both CR-LDP and RSVP-TE (and required by
  *> ASON), the proposal ignores the prior work done in
  *> http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-04.txt.
 *>  The advantages of the proposed method should be identified and
  *> justified.

Maybe it's time for someone to write an I-D entitled
"Crankback Considered Harmful" ?

Bob Braden

---

From: Bob Braden <[email-masked]>
Date: Thu, 2 Jan 2003 21:35:22 GMT

*> 
  *> Thanks for the opportunity to comment. I think it is important to document
  *> extensions and modifications made by other bodies to IETF protocols.
  *> 
  *> I would caution against progressing this draft until the referenced ITU
  *> material (G.7713.3) has reached consent within the ITU since to move it
  *> forward at this stage as an informational RFC might be misleading.
  *> 
Adrian,

There is a procedural catch-22 here.  This document was written, I believe,
to satisfy the IANA requirements for documentation oft code points to
be assigned for the ITU.  Presumably the ITU cannot progress their document
until these code points are assigned, yet the IANA is naturally wary about
assigning undocumented code points.

  *> At that point, perhaps Osama could clarify in the draft, that this
  *> draft introduces no new TLVs, messages or procedures others than those
  *> already agreed within the ITU. That is, that this draft is truly
  *> informational. Currently the text reads as though this draft is,
  *> itself, defining new material.

I believe the document implies that, but maybe you need them to say,
"Cross my heart and hope to die if it's not ITU-compliant"?

That said, the RFC Editor was asked to publish this as an independent
submission, and we are following procedures.  Those procedures
include asking the IESG to advise-and-consent to publication, which
led in turn to the Last Call. But the RFC Editor does not want to
publish anything whose confusion factor exceeds the long-term benefits
of publication, so we are pleased to get your input.

Bob Braden for the RFC Editor

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Wed, 8 Jan 2003 15:47:33 -0500

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

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Wed, 8 Jan 2003 15:47:33 -0500

Jerry Ash

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Thu, 9 Jan 2003 17:47:25 -0500

Zhi,

> 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.

Thanks to Kam for showing us the linkage, it's rather complicated...  Maybe that's why we've seen no discussion in CCAMP on these ASON Signaling Recommendations [G.7713.2 (GMPLS RSVP-TE) and G.7713.3 (GMPLS CR-LDP)].  Hopefully folks will look at them and provide comments.
 
> In terms of the intentions of the draft Recommendations 
> G.7713.x series, these draft Recommendations are targeted 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). 

So I guess you're saying that the G.7713.x Recommendations are actually 'requirements', presumably to be considered by the IETF for GMPLS extensions.  Is that also the purpose of yours and Osama's Informational RFCs on 'GMPLS extensions for ASON'?  That is, http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rsvpte-04.txt and http://www.ietf.org/internet-drafts/draft-aboulmagd-ccamp-crldp-ason-ext-02.txt are actually GMPLS requirements for CCAMP to consider, is that right?

BTW, 'large carriers' (and medium and small carriers, too) are providing requirements/needs directly into the GMPLS effort in IETF, as well as indirectly through the ITU.

> 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.

First, I think there is confusion in terminology across the various standards bodies.  For example, and quoting from Deborah Brungard: "One key item is the confusion between OIF, IETF, ITU participants on the definition of inter-domain interface. In ITU terminology, inter-domain is between carriers (and as an option for the carrier to use within his domain). Inter-domain is based on reachability, no topology sharing. Also no hierarchy. G.8080 is very clear on this. For OIF, an inter-domain interface is between vendors islands i.e. OIF is an interop forum. For IETF, it's interior (e.g. GMPLS/OSPF) and exterior (e.g. BGP)."

Second, we should align the ITU and IETF 'GMPLS' efforts.  That is, we need to a) understand the terminology, and b) provide the requirements from ITU to IETF (as you are doing through your informational RFCs).

> 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).

You're suggesting that a common set of requirements is driving the G.7713.x series, maybe so, but then why does CR-LDP have crankback and RSVP-TE doesn't have crankback (as one example of inconsistencies)?  Also, I'm not sure it's a great approach for vendors to decide which 'GMPLS extensions' to implement based on 2 versions of GMPLS (IETF and ITU), and also based on what operators ask for (it still sounds like we're getting 2 versions of GMPLS).

> Hope this answers your questions and concerns, and hope 
> others will chime in with their opinion on this...

Yes, I hope others will comment on this thread.

Thanks,
Jerry

> 
> Zhi
> 
> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALASO [mailto:[email-masked]]
> Sent: Wednesday, January 08, 2003 3:48 PM
> To: Loa Andersson; Adrian Farrel
> Cc: Ash, Gerald R (Jerry), ALASO; [email-masked]; Osama Aboul-Magd;
> [email-masked]; Lin, Zhi-Wei (Zhi); [email-masked]
> Subject: RE: CORRECTION: Last Call: CR-LDP Extensions for ASON to
> Informational
> 
> 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.
>