Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority

["Giovanni Martinelli (giomarti)" <[e-mail]>]

Hi Young,

btw first just a naming issue (I guess a question for the wg in general) the object label_set here has the same name name as the label_set form rfc3471 but it has actually a different encoding, so just asking if worth figuring out a little different name. If no one complain I'm fine too.

please see inline

On Aug 2, 2012, at 1:18 , Leeyoung wrote:

> <snip>
> On Aug 2, 2012, at 24:25 , Leeyoung wrote:
> 
>> Hi Giovanni,
>> 
>> The wavelength priority you propose seems different from the what we encoded per Rao Rajan's suggestion. What we encoded in section 2.3 of gen encode is not giving wavelength a priority level, among which I believe your wavelength property specifies.
>> 
>> What we are proposing is what labels are available/not available for each priority level (similar to LSP reservation or holding priority) as the following encoding dictates: 
>> 
> 
> 
> GM> So at the end is a "Label Priority" ? With the Label_Set granularity instead of the single Label?  
> 
> YOUNG>> No, this is not "label priority". Label is not "assigned" a priority. Label is neutral. Say, you have five wavelengths available for grab and you have two priorities you are aware of which is service level (e.g., LSP). For higher priority service, you may want to all your five wavelengths (w1-w5) available for grab while for lower priority, you may restrict to less number of wavelengths, say three wavelengths only (e.g., w1-w3).


GM> Well I'm not sure I'm following you, you say that labels are not assigned to a priority but then there is a priority associated to a label set. For sure label is neutral but "someone" decide if it goes in a label set with a certain priority, or in another (or in both label_set ). So, to me this means associate (is this term better than assign?) a priority to a label.



> Here you can see individual wavelength is not assigned a priority.


GM> the granularity is the label_set so you can easily see that's equivalent to individual label, anyway single label or label-set its not a substantial difference to me.



> This is analogous to how much BW availability for each priority in MPLS network, except that we need to express in wavelength level.  
> 
> 
> 
>>   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
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |A| Reserved    | Priority Flags|        Reserved               |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                           Label Set Field                     |
>>    :                                                               :
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>  Where
>> 
>>  A (Availability bit) = 1 or 0 indicates that the labels listed in
>>  the following label set field are available or not available,
>>  respectively, for use at a given priority level as indicated by the
>>  Priority Flags.
> 
> 
> GM> The reading here suggest me that there could be multiple objects (I bet up to 8) packed up somewere (e.g. something like sub-tlvs in the link advertisement). Is my interpretation correct?
> 
> YOUNG>> Yes. 
> 

GM> two encoding question here:
GM>  1/ why using flags instead of classical three bits? 
GM> 2/ What the usage of A? I mean you have an Available_label object and then you set A=0 which means that labels are not available... could you please clarify better?
 


Cheers
G



> Cheers
> G
> 
> 
>> 
>>  Priority Flags: Bit 8 corresponds to priority level 0 and bit 15
>>  corresponds to priority level 7. If a bit is set then the labels in
>>  the label set field are available or not available as indicated by
>>  the A bit for use at that particular priority level.
>> 
>> Let's begin if we are in agreement with this point. 
>> 
>> Thanks.
>> Young
>> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Giovanni Martinelli (giomarti)
>> Sent: Wednesday, August 01, 2012 12:40 PM
>> To: Giovanni Martinelli (giomarti)
>> Cc: CCAMP
>> Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority
>> 
>> Here my latest mail  with comments on wavelength priority... 
>> 
>> Here my memory on past discussion (please correct if wrong)
>> - last short thread was during ieft83 (around 26/28 march), last mail was from me and did not get answers. The content here below cover that mail as well.
>> - discussions about wl priority happens among authors not on ccamp mailing list. On the mailing list you announce draft update around dec 2011.  
>> 
>> Well, I'm not complaining about how discussion happen, simply I saw  a not-trivial addition to wg document, hence my comments.
>> 
>> Cheers
>> G
>> 
>> 
>> 
>> On Jul 31, 2012, at 24:34 , Giovanni Martinelli (giomarti) wrote:
>> 
>>> Dear authors / ccamp,
>>> 
>>> here a few comments related to the priority field added to draft-ietf-ccamp-general-constraint-encode:
>>> 
>>> A couple of editorial comments
>>> 1)  "wavelenght priority" appears in a draft that claim to be general. In fact is available in "Available Labels Sub-TLV" and "Shared Backup Labels Sub-TLV". So is a wavelength or label-like priority?
>>> 2)  why an 8 bits (bit field) instead of the classic 3 bits (integer [0 .. 7]?
>>> 
>>> 
>>> Then few other comments
>>> 3)  How the priority is used versus the A flag . Draft text report
>>> "  
>>> A (Availability bit) = 1 or 0 indicates that the labels listed in
>>> the following label set field are available or not available,
>>> respectively, for use at a given priority level as indicated by the
>>> Priority Flags.
>>> 
>>> "
>>> So does it means that there could be different "available labels sub-TLVs" advertised? 
>>> 
>>> 4) Still unclear to me how this priority is different from the one reported in http://tools.ietf.org/html/draft-kattan-wson-property-01 and eventually if this "priority" could fit the LSP priority already available (as one of the comment we received at that time)
>>> 
>>> Cheers
>>> G
>>> 
>> 
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>