Re: [CCAMP] Moving the WSON discussion forward (Was Re: TR: New Version Notification fordraft-peloso-ccamp-wson-ospf-oeo-03.txt)

["Margaria, Cyril (NSN - DE/Munich)" <[e-mail]>]

Hi CCAMPers, Greg, 

Thanks greg for your point of view, this can help clarifying some points.
Please find below clarifications on the point you raised.


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of ext Greg Bernstein
> Sent: Tuesday, July 05, 2011 4:50 PM
> To: [e-mail]
> Subject: Re: [CCAMP] Moving the WSON discussion forward (Was Re: TR:
> New Version Notification fordraft-peloso-ccamp-wson-ospf-oeo-03.txt)
> 
> Hi CCAMPers, none of the changes to the current WSON WG drafts listed 
> below are necessary to achieve the stated goals, i.e., the current 
> mechanisms suffice please see details below. We can offer an offline 
> tutorial session to interested parties in Quebec city as it seems 
> there is a lack of understanding of (a) the current WSON drafts, and 
> (b) GMPLS protocols in general.
>
> 
> Best Regards
> Greg
> 
> On 7/4/2011 8:02 AM, PELOSO, PIERRE (PIERRE) wrote:
> > Hello CCAMPer's,
> >
> > Following Lou's suggestion, this email intends to summarize the main 
> > changes introduced by draft-peloso-ccamp-wson-ospf-oeo, viewed from 
> > the information model, we end-up with 3 of them:
> >      0. IMPORTANT REMINDER OF ONE OF THE PIECES THAT WAS NOT CHANGED:
> > Resource block = group of devices with same features and same 
> > connectivity constraints.
> >
> >      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. 
The solution of current WG-drafts is less explicit regarding how many 
TLVs should/may be flooded.
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. 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?


> >      2. Use of the connectivity matrix defined inside the node entity
> > in order to describe connectivity constraints between node-external
> > links and the resource pools.
> > MOTIVATION: a/ to gather static information inside node entity (for
> > OSPF-TE inside a LSA never flooded upon LSP updates). b/ to limit the
> > number of connectivity representations introduced by current extensions
> > (draft-ietf-rwa-info proposes similar TLVs in different LSAs).
> >
> --> This change mixes information from "general constraints" with "wson
> specific constraints" and hence goes against the decision made by the
> CCAMP WG at the March 2009 San Francisco IETF. This proposed change
> does not result in any space savings and results in an undesirable
> mixing of separate concepts.  All current WSON drafts include
> separation of relatively "static" from more "dynamic" information,
> hence this change is unnecessary.

My co-authors and myself are aware of your interpretation of this solution
as being a mixing of generic and wson specific extensions.
Actually we are not sharing this interpretation, we consider this solution
as complying with the decision you're refering too.
The resulting connectivity matrix does not contains any FEC, wavelength,
modulation format information.
This kind of information is still separated in different elements.
Hence what you're interpreting as a mixing of wson and generic extensions
is nothing but the use in a generic element of unnumbered IDs.
By nature, all of these unnumbered IDs being defined in different LSAs,
as was already planned current WG drafts.
Considering that depending on the type of LSA which define these IDs,
the WG decision is betrayed or not is a position I let you advocate.


> >      3. Reduction of the scope of Resource Block Information, to keep
> > only resource/device description (moved the number of devices away).
> > MOTIVATION: a/ to share resource description for all the (same
> > devices) blocks (of a node), then decreasing the total size of
> > information. b/ to create an independent flooding entity holding all
> > the resource descriptions (which are static), the decreasing the size
> > of updated information.
> --> This change (a) does not result in any size savings, and (b) is not
> necessary to "to create an independent flooding entity holding all the
> resource descriptions".  Resource block information is already a
> separate sub-TLV and the current resource block set mechanism provides
> a highly efficient method to indicate which resources blocks are
> associated with a particular type of resource.
> 

I consider the contradiction to your statement is in the example you've been
providing in the email: "Current WSON encodings...".
In this example there are 200 wavelength converters of 10 different types,
spread over 4 physical pools/WC group.
Following the Resource Block definition, that gives 40 of those each having
a priori different number of wavelength converters.
So, a priori 40 different Resource Block Informations TLVs are needed, 
which change significantly the size of the LSA.
By  giving-up the definition of Resource Block with the max-number, it creates 
then 200 of those (one per wavelength converter). 
This results in associating each individual wavelength converter to a one of the
10 different Resource Block Information TLV created.
Applying our solution, demands to determine 40 Resource Block IDs, then to define
10 different Resource Description TLV, associated each with 4 of the preceding Resource Block IDs.

Is this analysis correct, is it the reason why the max-number of resources
was not included in your example or is there another reason?

Best regards,

Cyril, Giovanni, Julien and Pierre

> 
> > Best regards,
> >
> > Cyril, Giovanni, Julien and Pierre
> >
> > -----Message d'origine-----
> > De : [e-mail] [mailto:[e-mail]] De la
> part
> > de Lou Berger Envoyé : mardi 28 juin 2011 16:57 À : Leeyoung;
> > [e-mail]
> > Cc : [e-mail]
> > Objet : [CCAMP] Moving the WSON discussion forward (Was Re: TR: New
> > Version Notification fordraft-peloso-ccamp-wson-ospf-oeo-03.txt)
> >
> 
> --
> ===================================================
> Dr Greg Bernstein, Grotto Networking [phone]
> 
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp