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

[Julien Meuric <[e-mail]>]

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