Subject: RE: Proposed response to OIF on OSPF ENNI

From: "Sadler, Jonathan B." <[email-masked]>
Date: Mon, 24 Jul 2006 15:31:55 -0500

Hi Deborah, Lyndon, et al,

Some additional comments:

 - The hierarchical model discussed in the draft IA liaised may be
supported without any modifications to OSPF.  As discussed in earlier
emails, it can be implemented solely through the import/export of
information described in Appendix I of G.7715.

 - The draft IA also recognizes namespace issues exist between Router ID
and the IP Address that messages are sent to (ITU calls this the RC PC
SCN address).  This issue is also discussed in
draft-ietf-ccamp-gmpls-addressing.

Given that:

-          CCAMP has a milestone to publish an ASON routing solution by
Nov 2006, 

-          CCAMP didn't have at the time this was liaised (doesn't have
today?) a working group document, and

-          the draft IA has been successfully implemented by more than a
dozen vendors and interop-tested many times,

I would expect that we should be looking at this as experience/text that
could be leveraged...  "Running code..." and all that...

Regards,

Jonathan Sadler

________________________________

From: Ong, Lyndon [mailto:[email-masked]] 
Sent: Monday, July 24, 2006 2:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

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.

-- 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.

-- 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.

-- 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".

I think we're experiencing a significant miscommunication...

Cheers,

Lyndon

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

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:[email-masked]] 
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

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,

Jonathan Sadler

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI

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
<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

============================================================
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
============================================================
============================================================
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
============================================================

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Mon, 24 Jul 2006 16:31:17 -0500

Hi Jonathan,
 
I just sent mail to Lyndon to ask if he felt CCAMP's work was aligned.
From your mail below, you do believe that CCAMP's ASON requirements
document and evaluation document meet the needs of OIF? As the OIF
Liaison stated it specified requirements, we do want to ensure that the
work is aligned.
 
Thanks,
Deborah

From: Sadler, Jonathan B. [mailto:[email-masked]] 
Sent: Monday, July 24, 2006 4:32 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Given that:

Regards,

Jonathan Sadler

Hi Deborah,

interfaces.

 

Cheers,

Lyndon

Deborah

Hi Deborah and Adrian,

Thanks,

Jonathan Sadler

Hi,

Thanks,

Adrian and Deborah

= = = = = = = = = =

Dear Jim,

Best regards,

CCAMP co-chairs

---

From: [email-masked]
Date: Tue, 25 Jul 2006 12:18:29 +0200

jonathan & lyndon

o) During Dallas CCAMP meeting, IETF 66, we have had the following 
discussion (extracted from the meeting minutes) 

"Kireeti: What would make me happy is not to have extensions defined in 
IAs 
         Work has been done in the IETF. Instead, we will have objects in 
the specs and IAs 
         Putting the extensions in an informational appendix is still 
confusing, especially 
         as vendors have implemented them for demos 
         I would prefer that you just point to IETF so as extensions 
evolve in the IETF, you 
         stay coordinated 
Jim: We [the OIF] don't think that differently 
     One of our goals is to align and converge. 
     We understand we are using experimental codepoints" 

so, it is rather unclear why there is so much hubub when IETF proposes to 
achieve this objective ? if i well understand your opinion is that IETF 
should not target this objective ? let's assume this is the case, it still 
does not allow OIF to bypass the MPLS-GMPLS change process 

o) concerning the alignment of IETF vs G.7715 and G.7715.1, from the IETF 
liaison webpage you will see that a set of exchanges between bodies has 
been conducted to ensure such alignment; however, as ITU should be 
defining ASON routing requirements your statement "I cannot say that they 
are aligned with the requirements of the OIF" is totally unclear to me. 
Does OIF has its own requirements or are OIF requirements not fully 
aligned with ITU G.7715/.1 ? This question should be reflected in the 
liaison to OIF - as a CLEAR response from OIF will surely help sorting the 
present situation 

