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

[Rajan Rao <[e-mail]>]

Young, et al

The confusion is mainly about which fields are applicable where. We need to clarify usage for routing and signaling cases for the following fields:

- Action field  in Label set
- A-bit  in Available Labels
- Priority field in Available labels

 Let us agree on what is required for routing and signaling:

1) Routing:   cares about what lambda is available at what priorities.    So,  
 a)  Action =  inclusive List |  Inclusive Range | BitMap  are useful.  
      Action =  Exclusive List | Exclusive Range   is not of much use   
      My preference would be to go with one option (bit-map) and don't expose Action field at all in  BW advertisements. Like to hear from others.

 b)  A-bit is  not useful/redundant  we can take it out.
 c) Priority field is useful/required.   Regarding 3bit field Vs. 8bit field,   I would go with 8-bit field to be consistent with usage in PSC, TDM encodings. They use 8-bit priority field.


2) Signaling:  cares about what lambda to use or not use for an LSP.  So,
 a) Action field  -  all values are applicable
 b) A-bit  is not required
 c) Priority  field is not required as Action field identifies resources @ priority-p for the LSP being setup @ priority-p.

Would like to hear comments from others as well.

Thanks
Rajan

-----Original Message-----
From: Leeyoung [mailto:[e-mail]] 
Sent: Thursday, August 09, 2012 3:45 PM
To: Rajan Rao; Giovanni Martinelli (giomarti)
Cc: CCAMP
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority

Hi Rajan and Giovanni, 

Per your request, the following two changes can be made to Generic Constraint Encode draft.

1. Priority Flags are changed to 3 bits 

2. Illustrative Examples are given in Appendix. 

Check if this makes sense and give me your comments. Once we would agree on this, all the pending issues will be closed and we can update the draft ready for WG LC.

Best Regards,
Young

---------------------------------------------------------------------------------------------------------------

1. The following is a new encoding for Available/Shared Backup Labels Sub-TLV:

2.3 (2.4) Available (Shared Backup) Labels sub-TLV 

The Available (Shared Backup) Labels sub-TLV link consists of an availability flag, priority flags, and a single variable length label set field as follows:
   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| PRI |                        Reserve                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |				    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.

PRI (Priority Flags, 3 bits): Indicates priority level applied to Label Set Field. 
	000: Priority Level 0
	001: Priority Level 1
      010: Priority Level 2
	011: Priority Level 3
	100: Priority Level 4
	101: Priority Level 5
	110: Priority Level 6
	111: 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.


2. Illustrative Examples


A.5. Priority Flags in Available/Shared Backup Labels sub-TLV 

If one wants to make a set of labels (indicated by Label Set Field #1) available for all priority levels (level 0 to 7) while allowing a set of labels (indicated by Label Set Field #2) only to available to the highest priority (Priority Level 7), the following encoding will express such need. 

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |1|0 0 0|                        Reserved	                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |					Label Set Field #1    		     |
  :										    :
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |1|1 1 1|                        Reserved	                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |					Label Set Field #2                 |
  :										     :
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Alternatively, the following encoding expresses the same need by using A bit (A=0) as a mechanism to make unavailable a certain set of labels for all priority levels except the highest priority Level 7. 
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0|1 1 0|                        Reserved	                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |					Label Set Field #2                  |
  :					      				     :
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that when a set of labels (indicated by Label Set Field #2) is unavailable for Priority Level 6 (indicated by Priority Flag 110), this implies that these labels are not also available for lower Priority levels, 0-5. The above encoding also implies that all other labels except those defined under Label Set Field #2 are available for all priority levels.

-----Original Message-----
From: Rajan Rao [mailto:[e-mail]]
Sent: Thursday, August 02, 2012 12:40 PM
To: Leeyoung; Giovanni Martinelli (giomarti)
Cc: CCAMP
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority

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