RE: Proposed response to OIF on OSPF ENNI

["MEURIC Julien RD-CORE-LAN" <julien.meuric@orange-ft.com>]

Hi all.

About the OSPF scope, I also have concern. As far as I know, OSPF is an
IGP, which brings 2 issues to my mind:
- OSPF has not been built as an EGP, so enlarging it to that scope must
be considered thoroughly;
- I really do not see the use of any link-state protocol for
inter-carrier applications.

Regards,

Julien


-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Brungard, Deborah A, ALABS

Hi Tomo,

Much thanks for the reply. I think this modification to remove the
limitation to intra-carrier was done in version -03. It has been
difficult to follow the different versions.

(CCAMP-Chair hat off/AT&T hat on)
I also have concern with use of a link state routing protocol as an
inter-carrier interface. 

Regards,
Deborah
 

-----Original Message-----
From: Tomohiro Otani [mailto: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-ev
al-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
>