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

[Lou Berger <[e-mail]>]

Rajan/Young,
	I think it also would be helpful to have a description *in the draft*
of how & when the availability bit=0 is used.

(For example, what does it mean to have the bit =0 and an label set with
an exclusive action?)

Lou (as WG participant)

On 8/2/2012 1:39 PM, Rajan Rao wrote:
> Giovanni,
> 
> My comment  few months ago was to cover bandwidth advertisement at
> all 8 priority levels  as in PSC, TDM & TDM-OTN switching cases.
> The priority based advertisement in WSON/LSC  is no different from
> other cases.
> 
> What might be useful is to add couple of examples to show how this is
> used along with other flags.
> 
> Hope this helps.
> Thanks
> Rajan
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Leeyoung
> Sent: Thursday, August 02, 2012 9:57 AM
> To: Giovanni Martinelli (giomarti)
> Cc: CCAMP
> Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority
> 
> Hi Giovanni,
> 
> Please see in-line for my responses.
> 
> Thanks. 
> 
> -----Original Message-----
> From: Giovanni Martinelli (giomarti) [mailto:[e-mail]]
> Sent: Thursday, August 02, 2012 11:16 AM
> To: Leeyoung
> Cc: CCAMP
> Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority
> 
> 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.
> 
> YOUNG>> We are expanding the label set concept from 3471. I am not sure if there is a new name needed here. I defer this to WG chairs. 
> 
> 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.
> 
> YOUNG>> I think I explained enough what the current encoding is. This is about what labels are available for LSP priority. Some labels may be available for more than one LSP priority. There is no 1:1 "association" between label and priority per se. 
> 
>> 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?
>  
> YOUNG>> Yes, three bits can do that. We put A=0 (not available) --just to give more flexibility. That's all. If you want to restrict some ranges of labels to lower LSP, using A bit (A=0) would be more efficient to express such need. 
> 
> 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
>>
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
>