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

From: Giovanni Martinelli <[email-masked]>
Date: Mon, 03 Oct 2011 23:28:34 +0200

Hi Young,

sorry for late reply

On 9/22/11 9:43 PM, Leeyoung wrote:
>
> 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.
>
I would guess this text apply to
draft-ietf-ccamp-general-constraint-encode since the issue is not
specific to OSPF. Is the text here above you use "port" while should be
"link set".

<http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-05.txt>

>
> ?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.
>
Btw, I did not comment here although I lean toward this ... since adding
a new top level tlv sounds familiar.

> ?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.
>
although WSON technology in evolving in removing constrains I was trying
to figure out numbers for a pretty unconstrained node (and still the
result is not negligible).

Again, by comment was not in proposing a new encoding in connectivity
matrix but just figure out what sizes we could expect. Hence my request
to get some realistic examples in Appendix A (but I could provide text
for that).

Cheers
G

> 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,
>
> 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]>
> [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,
>
> 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: [email-masked] <mailto:[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,
>
>     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: [email-masked] <mailto:[email-masked]> [mailto:[email-masked]] On Behalf 
>
>         Of [email-masked] <mailto:[email-masked]>
>
>         Sent: Thursday, September 08, 2011 5:16 PM
>
>         To: [email-masked] <mailto:[email-masked]>
>
>         Cc: [email-masked] <mailto:[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-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
>
>         [email-masked] <mailto:[email-masked]>
>
>         https://www.ietf.org/mailman/listinfo/ccamp
>
>         _______________________________________________
>
>         CCAMP mailing list
>
>         [email-masked] <mailto:[email-masked]>
>
>         https://www.ietf.org/mailman/listinfo/ccamp
>
>      
>
>  
>
>
>
>
>
> _______________________________________________
> CCAMP mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ccamp