Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

From: [email-masked]
Date: Thu, 15 Sep 2011 12:47:51 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks
	Author(s)       : Young Lee
                          Greg M. Bernstein
	Filename        : draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
	Pages           : 14
	Date            : 2011-09-15

   This document provides GMPLS OSPF routing enhancements to support
   signal compatibility constraints associated with WSON network
   elements. These routing enhancements are required in common optical
   or hybrid electro-optical networks where not all of the optical
   signals in the network are compatible with all network elements
   participating in the network.

   This compatibility constraint model is applicable to common optical
   or hybrid electro optical systems such as OEO switches, regenerators,
   and wavelength converters since such systems can be limited to
   processing only certain types of WSON signals.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

---

From: Leeyoung <[email-masked]>
Date: Thu, 15 Sep 2011 19:59:22 +0000

Hi all,

After 05 version publication, Acee provided a number of valuable comments and suggestions. This revision (06) reflects those changes. Please note the following updates:

- Change the title of the draft to "GMPLS OSPF Enhancement..." from "OSPF Enhancement..." to make sure the changes apply to the GMPLS OSPF rather than the base OSPF. 

- Add specific OSPF procedures on how sub-TLVs are packaged per [RFC3630] and editorial change including avoiding "multiple instances of TE LSA" to "multiple TE LSAs". 

Your comments are always appreciated. Thanks.

Best Regards.
Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, September 15, 2011 2:48 PM
To: [email-masked]
Cc: [email-masked]
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Tue, 27 Sep 2011 10:28:23 +0200

Hi Young, and CCAMPers,

