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(_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