o) what is the real "issue" by pointing to the addressing i-d, the latter 
just provides recommendation in case of 1:1 corr. between data and control 
plane entities; i thought ASON was looking at larger scope - so what's the 
point beside trying to mis-use any IETF production to corroborate the 
GMPLS OSPF digression of Section 4.1 of the OIF IA ?

o) the tone of the OIF IA is its first sections is totally inappropriate 
and misleading - so requires major revision - by reading one got the 
impression by reading that a) OIF puts premises of a new protocol 
recommendation while also stating it is a demo code reporting for a single 
level - this must be seriously revisited b) OIF has apparently discovered 
major holes and flaws, while issue is limited to unnumbered links with 
overlapping ID space per TE Router ID (as detailed in section 5.7 of the 
eval doc) - alignment on these aspect(s) is also more than recommended 
imho 

o) at the end, the major concern is that it is totally unclear what the 
purpose of the OIF IA OSPF extensions are, if the intention of OIF is to 
push them outside OIF demo scope (which seems to be the case since the 
document passes through OIF ballot process and thus will be openly 
available after this phase), then de-facto it is an OIF dutty to ask IETF 
for in-depth revision and full alignment before publication 

ps: to achieve a standard you need running code, but not any running code 
becomes a standard even informational (hopefully);

-d.

"Sadler, Jonathan B." <[email-masked]>
Sent by: [email-masked]
24/07/2006 22:31
 
        To:     "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong, 
Lyndon" <[email-masked]>, <[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Some additional comments:
 - The hierarchical model discussed in the draft IA liaised may be 
supported without any modifications to OSPF.  As discussed in earlier 
emails, it can be implemented solely through the import/export of 
information described in Appendix I of G.7715.
 - The draft IA also recognizes namespace issues exist between Router ID 
and the IP Address that messages are sent to (ITU calls this the RC PC SCN 
address).  This issue is also discussed in 
draft-ietf-ccamp-gmpls-addressing.
 
Given that:
-          CCAMP has a milestone to publish an ASON routing solution by 
Nov 2006, 
-          CCAMP didn’t have at the time this was liaised (doesn’t have 
today?) a working group document, and
-          the draft IA has been successfully implemented by more than a 
dozen vendors and interop-tested many times,
I would expect that we should be looking at this as experience/text that 
could be leveraged...  “Running code…” and all that…
 
Regards,
 
Jonathan Sadler

Hi Deborah,

 

-- 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". 

Cheers,
 
Lyndon

From: [email-masked] [mailto:[email-masked]] On Behalf 
Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI
Hi Jonathan, (and Lyndon),

 
 
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

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,
 
Jonathan Sadler

From: [email-masked] [mailto:[email-masked]] On Behalf 
Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI
 
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.

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,

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 25 Jul 2006 12:55:35 -0400

Hi Dimitri,

I completely agree with you that there is much unnecessary hubbub
going on.  The document does in fact point to IETF (and ITU) for
standard extensions to the routing protocols.

From the discussion I have the sense that there is some unhappiness with
the
document focusing on requirements that are still in the process of being

addressed within CCAMP, but since it points to the drafts being done
here
if anything it should focus reader's attention on the work here in CCAMP
rather than anywhere else.  

Cheers,

Lyndon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Tuesday, July 25, 2006 3:18 AM
To: Sadler, Jonathan B.; Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
[email-masked]
Subject: RE: Proposed response to OIF on OSPF ENNI

jonathan & lyndon

         Work has been done in the IETF. Instead, we will have objects
in the specs and IAs 

so, it is rather unclear why there is so much hubub when IETF proposes
to achieve this objective ? if i well understand your opinion is that
IETF should not target this objective ? let's assume this is the case,
it still does not allow OIF to bypass the MPLS-GMPLS change process 

