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:giomarti <at> cisco.com]
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,

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: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] 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,

On 9/13/11 11:04 PM, Acee Lindem wrote:

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?

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

 

 

On Sep 12, 2011, at 11:40 PM, Zhangfatai wrote:

 

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,

 

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: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] 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,

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

 

 

 

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

 

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: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] On Behalf

Of internet-drafts <at> ietf.org

Sent: Thursday, September 08, 2011 5:16 PM

To: i-d-announce <at> ietf.org

Cc: ccamp <at> ietf.org

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

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

ibility-ospf-05.txt _______________________________________________

CCAMP mailing list

CCAMP <at> ietf.org

https://www.ietf.org/mailman/listinfo/ccamp

_______________________________________________

CCAMP mailing list

CCAMP <at> ietf.org

https://www.ietf.org/mailman/listinfo/ccamp

 

 

_______________________________________________

CCAMP mailing list

CCAMP <at> ietf.org

https://www.ietf.org/mailman/listinfo/ccamp