ietf
[Top] [All Lists]

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

2003-01-09 15:53:31
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:gash(_at_)att(_dot_)com]
Sent: Wednesday, January 08, 2003 3:48 PM
To: Loa Andersson; Adrian Farrel
Cc: Ash, Gerald R (Jerry), ALASO; iesg(_at_)ietf(_dot_)org; Osama Aboul-Magd;
ietf(_at_)ietf(_dot_)org; Lin, Zhi-Wei (Zhi); hklam(_at_)lucent(_dot_)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