Re: Proposed response to OIF on OSPF ENNI

[Tomohiro Otani <otani@kddilabs.jp>]

Hi Deborah,

In terms of 3, I agree with the description.  As far as I understand,
OIF is looking at intra-domain inter-vendor specification as
their E-NNI signaling & routing.  I have not caught up with the
modification. I think it is not appropriate for us to use the link
state based protocol as an inter-carrier interface of optical networks.

Regards,

tomo





Brungard, Deborah A, ALABS wrote:
> 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 
> Montreal, we have put together the following response.
>  
> 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)?
> The title indicates it will be an Implementation Agreement on GMPLS OSPF 
> extensions, but the main body of the document is a list of issues with 
> GMPLS OSPF. Further, your communication to us stated the document was 
> requirements on and use of OSPF-TE at the ENNI. These three views seem 
> to be inconsistent.
> 
> /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.
> The IETF’s GMPLS ASON routing focus has been on the use of a link-state 
> based protocol to support a hierarchical routing architecture (G.7715.1) 
> within a carrier’s domain. Requirements for using a link state protocol 
> as an inter-domain protocol between carriers are significantly 
> different. We strongly disagree if you intend to publish this document 
> as an inter-carrier OSPF ENNI Implementation Agreement claiming 
> alignment with IETF RFCs without review (or agreement) by any of the 
> IETF Working Groups.//
> 
> 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,
> 
> Adrian Farrel and Deborah Brungard,
> 
> CCAMP co-chairs
>