I was off the mailing lists for the last two weeks and being back I notice a lot of exchanges, which I'm very glad of.
I've also noticed many drafts have been updated.
Concerning this specific draft-ietf-ccamp-wson-signal-compatibility-ospf-06, I wanted to comment section 3.
Back in Quebec, I expressed my point of view (shared with Cyril, Julien and Giovanni) that current drafts were lacking guidance regarding the way to design LSAs that were to depict an WSON node with OEOs.
This section 3 provides additional material to help designing the LSA.
I would like to know whether authors are willing to pursue further in this direction, which is to my mind a real corner stone, that would help everyone agree on a solution.
A first point could concern the Resource Block Information (reminder: <ResourceBlockInfo> ::= ([<ResourceSet>] <InputConstraints> <ProcessingCapabilities> <OutputConstraints>):
     We all agree that these information are static, that we should not replicate this TLV whatever the number not the layout of OEO boards of a given type.
Then, we could dedicate a specific independant flooding entity. This would be defined once for all, and that would not leave room to different interpretations.
What about this first point?

Regards,

Pierre

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Leeyoung
Envoyé : jeudi 15 septembre 2011 21:59
À : [email-masked]
Objet : Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Hi all,

Best Regards.
Young

---

From: Leeyoung <[email-masked]>
Date: Tue, 27 Sep 2011 22:06:00 +0000

Hi Pierre, 

Please see-inline for my reply to your first point. 

Regards,
Young

-----Original Message-----
From: PELOSO, PIERRE (PIERRE) [mailto:[email-masked]] 
Sent: Tuesday, September 27, 2011 3:28 AM
To: Leeyoung; [email-masked]
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Hi Young, and CCAMPers,

YOUNG>> If I understand you correctly, what you are saying is since the Resource Block Info sub-TLV is very static in nature, advertisement of this sub-TLV should be treated differently from the rest of static-TLVs (which may change over time). Is this what you are saying?

If my interpretation of your comment is correct, 

- The current mechanism allows what you want: Please see the first paragraph in Section 3.2
   "In the highly unlikely event that a WSON sub-TLV by itself would
   result in an LSA exceeding the MTU, all five WSON specific sub-TLVs
   in this document provide mechanisms that allow them to be subdivided
   into smaller sub-TLVs that can be sent in separate OSPF TE LSAs."

According to this clause, you can separate the Resource Block Info Sub-TLV as the sole entry defined in the Optical Node property TLV in a separate TE LSA from the rest if you will. Nothing prevents this particular way of packaging. (Isn't this what you meant "a specific independent flooding entity"?) 

- Please let me know if this explanation satisfies you. Thanks --- Young

Regards,

Pierre

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Leeyoung
Envoyé : jeudi 15 septembre 2011 21:59
À : [email-masked]
Objet : Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Hi all,

Best Regards.
Young

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Fri, 30 Sep 2011 16:39:02 +0200

Hi Young, 

I understand the content of your answer, but I'm not satisfied with it.
My concern deals with providing a unique reading/interpretation of the OSPF-TE extensions.
We would like to make sure that any implementation complying to the drafts would provide the same LSAs when applied to the same network.
With this perspective in mind, we wish to get drafts with sufficient documentation to make sure the LSA design process to be depicted, by design rules.

Hence the content of your answer leaving me the "opportunity to do as I wish", is not pleasing me, I would rather have strict rules, and discussions with the WG on the design of those.
That is why a first design rule, we could agree on is: to gather the Resource Block Information TLVs inside a dedicated LSA, possibly with a dedicated top-level TLV (which in my mind allows to enforce this design rule).

Regards,

- Pierre

-----Message d'origine-----
De : Leeyoung [mailto:[email-masked]] 
Envoyé : mercredi 28 septembre 2011 00:06
À : PELOSO, PIERRE (PIERRE); [email-masked]
Objet : RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Hi Pierre, 

Regards,
Young

-----Original Message-----
From: PELOSO, PIERRE (PIERRE) [mailto:[email-masked]]
Sent: Tuesday, September 27, 2011 3:28 AM
To: Leeyoung; [email-masked]
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Hi Young, and CCAMPers,

Regards,

Pierre

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Leeyoung Envoyé : jeudi 15 septembre 2011 21:59 À : [email-masked] Objet : Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Hi all,

Best Regards.
Young

---

From: Leeyoung <[email-masked]>
Date: Fri, 30 Sep 2011 21:16:00 +0000

Hi Pierre,

I got your point. Let me ask you this question. In the current GMPLS OSPF TE Link TLV are defined under Opaque TE LSA with the following attributes:

- TE Metric
- max B/W
- max reservable b/w
- unreserved b/w
- Admin Group
- Link Protection Type
- SRLG
- ISCD
- etc.

And these are a mixture of static and dynamic information and yet they are assembled together as one TE Link TLV. For instance the ISCD is quite similar to Resource Block Info in that it does not change often unless there are new elements added in the node or configuration changes and yet it is packaged together with other dynamic information. 

Why? 

There are many ways to keep static/unchanged information from being flooded. Only the Link Type and Link ID which are mandatory in the TE Link TLV per RFC3630. All other sub-TLV are optional and may occur at most once (when there are enough changes from the previous period that deserve an update) and need not be included in the TE Link TLV when there is no need for updating. 

I really don't see the need for a separate top-level TLV and/or a separate LSA for the Resource Block information. 

Regards,
Young

-----Original Message-----
From: PELOSO, PIERRE (PIERRE) [mailto:[email-masked]] 
Sent: Friday, September 30, 2011 9:39 AM
To: Leeyoung; [email-masked]
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Hi Young, 

Regards,

- Pierre

-----Message d'origine-----
De : Leeyoung [mailto:[email-masked]] 
Envoyé : mercredi 28 septembre 2011 00:06
À : PELOSO, PIERRE (PIERRE); [email-masked]
Objet : RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Hi Pierre, 

Regards,
Young

-----Original Message-----
From: PELOSO, PIERRE (PIERRE) [mailto:[email-masked]]
Sent: Tuesday, September 27, 2011 3:28 AM
To: Leeyoung; [email-masked]
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Hi Young, and CCAMPers,

Regards,

Pierre

-----Message d'origine-----

Hi all,

Best Regards.
Young