o) concerning the alignment of IETF vs G.7715 and G.7715.1, from the
IETF liaison webpage you will see that a set of exchanges between bodies
has been conducted to ensure such alignment; however, as ITU should be
defining ASON routing requirements your statement "I cannot say that
they are aligned with the requirements of the OIF" is totally unclear to
me. 
Does OIF has its own requirements or are OIF requirements not fully
aligned with ITU G.7715/.1 ? This question should be reflected in the
liaison to OIF - as a CLEAR response from OIF will surely help sorting
the present situation 

o) what is the real "issue" by pointing to the addressing i-d, the
latter just provides recommendation in case of 1:1 corr. between data
and control plane entities; i thought ASON was looking at larger scope -
so what's the point beside trying to mis-use any IETF production to
corroborate the GMPLS OSPF digression of Section 4.1 of the OIF IA ?

o) the tone of the OIF IA is its first sections is totally inappropriate
and misleading - so requires major revision - by reading one got the
impression by reading that a) OIF puts premises of a new protocol
recommendation while also stating it is a demo code reporting for a
single level - this must be seriously revisited b) OIF has apparently
discovered major holes and flaws, while issue is limited to unnumbered
links with overlapping ID space per TE Router ID (as detailed in section
5.7 of the eval doc) - alignment on these aspect(s) is also more than
recommended imho 

o) at the end, the major concern is that it is totally unclear what the
purpose of the OIF IA OSPF extensions are, if the intention of OIF is to
push them outside OIF demo scope (which seems to be the case since the
document passes through OIF ballot process and thus will be openly
available after this phase), then de-facto it is an OIF dutty to ask
IETF for in-depth revision and full alignment before publication 

ps: to achieve a standard you need running code, but not any running
code becomes a standard even informational (hopefully);

-d.

"Sadler, Jonathan B." <[email-masked]> Sent by:
[email-masked]
24/07/2006 22:31

 
 
Given that:

dozen vendors and interop-tested many times, I would expect that we
should be looking at this as experience/text that could be leveraged...
"Running code..." and all that...
 
Regards,
 
Jonathan Sadler

Hi Deborah,

-- 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.
 
-- 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.
 
-- 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.
 
-- 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". 

Cheers,
 
Lyndon

Subject: RE: Proposed response to OIF on OSPF ENNI Hi Jonathan, (and
Lyndon),

 
 
"significant" 
 
Deborah

From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI Hi Deborah and
Adrian,

Thanks,
 
Jonathan Sadler

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.

Thanks,
Adrian and Deborah
 
= = = = = = = = = =
Dear Jim,

al-03.txt
the interpretation of the IETF's work, we recommend that you either
 
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.

Best regards,
Adrian Farrel and Deborah Brungard,
CCAMP co-chairs
============================================================
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
============================================================
============================================================
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
============================================================

---

From: [email-masked]
Date: Tue, 25 Jul 2006 19:54:23 +0200

lyndon - indeed this is mentioned - the concern here can be formulated as 
follows: section 1.2 of the OIF IA is unclear about positioning and exact 
intention with the proposed extensions (in Appendix) 

"These extensions use codepoints in the range reserved by IANA for private 
and experimental use, and are not agreed standard codepoints at this time. 
Future developments may result in change to the codepoints and/or formats 
of these extensions." 

you wrote: "the statement on codepoints in the appendix was not intended 
as a statement that the prototype codepoints are expected to become 
standard; it is recognized that IETF (and ITU) are the 
standards-generating bodies. This was a general statement allowing for 
changes or extensions in future experimental activities."

the fact that the sentence combines "at this time" and points to potential 
"standard codepoints" means that we have to warn OIF about implication 
i.e. if OIF intents to change their status (toward standard codepoints) 
then the extensions will be de-facto subject to the MPLS/GMPLS change 
process from the IETF perspective

ps: this is also the reason why there is a direct relationship between 
objective of the document (see previous post) and listed extensions -

"Ong, Lyndon" <[email-masked]>
Sent by: [email-masked]
25/07/2006 18:55
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Sadler, 
Jonathan B." <[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>, 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, 
<[email-masked]>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Dimitri,

