The CCAMP Working Group thanks Q14/15 for their detailed
response (COM 15-LS126) reviewing <draft-ietf-ccamp-gmpls-
ason-routing-ospf-02.txt> and <draft-ietf-ccamp-gmpls-rsvp-
Regarding your comments on <draft-ietf-ccamp-gmpls-ason-
addresses the requirements set out in RFC 4258 that was
based on G.7715.1 (2003) which did not address multi-
Our work on Multi-layer and Multi-region Networks
addresses the additional requirements of multi-layer
networks. You may find the latest copies of Internet-
Drafts that discuss the requirements for multi-layer
networks and analyze the existing protocols against
those requirements on the CCAMP web site
separate draft (draft-papadimitriou-ccamp-gmpls-mrn-
extensions) has started to specify the necessary
protocol extensions for this work.
You are correct in your understanding of the Interface
Switching Capabilities Descriptor (ISCD): this will
very probably require some extensions in support of
multi-layer networks. The information that you supplied
may be very helpful in a detailed analysis of exactly
what extensions are required, and we invite interested
members of your group to participate in this work via
the CCAMP mailing list.
Please keep us informed as you evolve ASON to include
multi-layer networks and any related GMPLS protocol
1.2 We understand the architectural possibility of an n:1
or m:n relationship between Routing Controllers (RCs)
and Transport Nodes, although we have yet to hear from
anyone who wishes to implement or deploy in this ratio.
We remind you that in this Internet-Draft Li is not a
physical entity (transport node), but is a logical
control plane entity that is "associated to a single
data plane (abstract) node". As in G.7715, no
distinction is made between data plane nodes that may
have further internal details (i.e., abstract nodes)
and those that cannot be decomposed any further. Thus,
while the relationship Ri:Li can only be 1:n (for n >=
1), the relationship Ri:Pi can be m:n (for m and n >=
1). This provides function in keeping with the
You are correct that an implementation of an Li:Pi
ratio of n:1 (for n > 1) might choose to use virtual
links between the Li instances. But we disagree with
your interpretation that a GMPLS TE link cannot be
advertised as "available for all possible constraints".
If you have a specific scenario in mind arising from
your implementation please discuss it with us and we
will be happy to explain further. We agree that an
implementation that chose to partition a Pi into
multiple Li instances by sharing the same TE link
between multiple Li instances would be ill-advised,
and we note that it is unlikely to be a recommendation
that multiple RCs advertise the same resource when they
are advertising for the same Pi.
We stress again that there are two focuses of this
work. Firstly to provide simple and backward compatible
protocol extensions to support those features of the
architecture that vendors are implementing and that
carriers wish to deploy. Secondly to enable all other
features of the architecture so that, should a vendor
choose to implement, they are not blocked. But we note
that the objective of the IETF is to produce solutions
that are implemented and deployed.
The second part of this item, regards your concern on
the limitation of one transport name per RC. As Mr.
Farrel noted in your meeting, there is no such
limitation. This Internet-Draft defines the capability
for an RC to advertise more than one TE Router ID.
You also express a concern about whether it is possible
to assign more than one SC (Signaling Communication)
address per RC. In the light of your observations that:
1. "the current definition of Router Address TLV does
not distinguish the identifier for transport plane
names (i.e., TE Router_ID) from the SC address"; and
2. "this I-D removes the restriction of one transport
name per RC"
we request additional clarification of your concern.
If your participants are interested in further
enhancing protocol solutions to support specific
implementation or deployment scenarios that are an
immediate concern for them, we invite you to
participate in CCAMP's protocol work.
1.3 We disagree with your representation that "information
elements necessary for operation of the protocol or for
conformance to the ASON routing requirements are stated
to be optional or non-normative". Consider, for
example, in section 4.2 where the text states that:
In the ASON context, accounting on per timeslot basis
using 32-bit tuples of the form <signal_type (8 bits);
number of unallocated timeslots (24 bits)> may
optionally be incorporated in the technology specific
field of the ISCD TE link attribute when the switching
capability field is set to TDM value.
This use of "optionally" is clearly necessary because
you would not expect timeslot accounting in a WDM
The other example you noted is in section 5.2 where the
Local TE Router ID sub-TLV is defined as "optional and
SHOULD only be included as part of the top level Link
TLV if the Router_ID is advertising on behalf of more
than one TE_Router_ID." There are two degrees to the
use of the word "optional" in this case:
1. You must understand that we are defining protocol
extensions to an existing protocol that is deployed
in many environments. If we state that the Local TE
Router ID sub-TLV is mandatory, how would you
suggest that a normal, legacy OSPF router should
2. The Local TE Router ID sub-TLV is only required if
the advertisement carries more than one TE Router
ID. If the protocol element is not required it is
omitted. Thus it is optional.
Note also that "optional" in the text does not apply in
regard to the support of an element (the support is
mandatory), but is in reference to the use of the
Please let us know if there are any other examples of
optional elements in the Internet-Draft that concern
you, or please confirm that you are now comfortable
with the wording.
Lastly, you ask how we propose to support nodes that do
not support the ASON extensions. It is certainly
possible, and indeed likely in early deployments, that
a subnetwork will be comprised entirely of nodes that
either support or do not support these extensions. It
should be noted, however, that it is of the nature of
the opaque LSA in OSPF that nodes that do not support
TLVs, sub-TLVs, or the entire LSA will continue to
flood the information. Thus, within certain limitations
it is possible to build a mixed network, and this
choice is left to the operators during network design
1.4 We are glad that you agree with our assessment that it
is an essential element of OSPF routing protocol design
to provide import/export rules to prevent feedback
RFC2966 presents a solution to this problem specific to
the ISIS protocol, although, as you say, this mechanism
could be adapted to other protocols.
But other mechanisms also exist, and the ultimate
solution that we choose must be agreed not by the ISIS
community, but by the OSPF community. In this case, the
choice was made after careful evaluation in cooperation
with IETF's OSPF Working Group.
Please let us know whether you have any technical
issues with the approach we have chosen, and if so,
what the issues are.
1.5 You say:
As ITU-T Q14/15 identifies the need for new code
points in support of evolving transport standards
(e.g., for new reachability formats, ISCD/IACD), we
will be counting on CCAMP WG assistance to actively
facilitate the allocation of code points from IANA.
(Several ITU-T sector members have already expressed
interest in supporting TID/AID as an additional
reachability format.) We look forward to your
We invite you to read and consider RFC 4775.
As in the past, CCAMP is pleased to work with you to
consider your protocol requirements and to advise you
on the best way to use or extend GMPLS protocols to
meet the requirements of your sector members. It would
be premature to accept that new codepoint assignments
are the appropriate solution before seeing the detailed
requirements, and we strongly encourage you to provide
us with any new requirements regarding the use of GMPLS
before attempting to specify protocol extensions.
1.6.1 The use of a variety of mechanisms to provide name/
address translation are certainly not prohibited.
Note, however, that <draft-ietf-ccamp-gmpls-ason-
routing-ospf-02.txt> is specific to the OSPF
protocol, and that RFC 4652 is specific to an
examination of how to provide the required function
using routing protocols. Therefore, other mechanisms
are out of scope of these documents and we have no
plans to update them.
We would welcome a separate initiative to document
other mechanisms that vendors are implementing and
that carriers propose to deploy.
1.6.2 The point you raise is fundamental to the use of
addressing in GMPLS, and we recommend careful reading
of RFC3945 and RFC4202. A thorough understanding of
naming and addressing in GMPLS is recommended to
everyone who seeks to implement, deploy, or extend
the GMPLS protocols.
The "reachable destination prefix hosted by the
advertising Router ID" is a GMPLS TE address, not
ever to be confused with addresses used in IPv4 and
IPv6 layer networks. The concept of issuing a 'ping'
in a layer one network is meaningless.
1.6.3 On Section 5.1, yes, this is in reference to control
plane connectivity as described in the paragraph
above the note. As described above (1.6.2),
separation of control plane and data plane is
fundamental to GMPLS.
On Section 5.2, refer to discussion above and the use
of "optional". Again, the use of the word "optional"
is with regards to the protocol as the phrasing
applies to any type of link advertisement, even those
that do not need it (i.e. "should").
(a) Thank you for this input. We will update the document
to be consistent with your revised definition.
(b) We are grateful for your views on the correct way to
build and deploy OSPF networks. We have consulted
within the IETF's OSPF working group where there is
great experience of OSPF network design and where the
OSPF protocol experts can be found, and within the
MPLS and CCAMP working groups where a largest
concentration of experience of TE network design and
deployment can be found. This consultation led to the
view that a multi-instance solution was preferable in
Note that hierarchical exchanges are not equivalent
to multi-area exchanges.
(c) With regard to "speedy recovery", can you clarify
your concern on LS MAX Age and the implications for
recovery? Are you saying that your concern is the
continued behavior of upward dissemination of routing
information in the event that the selected RC
performing the dissemination fails?
(d) Even if the case you have documented occurs, the
important point is that LSAs do not loop. Duplicates
may appear in OSPF, and these are acceptable since
there are procedures in OSPF to prevent them causing
1.6.5 Yes, good catch, thanks.
Regarding your comments on <draft-ietf-ccamp-gmpls-rsvp-te-
2.0 It is important to recognize that <draft-ietf-ccamp-
gmpls-rsvp-te-call-01.txt> introduces Call mechanisms
into GMPLS as a generic tool. As noted in Section 2,
while the mechanisms of this document meet the
requirements in RFC 4139, they are intended to have
wider applicability than ASON. RFC 4139 details the
requirements for ASON.
The application of the GMPLS Call to the ASON
architecture in order to satisfy the requirements for
conveying ASON Call information across a GMPLS
interface and for managing ASON Calls at a GMPLS UNI or
GMPLS ENNI will require a new Applicability Draft.
Thus, section 3.2 of this document does not imply
anything about ASON, and certainly not that ASON
requires full and logical call/connection separation.
We understand that ASON Calls may be implemented
through full call/connection separation (as in
G.7713.3) or call/connection 'piggybacking' as in
G.7713.2. Please confirm that our interpretation of
G.8080 and G.7713 is correct.
Adrian Farrel and Deborah Brungard
CCAMP Working Group Co-chairs