Re: [CCAMP] Change 2: Use of connectivity matrix to describe pools accessibility (was Re: Moving the WSON discussion forward)

[Greg Bernstein <[e-mail]>]

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:
> 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 :
>> 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.
>> On 7/15/2011 7:32 AM, Margaria, Cyril (NSN - DE/Munich) wrote:
>>> Hi Greg,
>>> Please see clarification inline
>>>
>>>
>>>> -----Original Message-----
>>>> From: ext Greg Bernstein [mailto:[e-mail]]
>>>>
>>>> Hi Cyril, see comments below.
>>>> Greg
>>>> On 7/14/2011 12:48 AM, Margaria, Cyril (NSN - DE/Munich) wrote:
>>>>> 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.
>>>> -->  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.
>>> I mean stable across control plane restart and configuration change.
>>>
>>>
>>>>> 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.
>>>> 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.
>>>> -->  The connectivity matrix doesn't work with IDs of any kind. It
>>> works
>>>> with "Link Sets".
>>> I will rephrase then :
>>>   Using a 32 bit unnumbered interface identifiers would allow the
>>>   connectivity matrix as defined in general constraint to 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 do you mean by stable?
>>> -->  stable across control plane restart and configuration change 
>>> (adding
>>> new HW)
>>>
>>>>>     - What is the motivation behind those 16 bit IDs?
>>>> -->  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.
>>>
>>>
>>>>>     - What is the problem having 32 bit node unique ids?
>>>> -->  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
>>>
>>>>>
>>>>> Best Regards
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [e-mail] [mailto:[e-mail]] On
>>>>>> Behalf Of ext Greg Bernstein
>>>>>> Sent: Wednesday, July 13, 2011 10:09 PM
>>>>>> To: [e-mail]
>>>>>> Subject: Re: [CCAMP] Change 2: Use of connectivity matrix to
>>>> describe
>>>>>> pools accessibility (was Re: Moving the WSON discussion forward)
>>>>>>
>>>>>> 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:
>>>>>>> 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]
>>>>>>>
>>>>>>>> -snip-
>>>>>>> _______________________________________________
>>>>>>> CCAMP mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>>
>>>>>>>
>>>>>> -- 
>>>>>> ===================================================
>>>>>> Dr Greg Bernstein, Grotto Networking [phone]
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> CCAMP mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>
>>>> -- 
>>>> ===================================================
>>>> Dr Greg Bernstein, Grotto Networking [phone]
>>>>
>>>
>>>
>>
>>
>
>


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