Cheers,

Lyndon

-----Original Message-----

jonathan & lyndon

-d.

 
 
Given that:

Regards,
 
Jonathan Sadler

Hi Deborah,

 

 
 
Cheers,
 
Lyndon

 

 
Deborah

 
Thanks,
 
Jonathan Sadler

Hi,

 
Thanks,
Adrian and Deborah
 
= = = = = = = = = =
Dear Jim,

 

Best regards,

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 25 Jul 2006 14:01:14 -0400

Hi Dimitri,

Well, they could of course become agreed standard codepoints if
CCAMP adopted them (unlikely as that appears to be given the past
history of CCAMP and any protocol proposals made by other bodies)
hence "at this time" seemed like a required note.

OIF would of course be very happy if CCAMP agreed to adopt the
formats that were implemented during OIF prototype testing,
this is still possible :o)

Cheers,

Lyndon 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Tuesday, July 25, 2006 10:54 AM
To: Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
Sadler, Jonathan B.; [email-masked]
Subject: RE: Proposed response to OIF on OSPF ENNI

lyndon - indeed this is mentioned - the concern here can be formulated
as
follows: section 1.2 of the OIF IA is unclear about positioning and
exact intention with the proposed extensions (in Appendix) 

"These extensions use codepoints in the range reserved by IANA for
private and experimental use, and are not agreed standard codepoints at
this time. 
Future developments may result in change to the codepoints and/or
formats of these extensions." 

the fact that the sentence combines "at this time" and points to
potential "standard codepoints" means that we have to warn OIF about
implication i.e. if OIF intents to change their status (toward standard
codepoints) then the extensions will be de-facto subject to the
MPLS/GMPLS change process from the IETF perspective

 

Hi Dimitri,

Cheers,

Lyndon

-----Original Message-----

jonathan & lyndon

-d.

 
 
Given that:

Regards,
 
Jonathan Sadler

Hi Deborah,

 

 
 
Cheers,
 
Lyndon

 

 
Deborah

 
Thanks,
 
Jonathan Sadler

Hi,

 
Thanks,
Adrian and Deborah
 
= = = = = = = = = =
Dear Jim,

 

Best regards,

---

From: [email-masked]
Date: Tue, 25 Jul 2006 20:11:16 +0200

lyndon - see my reply to jonathan on this specific point - 

i can sum'up the evaluation phases lead to different premises and ext. 
guidelines (in addition to the specific OIF reachability information 
encoding) hence, these extensions are not reconcilable without 
reconsidering the protocol evaluation itself - it is the basic reason why 
i have been so scrupulous in driving this evaluation work as accurate as 
possible - and the reason why the proposed liaison text directly referred 
to this Section 4.1

ps: could you answer to my previous post ? on OIF IA scope

25/07/2006 20:01
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <[email-masked]>, 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, 
"Sadler, Jonathan B." <[email-masked]>, 
<[email-masked]>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Dimitri,

Cheers,

Lyndon 

-----Original Message-----

 

Hi Dimitri,

Cheers,

Lyndon

-----Original Message-----

jonathan & lyndon

-d.

 
 
Given that:

Regards,
 
Jonathan Sadler

Hi Deborah,

 

 
 
Cheers,
 
Lyndon

 

 
Deborah

 
Thanks,
 
Jonathan Sadler

Hi,

 
Thanks,
Adrian and Deborah
 
= = = = = = = = = =
Dear Jim,

 

Best regards,

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 25 Jul 2006 17:10:42 -0400

Hi Dimitri,

Regarding the scope, I don't think the scope is that complicated.
However, I will reflect to OIF that there is confusion about the scope
of the document and as editor will see what I
can do to help clarify these. 

Cheers,

Lyndon

-----Original Message-----
Sent: Tuesday, July 25, 2006 11:11 AM

