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

From: Leeyoung <[email-masked]>
Date: Fri, 09 Sep 2011 19:51:20 +0000

Hi,

This update added a new section to discuss OSPF scalability and how to use multiple TE LSA instance technique to keep the LSA under the MTU limit. Please note that the MTU limit is 1500 bytes and the examples given in the encoding draft is far below this limit. In case the LSA size goes above the MTU, this draft discusses how to split the Sub-TLVs' defined under the Optical Node Property TLV under the MTU limit to avoid fragmentation. 

Take a look at Section 3 and if you have questions, please feel free to discuss in the mailing list. 

Regards,
Young

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

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           : 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-05.txt
	Pages           : 14
	Date            : 2011-09-08

   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-05.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-05.txt
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Acee Lindem <[email-masked]>
Date: Mon, 12 Sep 2011 18:58:15 -0400

Hi Young, Greg, 
I have the following comments:

   1. Specify that the Optical Node Property TLV cardinality and order rules per LSA. 
       For example (from RFC 3630): 

     "The Link TLV describes a single link.  It is constructed of a set of
       sub-TLVs.  There are no ordering requirements for the sub-TLVs.

      Only one Link TLV shall be carried in each LSA, allowing for fine  
      granularity changes in topology."

      However, use the term "advertised" rather than "carried". After all, these are
      Link State Advertisements. 

   2. The same comment for all the Sub-TLVs. Here is another example from 
        RFC 3630:

      "The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear
       exactly once.  All other sub-TLVs defined here may occur at most
       once.  These restrictions need not apply to future sub-TLVs.
       Unrecognized sub-TLVs are ignored."

       The new Sub-TLVs you are defining need this level of specification. 

   3. I know I told you not to use the term "multi-instance LSA". I still don't like
       the usage of "LSA instance" in the draft. In the base OSPF specification, RFC 2328, 
       the term LSA instance is used to denote a particular version of the same LSA - NOT
       an opaque identifier for multiple LSAs of the same type. Refer to section 12.1 in 
       RFC 2328. 

      The OSPF Opaque LSA RFC (RFC 2370 and its successor RFC 5250) correctly 
       identify the last 24 bits of the LSA ID as the Opaque ID. While RFC 3630 refers
       to this field as the "Instance", I believe this term should be avoided given the 
       semantics in the OSPF base specification. Hence, I'd suggest the 
       following changes:

225,226c225,226
<    the rest and make use of multiple TE LSA instances per source, per
<    [RFC3630] multiple instance capability.
---
>    the rest and be advertised with multiple TE LSAs per OSPF router, as
>    described in [RFC3630] and [RFC5250].
342,344c342,344
<    the dynamic information sub-TLVs into separate LSAs within an Optical
<    Node Property TLV using multiple TE LSA instances per source, per the
<    reference [RFC3630] multiple instance capability.
---
>    the dynamic information sub-TLVs from the static information sub-TLVs
>    and advertise them in OSPF TE LSAs, each with the Optical Node
>    Property TLV at the top level ([RFC3630 and RFC5250]). 
392c392
<    into smaller sub-TLVs that can be sent in separate LSA instances.
---
>    into smaller sub-TLVs that can be sent in separate OSPF TE LSAs.
399c399
<    sub-TLVs that can be sent in multiple LSA instances. The
---
>    sub-TLVs that can be sent in multiple OSPF TE LSAs. The
473c473
<    into multiple LSA instances each containing a disjoint assembly of
---
>    into multiple OSPF TE LSAs each containing a disjoint assembly of

     Additionally, I'd add RFC 5250 as at least a informative reference.

   4. Finally, I'd suggest changing the title from "OSPF Enhancement..." to 
       "GMPLS OSPF Enhancement..." since you are not really enhancing base 
       OSPF itself.  Of course, there are other CCAMP RFCs that do not make 
       this distinction. 

Thanks,
Acee

---

From: Zhangfatai <[email-masked]>
Date: Tue, 13 Sep 2011 03:37:09 +0000

