[CCAMP] Change 1: Introduction of resource pool entity (was Re: Moving the WSON discussion forward)

["PELOSO, PIERRE (PIERRE)" <[e-mail]>]

Hi Greg and CCAMPer's,

As in the preceding mail which summarized the 3 main changes proposed by draft-peloso-ccamp-wson-ospf-oeo, become too big to be easily read through,
I've been splitting the 3 points in 3 different threads, this one deals with change 1:  
Introduction of the Resource Pool entity inside the model, which allows the definition of several resource entites per node independantly floodable.
MOTIVATION: to decrease the size of flooding upon LSP changes (setup or tear down). (Resource Pool = group of resource blocks with same connectivity constraints).

Best Regards,

Pierre

[SNIP]

>>>       1. Introduction of the Resource Pool entity inside the model, 
>>> which allows the definition of several resource entites per node 
>>> independantly floodable.
>>> MOTIVATION: to decrease the size of flooding upon LSP changes (setup 
>>> or tear down). (Resource Pool = group of resource blocks with same 
>>> connectivity constraints)
>> -->  There is already a standard mechanism in OSPF-TE for achieving  
>> --> this
>> (multiple LSA instances) which is already in common use in MPLS and 
>> GMPLS so this change is unneeded. The current WSON encoding model 
>> includes very fine granularity in sub-TLVs hence this change would 
>> not achieve the stated "MOTIVATION" any better than the current approach.
> The change proposed by draft-peloso does mandate (implicitly, this 
> should be definitely changed) to have one LSA instance per top level TLV.
--> Hmm, other GMPLS specifications go the other way and restrict the
number of top level TLVs (usually one) per LSA.
This top level TLV is viewed as a container for a given type of information. If we have more than one "item" of information of a particular type you have the option of putting them in separate LSA instances. All the LSA instances together form the link state database and are used in path computation.  OSPF's reliable flooding mechanism will make sure the information gets there.  Note, that unlike the IP routing case where slightly out of date information can cause loops/blackholes, in the GMPLS case at worse the signaling request will fail somewhere along the path selected.
-->[Pierre]
My first comment here is that in our current case, WSON extensions are loading the CP heavily with various information, then as long as possible, the intent here is to avoid cranck-back. If cranck-back is not dammageable, it is as efficient to rely on a distributed wavelength assignment for which current GMPLS, possibly improved with signalling extensions provided in the relevant draft is sufficient. To sum-up my point, I personnaly hope that we are not doing all this work, to reach the conclusion that no better than without all these extensions if the signaling fails it is not important. 

> The solution of current WG-drafts is less explicit regarding how many 
> TLVs should/may be flooded.
--> This is implementation and situation specific.
> Would you then elaborate with text in the drafts giving recommendations
>   on how to process different LSA instances referring to same sub-TLVs 
> in the wson specific case.
--> We can add informative text to further explain the process. We'll
bring in some proposed text to Quebec City.
> The processing is not explicitly stated, according to 
> draft-ietf-ccamp-rwa-info-11, there is one ResourcePool per node and
> draft-ietf-ccamp-wson-signal-compatibility-ospf-04 state that this 
> ResourcePool is contained in the "Optical Node Property TLV".
>
> So according to the draft a LSP setup would impact the following sub-TLVs :
>    - "Resource Pool State Sub-TLV" : number of available device is changed
>    - "Block Shared Access Wavelength Availability Sub-TLV " is also 
> updated
>
> Should this be new instances or reuse existing instances? How to merge the information?
--> Think of the Optical Node Property TLV as the master container that
the OSPF working group has allocated to us. They have very limited "code space" and hence want us to use all existing mechanisms rather than asking them for more top level TLVs. Note all of GMPLS uses just one type of LSA.
We would not want to mix large amounts of static information (pool
accessibility) and dynamic information (pool state or shared access
state) in the same LSA instance.  So we could generally do something like the following schematic:
             LSA instance #1{ Node_Prop_TLV[Pools accessibility]}
             LSA instance #2{ Node_Prop_TLV[Resource info]}
             LSA instance #3{ Node_Prop_TLV[Pools accessibility]}
             LSA instance #4{ Node_Prop_TLV[Shared wave state]}
A similar process can be used with link information where the top level container was defined way back in early MPLS days.
-->[Pierre]
When reading the preceding part, I end-up to the conclusion that when finally explicited, you finally prone something very similar to draft-peloso-ccamp-wson-ospf-oeo, which I am happy with, as it means, we can then certainly sort out the details. As I see, you are only differing in that you do not dare defining an explicit top-level TLV type for each of your type of LSA instance.
I understand that your motivation there comes from OSPF WG having allocated us a very limited "code space". That is not something I am aware of, would you provide the WG with reference(s) to this statement?