|
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: |
Liaison Statement
To IETF CCAMP WG on <draft-ietf-ccamp-gmpls-ason-reqts-05.txt> |
|||
|
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,
In
addition to documents liaised from CCAMP to Q14/15, the document
<draft-ietf-ccamp-gmpls-ason-reqts-05.txt> was also reviewed in the Feb.
16-20 meeting. We have noted the main
comments below, and have also attached proposed clarification text for the
draft. Comments within the attachment
are in italics and additions/deletions are noted in the markup indicators. We look forward to ongoing collaboration
with you in the future.
Hing-Kam Lam,
Rapporteur,
Q.14/15
Comments on the draft <draft-ietf-ccamp-gmpls-ason-reqts-05.txt>:
1. We recognize that this document is not chartered to be strictly ASON requirements, as is the corresponding document on ASON routing requirements. Our review focuses on identifying where stated requirements should be understood to be IETF rather than ASON-derived as well as where stated requirements differ from ASON or where we believe requirements need to be added to reflect ASON architecture.
2. Section 3 Introduction. ASON extends to additional technologies, esp. future connection-oriented layer networks based on G.805.
3. Section 3 Introduction. Backwards compatibility should be understood to be an IETF-derived requirement and not an ASON-derived requirement. CCAMP requirements for backwards compatibility should be distinctly denoted.
4. Section 3 Introduction. In this section it characterizes reference points as points of protocol exchange. It should be noted that a reference point should not be assumed to correspond to a physical interface (see G.8080 Amend. 1 for appropriate text)
5. Section 3 Introduction. It should be noted that ASON defines a set of functional components that imply functionality and flexibility that should be supportable and is not limited to the list of functions (a-g) given in the draft. For example, ASON allows flexibility of distribution of call control and connection control (such as centralized vs. distributed). It would be helpful for the draft to state any assumptions made along these lines, e.g., GMPLS supports distributed connection control.
6. Section 4 Requirements. The statement that functions should be "agnostic to any UNI” is somewhat confusing. We interpret this to mean that the solution should be capable of supporting both ITU-T-based UNI (G.7713.2) and other UNIs such as GMPLS Overlay. There is no ASON-derived requirement related to this.
7. Section 4 Requirements. The statement "interworking aspects…are strictly the responsibility of the non-GMPLS control domain" is again somewhat confusing. We interpret this to mean that protocol translation at a node between a GMPLS I-NNI interface and a non-GMPLS I-NNI interface should not require GMPLS to support added functionality, and there is no intention for GMPLS to support this. This is also not an ASON requirement.
8. Section 4 Requirements. It should be noted that the E-NNI reference point can be instantiated by a carrier for a variety of reasons, including management/policy and administrative reasons, and is not strictly defined (or required) for protocol or vendor interworking boundaries. It could be required, for example, to introduce call management functionality to handle differences such as different namespaces, even when the same protocol is used as I-NNIs on both sides. The draft does not discuss support of the E-NNI, although this should be considered an ASON-derived requirement as well as support of the UNI.
9. The draft provides insufficient description of G.8080 UNI Transport
Resource Address support (esp. the potential for this to be a non-Ipv4 or Ipv6
address)
10. Separation of control plane and data plane should be clearer in the
document, especially when referring to identifiers.
11. G.8080 defines the ASON
control plane as applying to a single layer.
Some examples in the draft involve multiple layers. While not precluded by implementations, a
suggested replacement example is contained in the marked up copy that is single
layer.
Attachment: <wd35c-draft-ietf-ccamp-gmpls-ason-reqts-05.doc> (Feb.
16-20, 2004)
Attachment
can also be found at:
________________