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.
let us know if you still have a question after reviewing the
Giovanni Martinelli [mailto:giomarti <at> cisco.com]
Sent: Tuesday, September 20, 2011 2:36 AM
Cc: Acee Lindem; CCAMP
Subject: Re: [CCAMP] FW: I-D Action:
On 9/19/11 10:29 PM, Leeyoung wrote:
worst case analysis for 16 degree node connectivity matrix
is subject to verification,
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).
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
last email to the CCAMP was concerning how to do it.
can lift off RFC 5786 restriction to be able to send
multiple TLVs under the current Node Attribute TLV.
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
don’t think the scale of the connectivity matrix is a big
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?).
On 9/13/11 11:04 PM, Acee Lindem wrote:
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
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
Is my guess correct?
On Sep 12, 2011, at 11:40 PM, Zhangfatai wrote:
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".
Sent: 2011年9月13日 11:38
To: 'Acee Lindem'; Greg Bernstein; Leeyoung
Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
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".
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
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
"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
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
< 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].
< 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]).
< 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.
< sub-TLVs that can be sent in multiple LSA instances. The
sub-TLVs that can be sent in multiple OSPF TE LSAs. The
< 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
On Sep 9, 2011, at 3:51 PM, Leeyoung wrote:
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.
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:
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:
Internet-Drafts are also available by anonymous FTP at:
This Internet-Draft can be retrieved at:
CCAMP mailing list
CCAMP <at> ietf.org
CCAMP mailing list
CCAMP <at> ietf.org
CCAMP mailing list
CCAMP <at> ietf.org