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

["Margaria, Cyril (NSN - DE/Munich)" <[e-mail]>]

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


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