|
Hi Deborah, Lyndon, et al., You mention: >> -- G.7715, G.7715.1 and the IETF
eval and solutions draft all identify a need to support hierarchical >> routing areas for ASON, I am
perplexed as to why this seems to be viewed as a new feature. > db> "significant" was
not based on "newness" as a feature, it was based on what GMPLS OSPF
can > support today. I’d like to point out that carrying
Opaque LSAs is not a new extension to OSPF. What is new here is the
import/export of GMPLS information between areas. Again, this can be done
(and has been done by current implementations) without any change to OSPF.
Again, I’d say that this is not significant. Regards, From: Brungard,
Deborah A, ALABS [mailto:dbrungard@att.com] below (noted as db>)... Lyndon, do you think the OIF document and
CCAMP's ASON Requirements and Evaluation document are aligned? Thanks, Deborah From: Ong,
Lyndon [mailto:Lyong@Ciena.com] Hi Deborah, Here's what I would say is in and not
in the OIF document: -- G.7715, G.7715.1 and the IETF eval and
solutions draft all identify a need to support hierarchical routing areas for ASON, I am perplexed as
to why this seems to be viewed as a new feature. db> "significant" was not
based on "newness" as a feature, it was based on what GMPLS OSPF can support
today. -- the document does not specify the
domain of usage and leaves this to the carrier. This is no different from G.7715.1 and IETF drafts that do not
explicitly state whether they are used for intra- or inter-domain interfaces. db> G.7715.1 is on requirements for
link state protocols - it does not define requirements for inter-carrier ENNI
routing protocols. And, I differ with your view on IETF documents, IETF
documents do specify. And this OIF document also specifies - Figure 1
shows it for use between Carriers. The document may "leave it to the
carrier", but OIF claims it can do. I would presuppose an
Implementation Agreement would properly scope the solution.
Inter-carrier was not included in the ASON-GMPLS routing
requirements. Do you think the same solution can be used inter-carrier? -- GMPLS OSPF does not support a 1:N or
N:1 relationship between routing controller and transport node, hence extensions are felt to be
required - and are proposed in the eval solutions draft. The conclusions are no different. db> GMPLS-ASON did not identify the
need to advertise and use in the ERO a transport plane name (OIF/section 4.2) -
unless OIF-speak for a TE Router is "transport plane name". The only
GMPLS-ASON identified need was if non-unique link IDs (e.g.
unnumbered) were supported, an optional TLV was identified which could
be used. Note, GMPLS links are not representing "data plane"
(RFC4394 provides a good mapping of terminology). And, this was not based
on the issue which OIF identified in section 4.2, "identifier namespaces
are merged together" in GMPLS. -- the document does not in fact define
any standard extensions to the protocols, and points to future work in IETF and ITU to provide these.
Therefore I cannot understand where you say "new extensions to OSPF are specified" and
"none...align with the CCAMP's GMPLS-ASON work". db> None of the identified "issues
for extensions" aligns, and none of the DDRP protocol elements listed in
the Appendix and used for prototype testing align. If the identified issues do
not align, how will IETF provide extensions? ITU future work? I think we're experiencing a significant
miscommunication... db> Agree;-) Cheers, Lyndon From:
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Brungard, Deborah A, ALABS Hi Jonathan, (and Lyndon), Thanks to both of you for responding. "Significant" was referencing: - supports a (new) hierarchical
OSPF model - supports inter-domain
(inter-carrier) OSPF (not supported by today's OSPF) - identifies namespace issues with GMPLS
OSPF which do not exist, and proposes extensions to "fix" - new extensions to OSPF are specified - none of the proposed extensions align
with CCAMP's GMPLS-ASON work Did you have another adjective to suggest?
We were thinking "significant" was rather soft considering
the above. Though if it's just ITU-speak differences, why does the OIF liaison
state it reflects several years of work including testing? Any insight
(alignment mapping to CCAMP's work) which you or Lyndon can provide would be
helpful. The divergence is baffling to us. Deborah From: Sadler, Jonathan
B. [mailto:Jonathan.Sadler@tellabs.com] Hi Deborah and Adrian, I haven’t seen much discussion of
the OIF E-NNI Routing document on the CCAMP list. Can you tell me what
parts of the document are “significant modifications to the operation of
OSPF”? Thanks, From:
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Brungard, Deborah A, ALABS Hi, We had a communication from OIF on their
OSPF ENNI specification. You can see the original files on http://www.olddog.co.uk/ccamp.htm. Having assembled comments from several people and our discussions
in Please comment on the list in the next
week. Thanks, Adrian and Deborah = = = = = = = = = = Dear Jim, We thank you for sending us the OIF ENNI document in response to our
request. While we appreciate the document being provided for information, it is
concerning that this document has not been previously shared with CCAMP or the
OSPF WG considering the document contains significant modifications to the
operation of OSPF and reflects OIF work over the last several years. CCAMP has
been working on GMPLS ASON for several years and our Design Teams include OIF
participants. Even though a reply was not requested, we are replying, as we
strongly recommend that the document not be published for public information in
its current form. Of most concern to CCAMP is that it is not aligned with RFC 4258
(Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing
for the Automatically Switched Optical Network (ASON)) or the to-be-published: ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt.
Considering notable OIF participants are authors of both these IETF documents
(and the same participants are contributors and the Editor for the OIF
document), the non-alignment is perplexing. Considering the IETF document is
ready for publication, we suggest in the interests of time, that you align your
document with the IETF document. If any questions on the interpretation of the
IETF’s work, we recommend that you either utilize the CCAMP mail exploder
or send a communication. Specific comments include: 1. What
is the intent of this document? Will it be published as an Implementation
Agreement (IA)? 2.
The list of changes from the previous version (listed under
the Table of Contents) includes “removed
“intra-carrier” limitation” and the inclusion of
Figure 1 showing the OSPF ENNI for use between vendor domains and between
carrier domains. GMPLS OSPF-TE already supports inter-vendor operations. 3. Section
4.1/Table 1 and the statement under the table identifying issues with GMPLS
identifier namespaces are not correct. GMPLS identifier namespaces do meet ASON
requirements for namespace separation of the transport plane and control plane
(Section 5.2 and 5.3/Evaluation). Perhaps you are confusing OSPF and GMPLS
OSPF? As you also identified in your liaison that the key area needing review
was the support of independence of functional component to physical location,
this appears to be a key area of misunderstanding on GMPLS. We recommend
reviewing RFC3945 (GMPLS Architecture) to understand that the key architecture
difference between GMPLS and MPLS is the decoupling of the transport plane and
control plane. Additionally, RFC4394, RFC4397, and RFC4258, provide a mapping
to ITU terminology which may be helpful reading. We request an additional round of communication of this document to the
IETF before approval to allow us to work with you to produce convergence between
OIF and IETF work which, we believe, will be in the best interests of the
industry. Best regards, CCAMP co-chairs ============================================================The information contained in this message may be privilegedand confidential and protected from disclosure. If the readerof this message is not the intended recipient, or an employeeor agent responsible for delivering this message to theintended recipient, you are hereby notified that any reproduction,dissemination or distribution of this communication is strictlyprohibited. If you have received this communication in error,please notify us immediately by replying to the message anddeleting it from your computer. Thank you. Tellabs======================================================================================================================== The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ |