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

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Mon, 4 Jul 2011 17:02:57 +0200

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)

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

    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.

Best regards,

Cyril, Giovanni, Julien and Pierre

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Lou Berger
Envoyé : mardi 28 juin 2011 16:57
À : Leeyoung; [email-masked]
Cc : [email-masked]
Objet : [CCAMP] Moving the WSON discussion forward (Was Re: TR: New Version Notification fordraft-peloso-ccamp-wson-ospf-oeo-03.txt)

Young,
        I think we have a substantive document that satisfies my request for "a document that can serve as the foundation for discussion" on their proposal.

All,
        Perhaps it would be worthwhile to focus the discussion on the specific proposed changes and understanding the motivation for each.  I propose that we first focus on the Information model changes.

Authors of draft-peloso-ccamp-wson-ospf-oeo,

        Can you please list any major change made in Section 2 and explain/justify each proposed change? For example, discuss/justify your proposal to have multiple resource pools vs the single pool model in ccamp-rwa-info. (Note the BNF for multiple pools is missing, but is implied by Figure 1.)

Once we have closure on major changes, we can move on to the more minor changes in the section as well as changes in encoding (your section 3.)

My hope is to resolve the open issues on the list prior to Quebec, but suspect we'll need the WG session to help close the issues.

Lou

On 6/27/2011 4:32 PM, Leeyoung wrote:
> Hi Pierre,
>
> Please recall the WG chair's request to you in the last IETF meeting
> that the information you are to provide has to be comprehensive and
> complete so that others can understand the points you are making.
>
> Having reviewed your document, I think you need to provide the diagram
> of the node configuration you used as the basis of your analysis in
> the similar fashion to the current encoding draft.
>
> You mentioned that "For the small nodes, 5 different type of
> regenerators are considered, for the Middle and Large ones 10
> different type of regenerators are considered." -- Please provide your
> node diagrams for these cases so that we can provide our analysis.
> Until you provide the exact node configuration with these many OEO
> elements, it is not possible for us to proceed with the meaning
> comparisons.
>
> Regards, Young
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of PELOSO, PIERRE (PIERRE)
> Sent: Wednesday, June 22, 2011 8:26 AM
> To: Greg Bernstein; [email-masked]
> Subject: Re: [CCAMP] TR: New Version
Notificationfordraft-peloso-ccamp-wson-ospf-oeo-03.txt
>
> Hi Greg,
>
> I clearly get your will of understanding how the evaluation in section
5 was conducted, and
> I've noticed you were concerned by 2 points:
>   - 1 the node model and node diagram. The way we have conducted the
study, we refered to generic types of nodes (independant of the node internal structure), as we wanted the study not to be specific to a given product or architecture. Basically we have taken values for the items that are modeled by the information model. Though, for each case, we can provide multiple architectures (then diagrams) which would provide the same hypothesis. Our text in section 5.2 is certainly perfectible, hence if when reading it some points are either unclear or lacking to help the reader understand, please let us know which ones.
Section 5.2 is quoted below.
>   - 2 the encodings as used for current drafts. I have to say I fail
in understanding what you mean there. The encodings are provided in the drafts, we have used the drafts indications to determine those, as you are the editor of this draft, I would guess you would know how to determine those. Apart from tiny details, there is no much degree of freedom  in the way of encoding a given structure (which is to be hoped for in the frame of standardized protocol extensions). Can you help me then understand your point ?
>
>    o  Node Degree Connectivity: 4, 8 and 16.
>
>    o  WDM capacity: 100 wavelengths.
>
>    o  Switching capacity.  Defines the total node switching capability
>       and is calculated as Node Degree Connectivity x 100 wavelengths.
>
>    o  Regeneration Capability.  We assume a value of 5% of the total
>       switching capacity.
>
>    o  Add/Drop Capability.  We assume a typical value of 25% of the
>       switching capability.  So in the average up to 30 wavelengths per
>       incoming fiber can be added/dropped within the optical node.
>
>    o  Resource pool setup and capabilities.  A physical resource pool
>       contains a mix of Add/Drop and Regeneration capabilities.  This
>       has the effect of increasing the number of resource pool
>       advertized.  Resource pool can be fully flexible (connected to any
>       port), partial (only to some port) or Fixed (can only be connected
>       to one direction).  This parameter influences the complexity of
>       the connectivity matrix.
>
>    o  Number of Regenerator types.  For a given node the number of OEO
>       capabilities is limited, it is typically decided by the type of
>       electrical equipment and optical modules (emitting laser and
>       optical receiver).
>
>    o  Blocking Ratio.  The Spatial/Spectral blocking ratio indicates how
>       much port-based/wavelength based blocking a node is experiencing.
>
>    For example considering the typical design it results in the
>    following static layout:
>
>    o  3 OEO pools each having 3 Resource Block inside.
>
>    o  Connectivity Matrix: (8+30+30) 64x64 if considering one
>       connectivity matrix.  Ingress=64x3, Egress=3x64 (considering the
>       OEO access with a multiple-wavelength link).
>
>    The following types of nodes and node designs were considered in this
>    evaluation:
>
>                           Node Types and designs
>
>                  Node Type       Nodal Degree Pool Type Blocking
>             Small(S), Flexible         4       Partial    None
>            Small(S), Fixed(port)       4        Fixed     Port
>           Small(S), Fixed(label)       4       Partial   Lambda
>             Middle(M), Flexible        8       Flexible   None
>             Large(L), Flexible        16       Flexible   None
>
>    For the small nodes, 5 different type of regenerators are considered,
>    for the Middle and Large ones 10 different type of regenerators are
>    considered.  Based on those designs we derived the following
>    important figures:
>
>    o  Number of resourcePool : depends on the pool type and
>       connectivity, which depend on the port blocking and number of Add/
>       Drop and Regenerator capacity.
>
>    o  Number of resourceBlock.  There is two numbers to be considered
>       here : the number of resourceBlock for a given resource pool (this
>       document) and total number of resourceBlock
>       ([I-D.ietf-ccamp-rwa-info]).  In this document the number of
>       resource block within a resource pool is, worst case, the number
>       of possible regenerator types, whereas in
>       [I-D.ietf-ccamp-rwa-info] the number of resource block depends on
>       the number of OEO types and on the connectivity.
>
>    o  Number of connectivity matrix/number of pairs/link per pairs.  The
>       number of sub-matrix increase depending on the port blocking
>       ratio, the number of pair in one connectivity matrix depends on
>       the wavelength restrictions.  Those two criteria do not depend on
>       which information model is considered.  The number of link per set
>       is increased by the number of resource pool in this draft.
>
>    Those numbers for each node are shown in the following table
> (corrected the number of pools)
>
>                 Details of information elements per node
>
>         Node Type    Resource Pools Resource Blocks Matrix/Pair/Links
>        S, Flexible          6            5 (30)       1/1/10 (1/1/1)
>       S, Fixed(port)       12            5 (60)       4/4/4 (4/4/1)
>      S, Fixed(label)        6            5 (30)       4/1/10 (4/1/1)
>        M, Flexible          3           10 (30)       1/1/11 (1/1/1)
>        L, Flexible          5           10 (50)       1/1/21 (1/1/1)
>
>        Nota: Values for [I-D.ietf-ccamp-rwa-wson-encode] are between
>                                  brackets
>
>  As the preceding table may be uneasy to read, here is an alternative one:
>
>                  Details of information elements per node
>
>                         #Device            #ResProp
>    Node Type    #Pools   Type    #Blocks     TLV     Matrix/Pair/Links
>   S, Flexible      6       5       30       5 (25)     1/1/10 (1/1/1)
>  S, Fixed(port)   12       5       60       5 (45)     4/4/4  (4/4/1)
> S, Fixed(label)    6       5       30       5 (25)     4/1/10 (4/1/1)
>   M, Flexible      3      10       30      10 (30)     1/1/11 (1/1/1)
>   L, Flexible      5      10       50      10 (40)     1/1/21 (1/1/1)
>
>        Nota: Values for [I-D.ietf-ccamp-rwa-wson-encode] are between
>                                  brackets
>
> Regards,
>
> Pierre
>
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part
de Greg Bernstein
> Envoyé : vendredi 17 juin 2011 19:53
> À : [email-masked]
> Objet : Re: [CCAMP] TR: New Version
Notificationfordraft-peloso-ccamp-wson-ospf-oeo-03.txt
>
> This issue can be readily resolved if the  diagrams and current WG
draft sub-TLV encoding use in sections 5.2 and 5.3 of peloso-3 is given.
> There are four authors of this document, hence somebody must have a
diagram of the switch and sub-TLV encodings that generated the numbers used in the evaluation. If you can furnish that then I will show either
> (a) That the system of interest can be efficiently encoded with the
current WG drafts and current GMPLS/OSPF mechanisms.
> or
> (b) That a minimalistic extension to the WSON encoding draft along
with current GMPLS/OSPF extensions can be used to efficiently encode this system.
>
> Note that the purpose of this exercise is to solve a potential problem
with the WSON WG drafts and if enough folks are concerned about a potential problem we can figure out how to solve it.  The purpose is not a general re-write of these drafts. Note that during the development of the WSON WG drafts we shared all our test cases freely via my website, informal presentations at previous IETF meetings, and in papers published in journals. I don't seen any reason for the authors of
> peloso-3 to keep their test cases secret when asking for changes to
CCAMP WG drafts to accommodate it.
>
> Greg
>
> On 6/17/2011 9:20 AM, Julien Meuric wrote:
>> Hi Young.
>>
>> You are right on one thing: operators try to minimize costs. This is
>> exactly why ROADMs are first deployed with 10 Gb/s wavelengths, 40
>> Gb/s when transponders become cost-efficient enough, and then 100
>> Gb/s, which will likely become cost-efficient later... Obviously,
>> minimizing cost mean deploying over existing things, not replacing;
>> therefore we end up with many types of regenerators, due to the
>> various bit-rates and modulation format existing out there.
>>
>> I personally believe that a few-year-old long haul network will end
>> up beyond Cyril's "reasonable figures" quite easily.
>>
>> Regards,
>>
>> Julien
>>
>>
>> Le 17/06/2011 17:55, Leeyoung a écrit :
>>>
>>>  Cyril,
>>>
>>>
>>>
>>>  I think your example is a corner case, which is not typical case.
>>> We should not base this kind of highly theoretical corner case as
>>> the base case for your analysis. We are dealing with WSON switching
>>> enabled ROADM networks, not necessarily dealing with legacy DWDM
>>> system. Please also note that the typical WSON switching nodes are
>>> transparent nodes. Only some of the nodes may have Regen elements
>>> ---as I mentioned in the previous email, the operators try to
>>> minimize the use of Regen's due to its high cost.
>>>
>>>
>>>
>>>  Please see my other comment in-line.
>>>
>>>
>>>
>>>  Thanks.
>>>
>>>  Young
>>>
>>>
>>>
>>>
>>>
>>>  -------------------------
>>>
>>>  *From:*Margaria, Cyril (NSN - DE/Munich)
>>> [mailto:[email-masked]] **
>>>
>>>
>>>
>>>  Hi Young Lee, Ccamper's,
>>>
>>>
>>>
>>>  Reducing the type of regenerator makes sense but mixing regenerator
>>> type makes also sense, as you would try to avoid having only
>>> 40G-capable 3R when you can go for a cheaper 10G regenerator,
>>> depending on your demands.
>>>
>>>
>>>
>>>  In Greenfield deployments single rate makes sense, in an existing
>>> networks having multi-rate (2) support with different electrical
>>> module may be less common but should still be supported.
>>>
>>>  This kind of network would need 6 description for the processing
>>> capability alone. The total number of resource description need to
>>> be higher, as in the info model the description of a regenerator
>>> include the number of resource. Each time the connectivity imply a
>>> different number of regenerator are grouped together a separate
>>> ResourceBlockInfo should be used (Separating connectivity and
>>> regenerator setup would help here).
>>>
>>>
>>>
>>>  *YOUNG>> Your point on "separating connectivity and regenerator
>>> setup  would help here" is exactly the encoding principles of the
>>> current WG  adopted encoding drafts. Then I don't clearly understand
>>> what the  Pierre's draft are trying to do. *
>>>
>>>
>>>
>>>  Best case would see indeed 0-2 type of regenerator, intermediate
>>> actual deployments can see 6 types of regenerator, we also
>>> considered looking at possible evolutions, 10 being in our opinion a
>>> reasonable number.
>>>
>>>
>>>
>>>  I hope it could help you understand better what is considered in
>>> the draft. Those consideration will be more detailed in the next
>>> revision of the draft.
>>>
>>>
>>>
>>>  Best Regards
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  *From:*ext Leeyoung [mailto:[email-masked]] **
>>>
>>>
>>>
>>>  Hi Cyril,
>>>
>>>
>>>
>>>  I think your analysis below is very theoretical and a bit out of
>>> reality in WSON node configuration.
>>>
>>>
>>>
>>>  We are dealing with wavelength level so that OTUk level is
>>> transparent to WSON. In typical optical switch node configuration in
>>> WSON, we don't simply mix up all possible kinds of regenerators per
>>> each modulation type. It is true that we have many modulation types
>>> for each rate and the model should support all possibility. But this
>>> does not mean we have all "10 types" at the same time in a node
>>> design. As you know, regenerator is one of the most expensive WSON
>>> elements and having many types in a node is not economical and not
>>> realistic.
>>>
>>>
>>>
>>>  As far as my understanding of node design, we don't have such thing
>>> as you said in your email to support 10+ different types of
>>> regenerators in a node. In a typical commercially deployed WSON
>>> switching node, we have one rate (e.g., 10G or 40G, or possibly
>>>  others) and one regenerator type for each rate. If we have
>>> multi-rate  support, we may have two rates and thus two regenerators
>>> in a typical  WSON switching node.
>>>
>>>
>>>
>>>  I would be interested in the node design diagram that supports 10+
>>> different regenerators at the same time. I haven't seen such one
>>> myself yet.
>>>
>>>
>>>
>>>  Please also note that the WSON model has to support transparent
>>> node configuration, which we don't have "regen" element.
>>>
>>>
>>>
>>>  Best Regards,
>>>
>>>  Young
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  -------------------------
>>>
>>>  *From:[email-masked] [mailto:[email-masked]] *On
>>> Behalf Of *Margaria, Cyril (NSN - DE/Munich) **
>>>
>>>  Hi Greg, CCAMPers,
>>>
>>>
>>>
>>>  Regarding point (2), using one regen type per OTUk (k in [[1..4]]),
>>> and 2 type of laser module per reach makes already 8 type of oeo
>>> properties. Adding slightly different hw types (i.e old board with
>>> old modulation and a more recent with DP-QPSK) makes an easy 10
>>> types for a big node.
>>>
>>>
>>>
>>>  Without going into product families this sounded reasonable (for
>>> instance a typical product would indicate supports for 10 and 40g
>>> with different modulation, so lets say 2 sub-board type, which makes
>>>  6 regen type); The introduction of OTU4 and later OTU5 will
>>> increase the types of regenerator supported.
>>>
>>>
>>>
>>>  The size expansion is indeed related to the number of regenerator
>>> type, resource blocks contain connectivity, oeo-feature and how the
>>> blocks are grouped.
>>>
>>>
>>>
>>>  The other point would indeed clarify the document, the setup of
>>> resource pools/blocks is shown in Figure 1, a resource pool
>>> aggregating the connectivity for several resource blocks.
>>>
>>>
>>>
>>>  Best regards.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  *From:[email-masked] [mailto:[email-masked]] *On
>>> Behalf Of *ext Greg Bernstein **
>>>
>>>
>>>
>>>  Hi Pierre and draft authors, can you provide: (1) Diagrams of the
>>> example switches particularly with respect to the structure of the
>>> resource pools/blocks. (2) Explanation of why so many different
>>> types (not number) of regenerators in an optical node. You site 5
>>> different types for a small node and 10 for a large node. Can you
>>> point to a product family? I would think 0-1 types of regenerators
>>> for a small node and at maybe 2 for a large node or nodes that deal
>>> with long haul and metro types modulations. (3) Can you provide the
>>> example encodings such as done in the appendix of the encoding
>>> document so we can understand where the expansion is taking place.
>>>
>>>  It seems that the size expansions is directly related to the number
>>> of regenerator types, but hard to tell from this document. Are there
>>> any other WSON interested parties that have a need for so many
>>> regenerator types?
>>>
>>>  Cheers
>>>
>>>  Greg B.
>>>
>>>  On 6/10/2011 7:19 AM, PELOSO, PIERRE (PIERRE) wrote:
>>>
>>>  Hi Ccampers,
>>>
>>>  During Prague meeting I was asked to provide a draft detailing the
>>> solution we were presenting then concerning OSPF-TE extensions for
>>> Wavelength Switched Optical Networks (see point 10 of ccamp
>>> minutes). Julien, Giovanni, Cyril and I have tackled this work of
>>> providing a complete description of the solution with commonalities
>>> and deltas from the existing solution held in the following drafts:
>>> -
>>>  draft-ietf-ccamp-rwa-info-11 -
>>>  draft-ietf-ccamp-general-constraint-encode-04 -
>>> draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00 -
>>>  draft-ietf-ccamp-rwa-wson-encode-11 -
>>>  draft-ietf-ccamp-wson-signal-compatibility-ospf-04
>>>
>>>  Feedback from the working group is welcome.
>>>
>>>  To trigger this feedback, this draft holds inside section 5 a
>>> numerical study on the amount of static and dynamic information to
>>> be flooded. This study was conducted on various typical WSON nodes
>>> and compares the size of the LSAs between the two solutions.
>>>
>>>  Regards,
>>>
>>>  - Pierre
>>>
>>>
>>>  _______________________________________________ CCAMP mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>>
>>>
>>>  -- =================================================== Dr Greg
>>> Bernstein, Grotto Networking (510) 573-2237
>>>
>>>
>>>
>>>  _______________________________________________ CCAMP mailing list
>>> [email-masked] https://www.ietf.org/mailman/listinfo/ccamp
>> _______________________________________________
>> CCAMP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>
>
> --
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>
>
>
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Greg Bernstein <[email-masked]>
Date: Tue, 05 Jul 2011 07:50:17 -0700

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

> 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.
> 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 curren…
--> 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.
> 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 th…
--> 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.

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 8 Jul 2011 15:24:28 +0200

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.

> Of ext Greg Bernstein
> Sent: Tuesday, July 05, 2011 4:50 PM
> To: [email-masked]
> Subject: Re: [CCAMP] Moving the WSON discussion forward (Was Re: TR:
> New Version Notification fordraft-peloso-ccamp-wson-ospf-oeo-03.txt)
> 
> 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
> 
> > 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

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).
> >
> 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.
> separate sub-TLV and the current resource block set mechanism provides
> a highly efficient method to indicate which resources blocks are

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,

> > de Lou Berger Envoyé : mardi 28 juin 2011 16:57 À : Leeyoung;
> > [email-masked]
> > Cc : [email-masked]
> > Objet : [CCAMP] Moving the WSON discussion forward (Was Re: TR: New
> > Version Notification fordraft-peloso-ccamp-wson-ospf-oeo-03.txt)
> >
> 
> --

---

From: Greg Bernstein <[email-masked]>
Date: Fri, 08 Jul 2011 09:15:47 -0700

Hi Cyril, see comments below.
Cheers
Greg
> 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.
> TLVs should/may be flooded.
--> This is implementation and situation specific.
> 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
--> 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.
> 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.
> 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                      :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Wed, 13 Jul 2011 17:44:05 +0200

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]

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

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

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Wed, 13 Jul 2011 17:44:08 +0200

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

Best Regards,

Pierre

[SNIP] 

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

-->Pierre
What is to be gained is a little bit of space as all the information is concentrated in one entity, which enhances the overall compactness, but nothing big, I conceed.
Regarding the simplification of the extensions, this is not negligible discarding a sub-TLV that is redundant with another one, and hence enhances the coherence of the work.
And a document being at the stage of a WG document was not frozen in my understanding of it.

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Wed, 13 Jul 2011 17:44:13 +0200

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

Best Regards,

Pierre

[SNIP] 
>>>       3. Reduction of the scope of Resource Block Information, to 
>>> keep only resource/device description (moved the number of devices away).
>>> 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.
--> 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.

-->Pierre:
Thanks, for your answer Greg, but I am worried you answered without reading the whole point provided by Cyril.
At the stage, you've been answering, Cyril was stating what the logics of the draft-ietf-ccamp-rwa-info induces the reader to do, namely, use the resource blocks to achieve efficient encodings, I'm quoting the draft below (section 5):
"For modeling purposes and encoding efficiency identical processing resources such as regenerators or wavelength converters with identical limitations, and processing and accessibility properties are grouped into "blocks". Such blocks can consist of a single resource, though grouping resources into blocks leads to more efficient encodings."
And in the part of the email, below Cyril (and ourselves as well) is challenging the fact that for efficient encoding you end-up using a single resource per block, enforcing a proper resource block ID (then equivalent to resource ID) that allows efficient encoding as you can then luckily encode resource block sets with ID ranges. This is a very specific case, that effectively enables efficient encoding, but at which cost?
Then some questions were raised at the end of the email, like: 
   - 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?

     0                   1                   2                   3

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

