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

[John Drake <[e-mail]>]

Gerry,

I share your concerns.

I skimmed the informational RFCs you cited and they don't look much like
requirements documents.  Rather, they look like ITU protocol enhancements to
IETF protocols.  Quoting from the abstracts:  "It proposes additional
extensions to these signaling protocols to support the capabilities of an
ASON network." and "This document describes Constraint Route Label
Distribution Protocol (CR-LDP) extensions for use across ASON reference
points."

Using your example that it would be ill-considered for the IETF to develop
its own version of G.709, I think it would be better if ASON requirements
were brought into CCAMP and worked on there.

Thanks,

John 
 
  
    
-----Original Message-----
From: Ash, Gerald R (Jerry), ALASO [mailto:[e-mail]]
Sent: Thursday, January 09, 2003 2:47 PM
To: Lin, Zhi-Wei (Zhi)
Cc: Ash, Gerald R (Jerry), ALASO; [e-mail]; Osama Aboul-Magd;
[e-mail]; Lam, Hing-Kam (Kam); Lazer, Monica A, ALASO; Varma, Eve L
(Eve); Stephen Shew (E-mail); Alan McGuire (E-mail); Brungard, Deborah
A, ALASO; Loa Andersson; Adrian Farrel; Stephen Trowbridge; Lazer,
Monica A, ALASO
Subject: RE: CORRECTION: Last Call: CR-LDP Extensions for ASON to
Informational


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:[e-mail]]
> Sent: Wednesday, January 08, 2003 3:48 PM
> To: Loa Andersson; Adrian Farrel
> Cc: Ash, Gerald R (Jerry), ALASO; [e-mail]; Osama Aboul-Magd;
> [e-mail]; Lin, Zhi-Wei (Zhi); [e-mail]
> 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
>