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
________________