---

From: Leeyoung <[email-masked]>
Date: Wed, 13 Jul 2011 16:32:30 +0000

Hi Pierre,

In regards to the top-level TLV discussion, please recall what you have agreed while ago from the archive. 
Between you and Fatai and Greg and Acee and myself, we basically agreed what I proposed: 

·         Use existing Node Attribute TLV for the connectivity matrix encoding

·         Create ONE NEW top level node TLV (name to TBD) to encode all the optical resource related information. 

As Greg, mentioned, we do NOT need to create multiple top level TLV's one for static and another for dynamic -- multi-instance is good enough, which has been well adopted practice. I just appended the archived emails to remind you what you have agreed in the past -- I thought this issue has been resolved clearly in the past. 

CCAMPers, please pardon me attaching a long list of email, but I just wanted to recall the WG what we have nailed down already with respect to one of the issues Pierre raised again recently. 

Thanks.

Young

--------------------------------------------------------------------------------
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

--------------------------------------------------------------------------------

To: Greg Bernstein <gregb at grotto-networking.com>, Acee Lindem <acee.lindem at ericsson.com> 
Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: "PELOSO, PIERRE (PIERRE)" <pierre.peloso at alcatel-lucent.com> 
Date: Mon, 17 Jan 2011 22:19:56 +0100 
Accept-language: fr-FR, en-US 
Acceptlanguage: fr-FR, en-US 
Cc: CCAMP <ccamp at ietf.org> 

--------------------------------------------------------------------------------
Hi everyone,
 
Point 1: I do agree as well to have a top level TLV for the connectivity matrix and another type of top level TLV to place the information related to oeo encoding.
Then I feel that we can conclude as agreed the usage of TE node attribute for the connectivity matrix.
 
Point 2: Regarding the oeo, creating a new type of TLV is a perfect solution, that I am supporting for sure.
Once this being agreed and before jumping too fast in editing http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signal-compatibility-ospf/, I am convinced that it is the right time to discuss how the encodings provided in http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-07.txt can be organized in the newly created top level TLV. Actually, for my part I see different options to take the best of this novelty concerning this layout of encodings.
 
Hence, as a WG, we have here a genuine opportunity to examine these options, thus possibly addressing during this review how those difference in layouts can influence the size of the corresponding LSA in order for those to fit in a single MTU as often as possible, while insuring OSPF scalability.
 
[For clarification needs, I do not mean changing the inner content of the encodings, I would just make sure that the way they are gathered inside the newly created top-level TLV is addressing everyone needs.]
 
Any comments?
 
Regards to all,
 
Pierre

--------------------------------------------------------------------------------
De : Greg Bernstein [mailto:gregb at grotto-networking.com] 
Envoyé : mercredi 12 janvier 2011 19:23
À : Acee Lindem
Cc : Leeyoung; Fatai Zhang; PELOSO, PIERRE (PIERRE); CCAMP
Objet : Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

Hi Acee, Young, Fatai and Pierre, 
the approach outlined below by Young and Acee below sounds great to me!
Best Regards
Greg
On 1/11/2011 5:34 PM, Acee Lindem wrote: 
Hi Young, Fatai, and Greg,  

I'm not too concerned about lifting the restriction on the single TE LSA containing the TE Node Attribute TLV. In fact, we are removing this restriction for ASON single in order for a control place node to advertise reachability information for more than one node in the transport place. However, I still don't think that the WSON switching capabilities belong here. As for the general constraints document, this looks more along the lines of what could go here. 

Thanks,
Acee

On Jan 11, 2011, at 5:21 PM, Leeyoung wrote:

Hi Pierre, Greg and Fatai,

I tend to agree with Fatai. Since the connectivity matrix is a generic aspect, we still can use existing TOP-level Node Attribute TLV. Please make sure that the connectivity matrix is non-WSON property. I think it was the intention of the CCAMP co-chairs to delineate WSON specific from Generic stuffs. 

If we can agree with this, I think we can create ONE new TOP level TLV, ?Node Attribute for Optical Resources? (tentative name) in which to advertise all Optical Resource related information. 

Although I still have problem understanding the RFC 5786 restriction on why the TE LSA wouldn?t allow more than one Node Attribute TLV, I want to resolve this issue and move the stalled OSPF extensions. 

So Pierre, Greg and Fatai, can we agree on this discussion. In summary:

·         Use existing Node Attribute TLV for the connectivity matrix encoding

·         Create ONE NEW top level node TLV (name to TBD) to encode all the optical resource related information. 

If we can agree, I think we can move on. If that is the case, I will update current WSON-specific WG draft (http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signal-compatibility-ospf/) to recommend use of a new top level node TLV for the encoding of all optical resource related information. 

