Question(s):

14/15, 12/15

Meeting, date:

Chicago, February 16 – 20, 2004

Study Group:

15

Working Party:

3

Source:

ITU-T SG15, Q.14/15

Title:

Response To IETF CCAMP WG on ASON Routing Requirements

LIAISON STATEMENT

To:

IETF CCAMP WG Chairs (K. Kompella, A. Farrel)

Cc:

IETF Routing Area Directors (A. Zinin, B. Fenner)

Approval:

ITU-T SG15 Q14/15 Rapporteur Meeting

For:

Action

Deadline:

12 April 2004

Contact:

Hing-Kam Lam

Lucent Technologies

USA

Tel: +1 732-949-8338

Fax: +1 732-949-1196

Email: hklam@lucent.com

 

 

Dear Mr. Kompella and Mr. Farrel,

 

This liaison is sent in response to your liaison of February 13 providing us with the output of the IETF's CCAMP WG Design Team on GMPLS ASON routing requirements, "draft-ietf-ccamp-gmpls-ason-routing-reqts-02".  We appreciate the attention that has been given to this work by CCAMP and the Design Team members.  The draft provides an excellent start on joint work on routing to support ASON.  We were able to do a thorough review of the draft at our meeting of February 16-20 and have a number of comments. We have noted the main comments below, and have also attached proposed clarification text for the draft.  We look forward to ongoing collaboration with you in the future.

 

 

                                     Hing-Kam Lam,

                                            Rapporteur, Q.14/15

 

 

 

Comments on <draft-ietf-ccamp-gmpls-ason-routing-reqts-02>:

 

1. Reviewing the introduction in Section 3, we believe the scope statement should be broadened somewhat by reference to G.805 as proposed in the attached text (this would, for example, then add PDH networks as well as SDH and OTN to the scope).

 

2. It was noted that the document has a section on backwards compatibility.  Backwards compatibility with existing routing protocols is not an ASON requirement nor is it a defined activity of the design team.  As the charter of the design team states that its output should reflect only ASON requirements, we believe that it is not appropriate for the backwards compatibility statement to be in the main text.  Recognizing that backwards compatibility is a valid requirement for protocol development, statements could be included in a non-normative appendix for use by CCAMP in further routing work. While backwards compatibility was not a formal requirement of ASON, it may be worth noting that the ASON architecture does provide a measure of protocol independence that may aid in backward compatibility. In particular, ASON does not specify the routing protocol used inside of routing control domains. This allows for routing protocol heterogeneity in an ASON network.

 

In discussion, however, there was agreement that any extensions to routing protocols developed for support of ASON routing must not result in interference with the routing of messages over the Signaling Communication Network (SCN), should it be the case that the same protocol (e.g., OSPF or IS-IS) is used for both ASON connection routing and SCN routing.

 

3. Some information regarding potential differences between control domains has been added for clarity. The definition of control domain and associated reference points should be consistent between the routing and signaling requirement drafts.

 

4. It was noted that section 3 on routing architecture that "a carrier's network" is given as the context.  We have implicitly assumed that carrier's networks are themselves components of a top-level routing area, so the actual context is "the network", including multiple carriers.

 

5. In that same section, it describes RCs as exchanging information "between" RAs.  In fact, there is no direct communication between peer RAs in a level, only via a higher level containing RA.

 

6. We have removed the term "routing domain", as it may cause confusion.

 

7. There was some confusion about how best to interpret the text describing the number of levels as being "protocol specific". Proposed clarified text has been provided in the attached document.

 

8. Later in the section it describes link and node diversity as a function expected from GMPLS routing.  Strictly speaking, diversity is considered a result of path computation and out of scope of ASON, i.e., not a requirement from ASON.

 

9. Finally in the end of the section it mentions security as a requirement.  As this is also not a formal requirement of ASON, this should also be moved to an Appendix.

 

10.  In Section 4 and later text, the term TE Link is assumed to be the GMPLS equivalent of SNPP link.  We have some concerns about potential differences between the concepts.  Q14 believes that the ASON SNPP link is a more general construct than a TE link in that it can consist of an arbitrary set of SNPs, not just those that belong to the same trail (i.e., physical link).  Although the TE link definition was expanded in draft-ietf-ccamp-gmpls-routing-09.txt to become more abstract, it still appears to be confined to labels (SNPs) associated with a common trail, that is similar to a G.853.1 "topological link".  Further it does not have a containment property to allow TE links to be contained within TE links.  Q14 would appreciate CCAMP's comment on this understanding of the definition of a TE link.

 

11.  In Section 4.1 it describes the ASON routing components as being identified by values that MAY be drawn from different spaces.  This is somewhat vague and additional text has been proposed in the attached document.

 

12.  We have removed the term "designated RC" from section 4.2.3, as this represents only one possible physical distribution.

 

13.  In section 4.5.2 we have modified the terminology in the last bullet according to recent resolution of comments on ITU-T Recommendation G.7715.1.

 

14.  In the Conclusions section, questions on "non-disruptive" came up.  Rather than using "non-disruptive" to describe the operations of segmentation, etc., it was noted that the main concern with non-disruptive operation is to prevent disruption of existing connection services.  We propose that text be added describe this as an additional requirement of ASON.

 

15.  The Conclusions raise issues concerning Reachability.  First, UNI Transport Resource Addresses are not required to be advertised.  If they are advertised by routing controllers, the same advertisement mechanism used for SNPP links is not required to be used.  Second, there may be IP formatted addresses used by L3 applications and functions, particularly on clients.  These are distinct and separate from SNPP names used for transport resources as well as UNI Transport Resource Addresses.  Their reachability is independent of transport addresses/names.

 

16. The Conclusions describe ASON as not restricting architecture choices.  As ASON itself defines the architecture, a more precise wording might be that ASON does not restrict the distribution of function.  Related wording changes are suggested in the attachment.

 

17. The Conclusions raise an issue concerning the GMPLS LSR concept and separation of function in ASON.  Without directly addressing the LSR concept, our conclusion is that ASON requires the ability to support separation of control and data plane entities and the ability to support different types of distribution of function.

 

Attachment: <wd34c-r1-_draft-ietf-ccamp-gmpls-ason-routing-reqts-02.doc> (Feb. 16-20, 2004)

Attachment can also be found at: ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/wp3/q14/0402/wd34c-r1-_draft-ietf-ccamp-gmpls-ason-routing-reqts-02.doc

________________