i can sum'up the evaluation phases lead to different premises and ext. 
guidelines (in addition to the specific OIF reachability information
encoding) hence, these extensions are not reconcilable without
reconsidering the protocol evaluation itself - it is the basic reason
why i have been so scrupulous in driving this evaluation work as
accurate as possible - and the reason why the proposed liaison text
directly referred to this Section 4.1

 

Hi Dimitri,

Well, they could of course become agreed standard codepoints if CCAMP
adopted them (unlikely as that appears to be given the past history of
CCAMP and any protocol proposals made by other bodies) hence "at this
time" seemed like a required note.

OIF would of course be very happy if CCAMP agreed to adopt the formats
that were implemented during OIF prototype testing, this is still
possible :o)

Cheers,

Lyndon 

-----Original Message-----

 

Hi Dimitri,

Cheers,

Lyndon

-----Original Message-----

jonathan & lyndon

-d.

 
 
Given that:

Regards,
 
Jonathan Sadler

Hi Deborah,

 

 
 
Cheers,
 
Lyndon

 

 
Deborah

 
Thanks,
 
Jonathan Sadler

Hi,

 
Thanks,
Adrian and Deborah
 
= = = = = = = = = =
Dear Jim,

 

Best regards,

---

From: Richard Rabbat <[email-masked]>
Date: Tue, 25 Jul 2006 14:25:52 -0700

Hi Jonathan,
quick comment inline

Sadler, Jonathan B. wrote:
> - The draft IA also recognizes namespace issues exist between Router 
> ID and the IP Address that messages are sent to (ITU calls this the RC 
> PC SCN address). This issue is also discussed in 
Can you please elaborate on the issue discussed in the addressing draft? 
Which section are you talking about?
The goal of the draft in the abstract says:

   ... The aim 
   of this document is to facilitate and ensure better interworking of 
   GMPLS-capable Label Switching Routers (LSRs) based on experience 
   gained in deployments and interoperability testing and proper 
   interpretation of published RFCs. 

and the introduction:

   ... GMPLS supports a 
   control entity that is responsible for one or more data plane 
   entities, but for the purposes of this document, it is assumed that 
   there is a one-to-one correspondence between control plane and data 
   plane entities. 

Is this what you are referring to?
Thanks,
Richard.
>
> Given that:
>
> - CCAMP has a milestone to publish an ASON routing solution by Nov 2006,
>
> - CCAMP didn’t have at the time this was liaised (doesn’t have today?) 
> a working group document, and
>
> - the draft IA has been successfully implemented by more than a dozen 
> vendors and interop-tested many times,
>
> I would expect that we should be looking at this as experience/text 
> that could be leveraged... “Running code…” and all that…
>
> Regards,
>
> Jonathan Sadler
>
> ------------------------------------------------------------------------
>
> *From:* Ong, Lyndon [mailto:[email-masked]]
> *Sent:* Monday, July 24, 2006 2:33 PM
> *To:* Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
> *Cc:* Adrian Farrel
> *Subject:* RE: Proposed response to OIF on OSPF ENNI
>
> Hi Deborah,
>
> -- 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.
>
> -- 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.
>
> -- 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
>
> ------------------------------------------------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Brungard, Deborah A, ALABS
> *Sent:* Monday, July 24, 2006 12:15 PM
> *To:* Sadler, Jonathan B.; [email-masked]
> *Cc:* Adrian Farrel
> *Subject:* RE: Proposed response to OIF on OSPF ENNI
>
> "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:[email-masked]]
> *Sent:* Friday, July 21, 2006 11:34 AM
> *To:* Brungard, Deborah A, ALABS; [email-masked]
> *Cc:* Adrian Farrel
> *Subject:* RE: Proposed response to OIF on OSPF ENNI
>
> 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,
>
> Jonathan Sadler
>
> ------------------------------------------------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Brungard, Deborah A, ALABS
> *Sent:* Friday, July 21, 2006 9:38 AM
> *To:* [email-masked]
> *Cc:* Adrian Farrel
> *Subject:* Proposed response to OIF on OSPF ENNI
>
> Hi,
>
> 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.
>