Hi Acee,

I personally agree with your comments on "multi-instance LSA".

I will take your suggestions into account when I update "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".

Thanks
 
Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Acee Lindem
Sent: 2011年9月13日 6:58
To: Greg Bernstein; Leeyoung
Cc: CCAMP
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi Young, Greg,

225,226c225,226
342,344c342,344
392c392
399c399
473c473

Thanks,
Acee 

On Sep 9, 2011, at 3:51 PM, Leeyoung wrote:

> Subject: [CCAMP] I-D Action: 
> draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
> 
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compat
> ibility-ospf-05.txt _______________________________________________
> CCAMP mailing list
> [email-masked]

---

From: Zhangfatai <[email-masked]>
Date: Tue, 13 Sep 2011 03:40:49 +0000

Hi Acee,

Sorry for a mistake, :-)

I should say "when I update draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00.txt" instead of "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".

Thanks
 
Fatai

-----Original Message-----
From: Zhangfatai 
Sent: 2011年9月13日 11:38
To: 'Acee Lindem'; Greg Bernstein; Leeyoung
Cc: CCAMP
Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi Acee,

Thanks
 
Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Acee Lindem
Sent: 2011年9月13日 6:58
To: Greg Bernstein; Leeyoung
Cc: CCAMP
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi Young, Greg,

225,226c225,226
342,344c342,344
392c392
399c399
473c473

Thanks,
Acee

---

From: Leeyoung <[email-masked]>
Date: Tue, 13 Sep 2011 19:55:03 +0000

Hi Acee,

Thanks for your thorough review and great comments. We will incorporate all your comments where possible in the revision. 
See my comment in-line. 

Best Regards
Young

________________________________________
From: Acee Lindem [[email-masked]]
Sent: Monday, September 12, 2011 5:58 PM
To: Greg Bernstein; Leeyoung
Cc: CCAMP
Subject: Re: [CCAMP] FW: I-D    Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi Young, Greg,

YOUNG>> Yes, I agree. 

YOUNG>> Yes, this is fine. 

YOUNG>> Sorry for the confusion. Yes mutliple TE-LSAs are what we are talking about here.  

YOUNG>> Will do. Thanks.

225,226c225,226
342,344c342,344
392c392
399c399
473c473

YOUNG>> If the chairs are OK with this, we will change the title. 

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Tue, 13 Sep 2011 17:04:01 -0400

Hi Fatai,
I only have two comments on this document:

  1. Reference RFC 5250 rather than RFC 2370 as the former obsoleted the latter. 
  2. Possibly this draft should remove the RFC 5786 restriction that only a single OSPF TE LSA containing a top-level TLV is allowed. 
      Couldn't the connectivity matrix become quite large? 

Thanks,
Acee

---

From: Zhangfatai <[email-masked]>
Date: Wed, 14 Sep 2011 02:13:22 +0000

Hi Acee,

For your point 1: I will replace RFC 2370 with RFC 5250 in the future version.

For your point 2: There were lots of discussion on whether we should remove the RFC5786 restriction in the mailing list (we also asked for suggestions from the authors of RFC5786), however, there was no consensus.

Actually, if we can remove the RFC5786 restriction, it can make things simple, for example, we don't need to define another new top Node TLV (ie., Optical Node Property TLV) to carry WSON OEO stuff.

I would like to hear more opinions from CCAMPers and OSPFers on point 2.

Thanks
 
Fatai

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]] 
Sent: 2011年9月14日 5:04
To: Zhangfatai
Cc: Greg Bernstein; Leeyoung; CCAMP
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi Fatai,

Thanks,
Acee

---

From: Leeyoung <[email-masked]>
Date: Fri, 16 Sep 2011 20:37:08 +0000

Hi Acee and Fatai,

It might be easier just to create a new Top Level TLV (say we name it, "Genetic" Node Property TLV) under which we can package all generic properties such connectivity matrix, etc. 

