Subject: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

From: Greg Bernstein <[email-masked]>
Date: Tue, 14 Dec 2010 10:23:49 -0800

Hi all two weeks ago we updated 
draft-ietf-ccamp-general-constraint-encode and 
draft-ietf-ccamp-rwa-wson-encode based on comments from the list and the 
Beijing meeting. These changes were editorial in nature and consisted of 
removing some informational text.
To move things forward in general we need to reach agreement on the top 
level TLVs to be used to carry this information.  We have two main types 
of information: (a) link related, and (b) node related.  In addition, 
depending on the complexity of the system we may want to split the 
information for a particular node or link into multiple LSAs  to keep 
the size of the LSA below a particular limit or to separate rapidly 
changing node or link information from relatively static. In general 
multiple TE LSA instances provide a mechanism for this.

*For Link information* *RFC3630* defines the "Traffic Engineering LSA". 
This has area scope.
"One new LSA is defined, the Traffic Engineering LSA.  This LSA 
describes routers, point-to-point links, and connections to multi-access 
networks (similar to a Router LSA)."

Multiple instances can exist from a single source:
"The Instance field is an arbitrary value used to maintain multiple 
Traffic Engineering LSAs.  A maximum of 16777216 Traffic Engineering 
LSAs may be sourced by a single system."

Two top level TLVs are defined: Router Address TLV (section 2.4.1) and 
Link TLV (section 2.4.2). The router address is just as it says. The 
link TLV is the generally useful one for us:
"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."

There does not appear to be any constraints on breaking up information 
about a single link into multiple LSAs. For WSON use we may want to keep 
static information (port wavelength constraints) separate from dynamic 
information (wavelength availability).

*For Node Level information* (such as connectivity matrices, resource 
block information, resource block usage state) it seemed like *RFC 5786* 
which has extensions for advertising a routers local addresses in TE 
extensions would be useful. It defines the OSPF TE LSA Node TLV and they 
state:
"It is anticipated that the Node Attribute TLV will also prove more 
generally useful."
However in section 4.2 (Operation) they state:
"*/The Node Attribute TLV MUST NOT appear in more than one TE LSA 
originated by a router/*.  Furthermore, such an LSA MUST NOT include 
more than one Node Attribute TLV."

The first of these restrictions on use seems to preclude us from 
separating traffic matrices, resource block descriptions, and resource 
block utilization status into separate LSA instances using this TLV. 
Unless this rule can be changed it seems that we will need a new top 
level "node properties" TLV for use in both WSON specific and General 
constraint extensions to OSPF.  Pierre and Giovanni in 
draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to define a new top level 
TLV for the resource block information, however it seems that we 
probably should ask for a general "node properties" (or whatever better 
name we can think of) top level TLV that could be applied to the general 
constraint node information (connectivity matrices) as well as the 
various resource related quantities.

Pierre and Giovanni does this sound like a reasonable way forward? Or do 
you have a different suggestion.  Comments and suggestions from all are 
welcome.

Best Regards

Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Mon, 20 Dec 2010 13:27:39 +0100

Hi Greg,

To start with, I am pretty in-line with the part related to the link TLV, which was already agreed.

Regarding the node related information, I am happy to see that you consider splitting its information over 2 top-level TLVs, which we have been proning in order to ease the scalability and the information organisation.
I do encourage you to adopt even more the concepts proned in draft-peloso-ccamp-won-ospf-oeo, by defining this new top-level TLV in a way that allows to have multiple instance of it, one for each conistent entity of ressoruces.

To detail my point of view, considering that I bet you would keep inside the node attribute top-level TLV the connectivity matrix object, and transfer the informations concerning the OEO ressources to the new top-level TLV that you suggest to name Node Property. I have no hard convinctions on any name, and this one can fit with me, it is not the important thing anyway.
I insist that, what seems more important to me is really to benefit fully from the advantages brought by introducing a new top-level TLV (which was apparently one of the thinks you were reluctant to do), namely the capability to have one instance of this type per pool. Here a pool, being a consistent bunch of OEO resources, sharing the fact that updating the usage of one of them will have consequences on the accessibility of the others. Which is to my mind the smallest information entity that will need a single update on the modification of usage of one of its members, hence the most compliant with scalability.

To summarize, once the cost of introducing a new top-level TLV is accepted, let's use the advantages of the concepts introduced in our solution to their full extent, and then use a layout of information compliant with that. Does this sems reasonnable for you, and for the WG ?

- pierre

P.S. Let's keep aside right now the discussions concerning the administrative group, and TE metric sub-TLVs.
________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Greg Bernstein
Envoyé : mardi 14 décembre 2010 19:24
À : CCAMP
Objet : [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

Hi all two weeks ago we updated draft-ietf-ccamp-general-constraint-encode and draft-ietf-ccamp-rwa-wson-encode based on comments from the list and the Beijing meeting. These changes were editorial in nature and consisted of removing some informational text.
To move things forward in general we need to reach agreement on the top level TLVs to be used to carry this information.  We have two main types of information: (a) link related, and (b) node related.  In addition, depending on the complexity of the system we may want to split the information for a particular node or link into multiple LSAs  to keep the size of the LSA below a particular limit or to separate rapidly changing node or link information from relatively static. In general multiple TE LSA instances provide a mechanism for this.

For Link information RFC3630 defines the "Traffic Engineering LSA". This has area scope.
"One new LSA is defined, the Traffic Engineering LSA.  This LSA describes routers, point-to-point links, and connections to multi-access networks (similar to a Router LSA)."

Multiple instances can exist from a single source:
"The Instance field is an arbitrary value used to maintain multiple Traffic Engineering LSAs.  A maximum of 16777216 Traffic Engineering LSAs may be sourced by a single system."

Two top level TLVs are defined: Router Address TLV (section 2.4.1) and Link TLV (section 2.4.2). The router address is just as it says. The link TLV is the generally useful one for us:
"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."

There does not appear to be any constraints on breaking up information about a single link into multiple LSAs. For WSON use we may want to keep static information (port wavelength constraints) separate from dynamic information (wavelength availability).

For Node Level information (such as connectivity matrices, resource block information, resource block usage state) it seemed like RFC 5786 which has extensions for advertising a routers local addresses in TE extensions would be useful. It defines the OSPF TE LSA Node TLV and they state:
"It is anticipated that the Node Attribute TLV will also prove more generally useful."
However in section 4.2 (Operation) they state:
"The Node Attribute TLV MUST NOT appear in more than one TE LSA originated by a router.  Furthermore, such an LSA MUST NOT include more than one Node Attribute TLV."

The first of these restrictions on use seems to preclude us from separating traffic matrices, resource block descriptions, and resource block utilization status into separate LSA instances using this TLV. Unless this rule can be changed it seems that we will need a new top level "node properties" TLV for use in both WSON specific and General constraint extensions to OSPF.  Pierre and Giovanni in draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to define a new top level TLV for the resource block information, however it seems that we probably should ask for a general "node properties" (or whatever better name we can think of) top level TLV that could be applied to the general constraint node information (connectivity matrices) as well as the various resource related quantities.

Pierre and Giovanni does this sound like a reasonable way forward? Or do you have a different suggestion.  Comments and suggestions from all are welcome.

Best Regards

Greg B.