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

[Greg Bernstein <[e-mail]>]

Hi Cyril, see comments below.
Cheers
Greg
On 7/8/2011 6:24 AM, Margaria, Cyril (NSN - DE/Munich) wrote:
> 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.
--> 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.
> 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.
>
>>>       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.
--> But there is nothing to be gained from these changes spacewise. As 
someone who has been working on the drafts since 2007 we originally 
separated the information, then combined the information, then separated 
the information based on the WG decision. Since this change doesn't fix 
anything, at this point we should leave it as it is.
>
>>>       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.
--> Hmm, this is where we seem to differ. The example shows that we have 
one information encoding for each type of resource which gives 10 and 
not 40.  The Resource Block Info sub-TLV begins with an RB Set Field 
which specifies in compact form all the resource blocks that are of this 
particular type. This was changed in the transition from the 09 to the 
10 (published 3/14/2011). Hence I guess the Peloso-03 analysis was based 
on the old version and is no longer applicable.

--> only need one of these per type of resource:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     RB Set Field                              |
    :         List of resource WC IDs that are of this type         |
    |         Length in words = 1 + ceil{(Num WC total)/(2*NT)}     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|0|                      Reserved                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Input Modulation Type List Sub-Sub-TLV              |
    :        (The receivers can only process NRZ)                   :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Input FEC Type List Sub-Sub-TLV                     |
    :           (Only Standard SDH and G.709 FECs)                  :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Input Client Signal Type Sub-TLV                      |
    :              (GPIDs for SDH and G.709)                        :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Input Bit Rate Range List  Sub-Sub-TLV                |
    :                          (2.5Gbps, 10Gbps)                    :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Processing Capabilities List Sub-Sub-TLV              |
    :                    Fixed (non optional) 3R regeneration       :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Output Modulation Type List Sub-Sub-TLV               |
    :                          NRZ                                  :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Output FEC Type List Sub-Sub-TLV                      |
    :                 Standard SDH, G.709 FECs                      :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> 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
>


-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]