Liaison statement
Response to your liaison on current ASON work in CCAMP

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.

Best regards,
Adrian Farrel and Deborah Brungard
CCAMP Working Group Co-chairs