Draft liaison to ITU-T SG15

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

We owe Question 14 of Study Group 15 of the ITU-T a response to their 
liaison containing review comments on 
draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt and 
draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt. You can find their liaison by 
looking at www.olddog.co.uk/ccamp.htm

Deborah and I have put together the attached draft with the help of some 
others, and we'd like you to check it over.

As we have left this a bit late, we will probably send it as a liaison quite 
soon. If necessary we will be able to update the liaison later.

Thanks,
Adrian
===

To: ITU-T SG15
From: CCAMP
For Action

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-
te-call-01.txt>.

Regarding your comments on <draft-ietf-ccamp-gmpls-ason-
routing-ospf-02.txt>:

1.1 <draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt>
   addresses the requirements set out in RFC 4258 that was
   based on G.7715.1 (2003) which did not address multi-
   layer networks.

   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
   (www.ietf.org/html.charters/ccamp-charter.html). A
   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
   requirements.

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
   architecture.

   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
   system.

   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
      behave?

   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
   element.

   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
   and deployment.

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
   loops.

   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
     acknowledgment.

   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.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").

1.6.4
 (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
     this case.

     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
     any damage.

1.6.5 Yes, good catch, thanks.



Regarding your comments on <draft-ietf-ccamp-gmpls-rsvp-te-
call-01.txt>

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.