Since we are concerned about the MTU limit, this approach would be a good way not to mix up with other Node attribute stuffs currently defined under Node Attribute TLV. In light of OTN stuff coming down the pipe, creating a new Top-Level TLV to put all these new attributes sounds reasonable to me. 

Lifting up 5786 restriction is obviously feasible but it takes another draft to sort it out. From a procedural perspective, it will take a longer path and the MTU issue will continue to be an issue. 

Regards,
Young

-----Original Message-----
From: Zhangfatai 
Sent: Tuesday, September 13, 2011 9:13 PM
To: Acee Lindem
Cc: Greg Bernstein; Leeyoung; CCAMP
Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-01.txt

Hi Acee,

Thanks
 
Fatai

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]] 
Sent: 2011年9月14日 5:04
To: Zhangfatai
Cc: Greg Bernstein; Leeyoung; CCAMP
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi Fatai,

Thanks,
Acee

---

From: Giovanni Martinelli <[email-masked]>
Date: Mon, 19 Sep 2011 22:08:49 +0200

Hi,

>        Couldn't the connectivity matrix become quite large?
as far as I've see there is a couple of  examples here 
http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-05 
within appendix A3 and A4.  So asking authors, any other numbers around?

My comment here is that those numbers refers essentially to 2 degree 
node. I would ask if draft can report some information (formula in the 
optimal case) that allow to figure out how the connectivity matrix scale.

E.g. Thinking about a 16 degree node my guess reading the appendix A4: 
the last part of the TLV (from "note : line to line" on) we need to add 
one more 32 bits to identify the out-range, and we need to replicate 
this link-set tuple 15 times.  So in total the "line to line" become 
5*15*4 = 300 bytes

Is my guess correct?

Cheers
G

>> Sent: 2011?9?13? 11:38
>> Sent: 2011?9?13? 6:58

---

From: Leeyoung <[email-masked]>
Date: Mon, 19 Sep 2011 20:29:45 +0000

Hi Giovanni,

Your worst case analysis for 16 degree node connectivity matrix is subject to verification, but even if this is a right number, 300 bytes is well under 1500 byte MTU limit, so we can package it without sub-dividing the TLV.

We can easily partition the connectivity matrix even if it goes beyond the MTU limit. The last email to the CCAMP was concerning how to do it.

-          We can lift off RFC 5786 restriction to be able to send multiple TLVs under the current Node Attribute TLV.

-          Define a new top level TLV to do that.

I don’t think the scale of the connectivity matrix is a big issue.

Regards,
Young

From: [email-masked] [mailto:[email-masked]] On Behalf Of Giovanni Martinelli
Sent: Monday, September 19, 2011 3:09 PM
To: Acee Lindem
Cc: CCAMP
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi,

Hi Fatai,

      Couldn't the connectivity matrix become quite large?
as far as I've see there is a couple of  examples here http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-05 within appendix A3 and A4.  So asking authors, any other numbers around?

My comment here is that those numbers refers essentially to 2 degree node. I would ask if draft can report some information (formula in the optimal case) that allow to figure out how the connectivity matrix scale.

E.g. Thinking about a 16 degree node my guess reading the appendix A4: the last part of the TLV (from "note : line to line" on) we need to add one more 32 bits to identify the out-range, and we need to replicate this link-set tuple 15 times.  So in total the "line to line" become 5*15*4 = 300 bytes

Is my guess correct?

Cheers
G

Thanks,

Acee

Hi Acee,

Sorry for a mistake, :-)

Thanks

Fatai

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

From: Zhangfatai

Sent: 2011年9月13日 11:38

Cc: CCAMP

Hi Acee,

Thanks

Fatai

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

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Acee Lindem

Sent: 2011年9月13日 6:58

Cc: CCAMP

Hi Young, Greg,

       RFC 3630:

      RFC 2328.

      following changes:

225,226c225,226

---

342,344c342,344

---

392c392

---

399c399

---

473c473

---

      this distinction.

Thanks,

Acee

Hi,

Regards,

Young

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

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf

Of [email-masked]<mailto:[email-masked]>