And there is no change in Fatai?s draft (http://datatracker.ietf.org/doc/draft-zhang-ccamp-general-constraints-ospf-ext/) 

I look forward to hearing from you. 

Best Regards,

Young

--------------------------------------------------------------------------------

From: ccamp-bounces at ietf.org [mailto:ccamp-bounces at ietf.org] On Behalf Of Fatai Zhang
Sent: Sunday, January 09, 2011 7:59 PM
To: PELOSO, PIERRE (PIERRE); Greg Bernstein; Acee Lindem
Cc: CCAMP
Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

Hi Pierre and Greg,

I need to remind you both that [OSPF-Gen] ("draft-zhang-ccamp-general-constraints-ospf-ext-00.txt") is general (not specific to WSON). 

"Connectivity Matrix" defined in [OSPF-Gen] is a kind of node attribute, and it is static like "IPv4/v6 Local Address" defined in RFC5786, so we can resue "Node Attribute" top TLV to advertise Connectivity Matrix information without breaking the existing rules/restrictions defined in RFC5786.

For WSON specific information(ie., OEO stuff), I think we should define a new top TLV in order to comply with the rules defined in RFC5786 (or we may  life-up this restriction defined in RFC5786 as Young suggested).

Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

----- Original Message ----- 

From: PELOSO, PIERRE (PIERRE) 

To: Greg Bernstein ; Acee Lindem 

Cc: CCAMP 

Sent: Saturday, January 08, 2011 1:13 AM

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

Hi Greg, Acee and Every CCAMPers,

My answer is definitively two, Acee mentions there is no issue implementing one or two regarding OSPF, hence I really see no blocking point against two new Top level TLV.

On top of ensuring the split between static and dynamic information. It also provides an intrinsic structure of information organization.

One type of LSA is structured around the connectivity constraints of the nodes.

Another type of LSA is structured around the resources in the node. One instance per ressource block. Hence one LSA of this type updated only at each time.

This feature is achieved with no extra-cost on the overall information to be conveyed, while the one to be updated is intrinsically placed in independant LSA.

To conclude I am all the more convinced that we need to benefit of the inherent organization of information spread over multiple type of LSAs. It provides an inherent solution to address static and dynamic information inside nodes, which is altogether efficient regarding the amount of information to be updated, while providing a clear layout of information for OSPF-TE.

Pierre

--------------------------------------------------------------------------------

De : Greg Bernstein [mailto:gregb at grotto-networking.com] 
Envoyé : jeudi 6 janvier 2011 19:17
À : Acee Lindem
Cc : PELOSO, PIERRE (PIERRE); CCAMP
Objet : Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

Thanks Acee.  
Okay CCAMPers (Fatai and Pierre in particular) do we need one or two?  What would be the justification for two new Top level TLVs for node related information?  
We've talked before about static versus dynamic information, but for link information we seemed to have settled on using multiple LSA instances for this purpose, i.e., keep the static stuff in LSA instances different from the dynamic stuff (e.g. wavelength availability).  Hence I don't see the need for two top level TLVs.  

Greg

On 1/6/2011 9:24 AM, Acee Lindem wrote: 

Hi Greg,  

I think it is better to get 1 or 2 new top-level TE TLVs than to overload the TE Node Attribute TLV" with the optical capabilities information. 

Thanks,

Acee 

On Jan 3, 2011, at 11:55 AM, Greg Bernstein wrote:

Hi Pierre, do you think we should still try to use the "node attribute top level TLV" from RFC5786? A complete node description may require multiple connectivity matrices and these could potentially become large. RFC5786 has the constraint: 
    "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." 

So we couldn't split them up for MTU purposes. It seems that one new top level TLV for a node without the RFC5786 constraints would suffice. Do you think we need two? How would we justify two new top level TLVs to the OSPF WG when we have the ability to use multiple instances?

Other opinions?

Best Regards

Greg 
On 12/20/2010 4:27 AM, PELOSO, PIERRE (PIERRE) wrote: 

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 : ccamp-bounces at ietf.org [mailto:ccamp-bounces at ietf.org] 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.

 
<ATT00001..txt>

--------------------------------------------------------------------------------

 

--------------------------------------------------------------------------------

References: 
[CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: Greg Bernstein
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: PELOSO, PIERRE (PIERRE)
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: Greg Bernstein
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: Acee Lindem
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: Greg Bernstein
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: PELOSO, PIERRE (PIERRE)
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: Fatai Zhang
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: Leeyoung
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: Acee Lindem
Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
From: Greg Bernstein
Prev by Date: Re: [CCAMP] MIB Dr. review of draft-ietf-ccamp-gmpls-ted-mib-07 
Next by Date: [CCAMP] AD review of draft-ietf-ccamp-mpls-tp-cp-framework 
Previous by thread: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) 
Next by thread: Re: [CCAMP] Comment on draft-ietf-ccamp-oam-configuration-fwk 
Index(es): 
Date 
Thread  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of PELOSO, PIERRE (PIERRE)
Sent: Wednesday, July 13, 2011 10:44 AM
To: [email-masked]
Subject: [CCAMP] Change 1: Introduction of resource pool entity (was Re: Moving the WSON discussion forward)

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]

             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.

---

From: Greg Bernstein <[email-masked]>
Date: Wed, 13 Jul 2011 13:09:17 -0700

Hi Pierre, as previously stated:

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. Hence you can take it off the table.

Best Regards
Greg

On 7/13/2011 8:44 AM, PELOSO, PIERRE (PIERRE) wrote:
>> -snip-

---

From: Greg Bernstein <[email-masked]>
Date: Wed, 13 Jul 2011 13:46:54 -0700

As my example showed and your co-authors confirmed there was no net size 
change in the "many resource types case" from the current WSON WG draft. 
Hence this change is not needed.
Best Regards

Greg

---

From: Greg Bernstein <[email-masked]>
Date: Wed, 13 Jul 2011 13:53:09 -0700

