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