To: [email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>

   Author(s)       : Young Lee

                        Greg M. Bernstein

   Pages           : 14

   Date            : 2011-09-08

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compa

tibility-ospf-05.txt

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

---

From: Giovanni Martinelli <[email-masked]>
Date: Tue, 20 Sep 2011 09:36:07 +0200

Hi,

On 9/19/11 10:29 PM, Leeyoung wrote:
>
> Hi Giovanni,
>
> Your worst case analysis for 16 degree node connectivity matrix is
> subject to verification,
>
> but even if this is a right number, 300 bytes is well under 1500 byte
> MTU limit, so we can package it without sub-dividing the TLV.
>
yes , I was not concerned about mtu but how to build a correct
connectivity matrix beyond a simple 2 degree node. If you provide few
more numbers there's probably a better feeling of "how many" bytes are
(well beyond the mtu but well above the 75 bytes in the example).

> We can easily partition the connectivity matrix even if it goes beyond
> the MTU limit.
>
Agree that's a good solution but my comment here is related to how do we
partition. Would it worth to add some text about it? We could probably
guess (e.g. linkset couple) but just to make sure all readers will have
same interpretation.

> The last email to the CCAMP was concerning how to do it.
>
> -We can lift off RFC 5786 restriction to be able to send multiple TLVs
> under the current Node Attribute TLV.
>
> -Define a new top level TLV to do that.
>
I know and I was not replaying on last email but trying to providing
numbers for the connectivity matrix.

> I don’t think the scale of the connectivity matrix is a big issue.
Since it has to be "generic" we don't know in principle. Does not look a
problem for *unconstrained* wson nodes. Don't know if others has
different options for wson technology or may be possible other
technologies (otn?).

Cheers
G
>
> Regards,
>
> Young
>
> *From:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Giovanni Martinelli
> *Sent:* Monday, September 19, 2011 3:09 PM
> *To:* Acee Lindem
> *Cc:* CCAMP
> *Subject:* Re: [CCAMP] FW: I-D Action:
> the last part of the TLV (from "note : line to line" on) we need to
> add one more 32 bits to identify the out-range, and we need to
> replicate this link-set tuple 15 times. So in total the "line to line"
> become 5*15*4 = 300 bytes
>
> Is my guess correct?
>
> Cheers
> G
>
>
>
>
>
>  
> Thanks,
> Acee
>  
>  
>     From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Acee Lindem
>
>     Sent: 2011年9月13日 6:58
>
>         From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked]] On Behalf 
>
>         Of [email-masked] <mailto:[email-masked]>
>
>         To: [email-masked] <mailto:[email-masked]>
>
>         Cc: [email-masked] <mailto:[email-masked]>
>
>         [email-masked] <mailto:[email-masked]>
>
>         [email-masked] <mailto:[email-masked]>
>
> [email-masked] <mailto:[email-masked]>

---

From: Acee Lindem <[email-masked]>
Date: Wed, 21 Sep 2011 12:03:27 -0400

Hi Young,

> Since we are concerned about the MTU limit, this approach would be a good way not to mix up with other Node attribute stuffs currently defined under Node Attribute TLV. In light of OTN stuff coming…

I agree. If the authors and WG are amenable to this solution, it would seem to simplify things. 

Thanks,
Acee

---

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

Hi Giovanni,

We have updated the generic OSPF draft (thanks to Fatai).

*         Point #1: Regarding your concern on how to build a connectivity matrix in case we need to decompose into several sub-TLV’s, we have added the following subsection in the revision:

5.2. Decomposing a Connectivity Matrix into Multiple Matrices

   In the highly unlikely event that a Connectivity matrix sub-TLV by
   itself would result in an LSA exceeding the MTU, a single large
   matrix can be decomposed into sub-matrices. Per [GEN-Encode] a
   connectivity matrix just consists of pairs of input and output ports
   that can reach each other and hence such this decomposition would be
   straightforward. Each of these sub-matrices would get a unique matrix
   identifier per [GEN-Encode].