> 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.
>
> 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.
>
> 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 
> 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.//
>
> identifier namespaces do meet ASON requirements for namespace 
> 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,
>

---

From: [email-masked]
Date: Wed, 26 Jul 2006 00:29:25 +0200

lyndon - this would really be helpful - this said the point is not only 
editorial there is an implication as indicated in my previous e-mail

if this OIF IA targets more than documenting demo codepoints (experimental 
work remaining at that status), there is a need to warn OIF about 
implications i.e. if OIF intents to change the status of this doc. then 
the extensions will be de-facto subject to the MPLS/GMPLS change process 
from the IETF perspective

i would like to see this point included in the liaison text because 
leaving OIF unaware of such process may leave OIF audience uaware of rule 
change from what they knew when OIF UNI signaling was conducted in 2001, 
as of today having demo code doesn't leave the possibility to ask for std 
codepoints w/o passing through the complete MPLS/GMPLS change process
 
thanks,
- d.

25/07/2006 23:10

Hi Dimitri,

Cheers,

Lyndon

-----Original Message-----

 

Hi Dimitri,

Cheers,

Lyndon 

-----Original Message-----

 

Hi Dimitri,

Cheers,

Lyndon

-----Original Message-----

jonathan & lyndon

-d.

 
 
Given that:

Regards,
 
Jonathan Sadler

Hi Deborah,

 

 
 
Cheers,
 
Lyndon

 

 
Deborah

 
Thanks,
 
Jonathan Sadler

Hi,

 
Thanks,
Adrian and Deborah
 
= = = = = = = = = =
Dear Jim,

 

Best regards,

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 25 Jul 2006 18:39:31 -0400

I have no objection to this, although I think people know this already.

Lyndon 

-----Original Message-----
Sent: Tuesday, July 25, 2006 3:29 PM

if this OIF IA targets more than documenting demo codepoints
(experimental work remaining at that status), there is a need to warn
OIF about implications i.e. if OIF intents to change the status of this
doc. then the extensions will be de-facto subject to the MPLS/GMPLS
change process from the IETF perspective

i would like to see this point included in the liaison text because
leaving OIF unaware of such process may leave OIF audience uaware of
rule change from what they knew when OIF UNI signaling was conducted in
2001, as of today having demo code doesn't leave the possibility to ask
for std codepoints w/o passing through the complete MPLS/GMPLS change
process
 
thanks,
- d.

Hi Dimitri,

Regarding the scope, I don't think the scope is that complicated.
However, I will reflect to OIF that there is confusion about the scope
of the document and as editor will see what I can do to help clarify
these. 

Cheers,

Lyndon

-----Original Message-----

 

Hi Dimitri,

Cheers,

Lyndon 

-----Original Message-----

 

Hi Dimitri,

I completely agree with you that there is much unnecessary hubbub going
on.  The document does in fact point to IETF (and ITU) for standard
extensions to the routing protocols.

From the discussion I have the sense that there is some unhappiness with
the document focusing on requirements that are still in the process of
being

addressed within CCAMP, but since it points to the drafts being done
here if anything it should focus reader's attention on the work here in
CCAMP rather than anywhere else. 

Cheers,

Lyndon

-----Original Message-----

jonathan & lyndon

-d.

 
 
Given that:

Regards,
 
Jonathan Sadler

Hi Deborah,

 

 
 
Cheers,
 
Lyndon

 

 
Deborah

 
Thanks,
 
Jonathan Sadler

Hi,

 
Thanks,
Adrian and Deborah
 
= = = = = = = = = =
Dear Jim,

 

Best regards,

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 26 Jul 2006 14:43:42 +0100

> Which section are you talking about?

This is actually very important.

I have just re-read the draft and I do not find any such text discussing any 
real or imagined namespace issues.

If the draft gives the false impression that there is some major issue with 
GMPLS namespaces I hope Jonathan will highlight the text so that it can be 
removed.

Thanks,
Adrian