Pierre, as previously stated multiple instances in OSPF-TE (RFC3630) 
allow one to decrease the flooding size for dynamic information. As 
RFC3630 indicates: "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.". This 
number of instances should be more than enough by far for all WSON 
applications.  Hence the proposed change is not needed.

Best Regards
Greg

On 7/13/2011 8:44 AM, PELOSO, PIERRE (PIERRE) wrote:
> ==snip==

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 14 Jul 2011 09:48:18 +0200

Hi Greg, 

There is one thing that really bother me is to have resource block IDs
with 16 bits 
With few motivation and without any definition in the WG-drafts if they
are stable or not.
The only statement I have seen is : 
"The RB identifier represents the ID of the resource block which is a 16
bit integer."

I would expect a 32 bit stable ID that match existing IDs assignments in
nodes. If a 32 bit ID is used the connectivity matrix as defined in
general constraint can be used. Your opinion is that it should be a
separate TLV in the WSON information, My opinion is that it could go in
the general node connectivity, because it's part of the node
connectivity. In the last couple of mail this did not change, I would be
interested to hear other people opinions.

Coming back to draft-ietf-ccamp-rwa-wson-encode resource block ids, this
16 ID was introduced in draft-ietf-ccamp-rwa-wson-encode-01 (March
2009), I have looked in the mailing list (only the web interface) and I
did not see any justification nor discussion on that topic. I may have
missed something, Could you indicate : 
  - should those ID be stable or not?
  - What is the motivation behind those 16 bit IDs?
  - What is the problem having 32 bit node unique ids? 

Best Regards

> Sent: Wednesday, July 13, 2011 10:09 PM
> To: [email-masked]
> Subject: Re: [CCAMP] Change 2: Use of connectivity matrix to describe
> pools accessibility (was Re: Moving the WSON discussion forward)
> 
> > 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 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.
the
> > number of connectivity representations introduced by current
> > extensions (draft-ietf-rwa-info proposes similar TLVs in different
> > LSAs)
> >
> > Best Regards,
> >
> > Pierre
> >
> > [SNIP]
> >
> >> -snip-

---

From: Greg Bernstein <[email-masked]>
Date: Fri, 15 Jul 2011 06:56:11 -0700

> With few motivation and without any definition in the WG-drafts if they
--> This allows for 65,536 resources per node.  I'm not sure what you 
mean by "stable". The assignments of resource block ID's to resources is 
provisioned  by the equipment. This assignment would be relatively 
"static", i.e., would not change with LSP creation or removal.
> nodes.
Which ID's in nodes?  Link IDs can take three different forms IPv4, IPv6 
and link local identifiers per GMPLS/MPLS standards.
> If a 32 bit ID is used the connectivity matrix as defined in
> general constraint can be used.
--> The connectivity matrix doesn't work with IDs of any kind. It works 
with "Link Sets".
>   Your opinion is that it should be a
--> What do you mean by stable?
>    - What is the motivation behind those 16 bit IDs?
--> Saves space; 65,536 resource block in a switch seems like plenty.
>    - What is the problem having 32 bit node unique ids?
--> Uses more space; Doesn't solve any problems that we know of.

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 15 Jul 2011 16:32:16 +0200

Hi Greg, 
Please see clarification inline

> From: ext Greg Bernstein [mailto:[email-masked]]
> Sent: Friday, July 15, 2011 3:56 PM
> To: Margaria, Cyril (NSN - DE/Munich)
> Cc: [email-masked]
> > with 16 bits With few motivation and without any definition in the
> > WG-drafts if they are stable or not.
> mean by "stable". The assignments of resource block ID's to resources
> is provisioned  by the equipment. This assignment would be relatively

I mean stable across control plane restart and configuration change.

> > "The RB identifier represents the ID of the resource block which is
a
> > 16 bit integer."
> >
> > I would expect a 32 bit stable ID that match existing IDs
assignments
> > in nodes.
> Which ID's in nodes?  Link IDs can take three different forms IPv4,
> IPv6 and link local identifiers per GMPLS/MPLS standards.

I mean unnumbered interface IDs. Node usually assign interface ids to
their
 different ports (being internal or external), this assignment tend to
be also 
 meaningful for the management system and are usually based on 32 bit
ids.

> > If a 32 bit ID is used the connectivity matrix as defined in general
> > constraint can be used.

I will rephrase then : 
 Using a 32 bit unnumbered interface identifiers would allow the 
 connectivity matrix as defined in general constraint to be used.

> > separate TLV in the WSON information, My opinion is that it could go
> > in the general node connectivity, because it's part of the node
> > connectivity. In the last couple of mail this did not change, I
would
> > be interested to hear other people opinions.
> >
> > 2009), I have looked in the mailing list (only the web interface)
and
> > I did not see any justification nor discussion on that topic. I may
> > have missed something, Could you indicate :
--> stable across control plane restart and configuration change (adding
new HW)

> --> Saves space; 65,536 resource block in a switch seems like plenty.
--> This has the inconvenient to add another assignment space in the
node, 
using unnumbered interface id is far more convenient and generic : if
you 
want also to model the 3R construct as a multi-layer (ML) (OCH/ODU)
matrix, then 
you will tend to address the 3R using unnumbered (or numbered) interface
id.
In general once you have an heuristic to compute a connectivity matrix
in general 
 using another space for some element is not convenient.

> --> Uses more space; Doesn't solve any problems that we know of.
Its not convenient if you go in the direction of ML representation
the oeo ingress/egress port  might become a link. 