Please let us know if you still have a question after reviewing the text.

*         Point  #2: In addition, the revision proposed a new solution that allows multiple sub-TLV’s defined in a top-level TLV. Please see Section 2 in which we added the following text:

   This document defines a new top TLV named the Generic Node Attribute
   TLV which carries attributes related to a general network element.
   This Generic Node Attribute TLV contains one or more sub-TLVs

And in Section 7.1, we added

   This document introduces a new Top Level Node TLV (Generic Node
   Attribute TLV) under the OSPF TE LSA defined in [RFC3630].

      Value    TLV Type

      TBA      Generic Node Attribute

Please let us know if this seems to be a viable solution. If not, please suggest an alternative solution.

*         Point #3: Finally, concerning your question/comment: Since it has to be "generic" we don't know in principle. Does not look a problem for *unconstrained* wson nodes. Don't know if others has different options for wson technology or may be possible other technologies (otn?).

I am not clear what you are asking for here. But if I guess, you are concerned about “generic” technology connectivity matrix. Please note that the reason why we needed the connectivity matrix in WSON was due to the nature of asymmetric nature of ROADM switching technology.

If switches are symmetric, we don’t need to advertise the connectivity matrix. This means any port can be switched to any other ports. Please see the last paragraph of Section 2:

   In some specific technologies, e.g., WSON networks, Connectivity
   Matrix sub-TLV may be optional, which depends on the control plane
   implementations. Usually, for example, in WSON networks, Connectivity
   Matrix sub-TLV may appear in the LSAs because WSON switches are
   asymmetric at present. It is assumed that the switches are symmetric
   switching, if there is no Connectivity Matrix sub-TLV in the LSAs.

Please let us know if you still have a question after reviewing the text.

Best Regards,
Young

From: Giovanni Martinelli [mailto:[email-masked]]
Sent: Tuesday, September 20, 2011 2:36 AM
To: Leeyoung
Cc: Acee Lindem; CCAMP
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi,

Your worst case analysis for 16 degree node connectivity matrix is subject to verification,
but even if this is a right number, 300 bytes is well under 1500 byte MTU limit, so we can package it without sub-dividing the TLV.

yes , I was not concerned about mtu but how to build a correct connectivity matrix beyond a simple 2 degree node. If you provide few more numbers there's probably a better feeling of "how many" bytes are (well beyond the mtu but well above the 75 bytes in the example).

We can easily partition the connectivity matrix even if it goes beyond the MTU limit.
Agree that's a good solution  but my comment here is related to how do we partition. Would it worth to add some text about it? We could probably guess (e.g. linkset couple) but just to make sure all readers will have same interpretation.

I know and I was not replaying on last email but trying to providing numbers for the connectivity matrix.

Since it has to be "generic" we don't know in principle. Does not look a problem for *unconstrained* wson nodes. Don't know if others has different options for wson technology or may be possible other technologies (otn?).

Cheers
G

Regards,
Young

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Giovanni Martinelli
Sent: Monday, September 19, 2011 3:09 PM
To: Acee Lindem
Cc: CCAMP
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi,

Hi Fatai,

Is my guess correct?

Cheers
G

Thanks,

Acee

Hi Acee,

Sorry for a mistake, :-)

Thanks

Fatai

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

From: Zhangfatai

Sent: 2011年9月13日 11:38

Cc: CCAMP

Hi Acee,

Thanks

Fatai

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

Sent: 2011年9月13日 6:58

Cc: CCAMP

Hi Young, Greg,

       RFC 3630:

      RFC 2328.

      following changes:

225,226c225,226

---

342,344c342,344

---

392c392

---

399c399

---

473c473

---

      this distinction.

Thanks,

Acee

Hi,

Regards,

Young

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

   Author(s)       : Young Lee

                        Greg M. Bernstein

   Pages           : 14

   Date            : 2011-09-08

tibility-ospf-05.txt

CCAMP mailing list

CCAMP mailing list

CCAMP mailing list