Liaison statement
Response to your liaison on current ASON work in CCAMP
Additional information about IETF liaison relationships is available on the
IETF webpage
and the
Internet Architecture Board liaison webpage.
State | Posted |
---|---|
Submitted Date | 2007-02-21 |
From Group | ccamp |
From Contact | Adrian Farrel |
To Group | ITU-T-SG-15-Q14 |
To Contacts | Greg Jones <greg.jones@itu.int> |
Cc | Kam Lam <hklam@alcatel-lucent.com> Stephen Trowbridge <sjtrowbridge@alcatel-lucent.com> Ross Callon <rcallon@juniper.net> Scot Bradner <sob@harvard.edu> Deborah Brungard <dbrungard@att.com> CCAMP <ccamp@ops.ietf.org> |
Response Contact | Adrian Farrel <adrian@olddog.co.uk> |
Technical Contact | Adrian Farrel <adrian@olddog.co.uk> |
Purpose | For action |
Deadline | 2007-03-16 Action Taken |
Attachments | (None) |
Body |
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 |