BR

> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of ext Greg Bernstein
> >> through, I've been splitting the 3 points in 3 different threads,
> >> this one deals with change 2:
> >> order to describe connectivity constraints between node-external

---

From: Greg Bernstein <[email-masked]>
Date: Fri, 15 Jul 2011 13:33:11 -0700

Hi Cyril, the conversation below seems focused on relatively obscure 
details.
A resource block is not a link.  Sixteen bits versus 32 bits for a 
resource block id saves space.
The issue of "stability across control plane restart and configuration 
change" is not particular to resource block IDs, nor to WSON extensions 
of GMPLS. GMPLS link IDs can be changed.
Is there an actual problem you are trying to solve? If so, please state 
it in a succinct and clear fashion then we can all solve it.

Regards
Greg B.

---

From: Julien Meuric <[email-masked]>
Date: Mon, 18 Jul 2011 16:21:29 +0200

Hi Greg.

If there are "obscure details" in those drafts, discussing is an 
efficient way to bring them into the light and improve the content. I 
expect IETF documents to provide clear details that I can deploy. For 
instance, if ID stability is not mentioned, then I do not know why I 
would take it for granted.

Besides, your argument reads odd to me. Unnumbered interface IDs are 
32-bit long, while I guess nobody ever expected to make full use of a 
node-local ID space as large as IPv4. Size matters to implementers, 
especially as we are not building new protocols but extending existing 
ones. If 16-bit ID is more specific than a generic 32-bit ID, then we 
have "size vs. implementation efficiency"; since I care about size 
mainly for an efficiency purpose, then I believe a 32-bit length 
deserves to be considered.

Any opinion from implementers?

Regards,

Julien

Le 15/07/2011 22:33, Greg Bernstein a écrit :
> change" is not particular to resource block IDs, nor to WSON 
> extensions of GMPLS. GMPLS link IDs can be changed.
> Is there an actual problem you are trying to solve? If so, please 
> state it in a succinct and clear fashion then we can all solve it.
>
> Regards
> Greg B.

---

From: Greg Bernstein <[email-masked]>
Date: Mon, 18 Jul 2011 08:53:35 -0700

Hi Julien, if I recall the entire argument for changing the existing 
draft given in Prague was that the TLVs were somehow too big. We have 
shown that the analysis of this in Peloso-03 and Peloso-04 was false and 
that current encodings are as efficient or better than alternatives in 
Peloso-03/04.
As a implementer, I've found it easy to work with 16 bit and 32 bit 
lengths for identifiers.
Regards

Greg
On 7/18/2011 7:21 AM, Julien Meuric wrote:
>> The issue of "stability across control plane restart and 
>> configuration change" is not particular to resource block IDs, nor to 
>> WSON extensions of GMPLS. GMPLS link IDs can be changed.

---

From: Lou Berger <[email-masked]>
Date: Mon, 18 Jul 2011 12:46:51 -0400

Greg,
	It seems the discussion has moved on from the simple efficiency
discussion.  Use of consistent length identifiers and stability across
restarts are important, real world, implementation considerations.

Note, I'm not endorsing any changes here, just that (IMO) we should
ensure that issues that come out of this general discussion are covered
in the WG documents.

Lou

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Wed, 20 Jul 2011 16:15:26 +0200

Hi Greg,

The reason we are proposing a change, is that with current WG solution the updating process is not detailed, and leaves this in an implementation dependant interpretation, as is also the composition of each instance of the LSA. I would rather have a solution that specifies that as I see this as a facilitator for interoperability and commonality. Otherwise the WG believes that having a specified process of updates is not required.
My opinion on that is that in case the cost is low, let it be specified.
Using multiple type of top-level TLV is a way to formalize that, there can be alternative approachs, but if there is no constraint in using those, why not exploring this path, as long as nothing else is proposed?

Regards,

- pierre 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Greg Bernstein
Envoyé : mercredi 13 juillet 2011 22:53
À : [email-masked]
Objet : Re: [CCAMP] Change 1: Introduction of resource pool entity (was Re: Moving the WSON discussion forward)

Pierre, as previously stated multiple instances in OSPF-TE (RFC3630) allow one to decrease the flooding size for dynamic information. As RFC3630 indicates: "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.". This number of instances should be more than enough by far for all WSON applications.  Hence the proposed change is not needed.

Best Regards
Greg

On 7/13/2011 8:44 AM, PELOSO, PIERRE (PIERRE) wrote:
> 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:

---

From: Greg Bernstein <[email-masked]>
Date: Wed, 20 Jul 2011 08:04:49 -0700

I think this is more a question to the OSPF WG.
Are you asking when an LSA gets updated? They get updated when a newer 
one is received. By newer one that means one with the same "LSA instance 
number". Another top level TLV wouldn't help here  since updates are not 
based on TLVs, but on LSAs (OSPF folks please chime in).

Note that the the link state database (LSDB) is just a collection of 
LSAs.  Hence the way to get finer granularity in your updates is to use 
more "LSA instances".

Do you have a specific example in mind that can make this discussion 
more concrete?  If an optical node undergoes an in-service update 
(hot-swap) then it will want to send out LSAs reflecting this change. If 
the changes need to replace existing information in the LSDB then the 
same "LSA instance" numbers should be used to force the change. If the 
information is supplemental then new "LSA instance" numbers can be used.

Greg