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

[Lou Berger <[e-mail]>]

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

On 7/18/2011 11:53 AM, Greg Bernstein wrote:
> 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]
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 
>