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

Leeyoung <leeyoung@huawei.com> Fri, 10 August 2012 22:42 UTC

Return-Path: <leeyoung@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C052711E80BA for <ccamp@ietfa.amsl.com>; Fri, 10 Aug 2012 15:42:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.48
X-Spam-Level:
X-Spam-Status: No, score=-6.48 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5D3rsKS+3qQX for <ccamp@ietfa.amsl.com>; Fri, 10 Aug 2012 15:42:43 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E82E411E80AD for <ccamp@ietf.org>; Fri, 10 Aug 2012 15:42:42 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfwdlp03-ep.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJC61444; Fri, 10 Aug 2012 14:42:42 -0800 (PST)
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 10 Aug 2012 15:41:59 -0700
Received: from dfweml511-mbs.china.huawei.com ([169.254.15.49]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Fri, 10 Aug 2012 15:41:56 -0700
From: Leeyoung <leeyoung@huawei.com>
To: Rajan Rao <rrao@infinera.com>, "Giovanni Martinelli (giomarti)" <giomarti@cisco.com>
Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority
Thread-Index: AQHNcAyuJFh0KZM0PEuR5rvzvXz1+5dFha9ggAB9XQD//4xN4IABmgCA//+RYuCAAIYUgIAK0m1AgACdVID//9B+8AAqpkQAAASSEuA=
Date: Fri, 10 Aug 2012 22:41:55 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172906081A@dfweml511-mbs.china.huawei.com>
References: <98310D9B-8BF2-4C16-ABEF-F96D1DE1675C@cisco.com> <63F9D750-59E0-487B-B590-DCC2D3EBC344@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED40@dfweml511-mbs.china.huawei.com> <47594FF6-97E2-401A-8703-FAD081F28635@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED70@dfweml511-mbs.china.huawei.com> <48F63A76-53E9-4C38-A266-8B8BAB9F7838@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905EEC1@dfweml511-mbs.china.huawei.com> <650AA355E323C34D9D4AAEED952E053D347EE54E@SV-EXDB-PROD2.infinera.com> <7AEB3D6833318045B4AE71C2C87E8E172905FCB0@dfweml511-mbs.china.huawei.com> <650AA355E323C34D9D4AAEED952E053D34807E2F@SV-EXDB-PROD2.infinera.com> <7AEB3D6833318045B4AE71C2C87E8E172906059C@dfweml511-mbs.china.huawei.com> <650AA355E323C34D9D4AAEED952E053D3480A337@SV-EXDB-PROD2.infinera.com>
In-Reply-To: <650AA355E323C34D9D4AAEED952E053D3480A337@SV-EXDB-PROD2.infinera.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.112]
Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172906081Adfweml511mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: CCAMP <ccamp@ietf.org>, Ashok Kunjidhapatham <akunjidhapatham@infinera.com>, Subhendu Chattopadhyay <SChattopadhyay@infinera.com>, Mohit Misra <mmisra@infinera.com>
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Aug 2012 22:42:46 -0000

Hi Rajan,

I think we are in agreement in all the issues on priority encoding for Available/Shared backup Label Set sub-TLV.

CCAMP WG, please send your comments on this discussion if you have other thoughts or differing opinions.

Thanks,
Young

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao
Sent: Friday, August 10, 2012 12:50 PM
To: Leeyoung; Giovanni Martinelli (giomarti)
Cc: CCAMP; Mohit Misra; Ashok Kunjidhapatham; Subhendu Chattopadhyay
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority


Young,



Pl see inline



Thanks

Rajan



-----Original Message-----
From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Thursday, August 09, 2012 10:10 PM
To: Rajan Rao; Giovanni Martinelli (giomarti)
Cc: CCAMP; Subhendu Chattopadhyay; Ashok Kunjidhapatham; Khuzema Pithewan; Biao Lu; Mohit Misra
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority



Hi Rajan,



I think what you are suggesting is all agreeable with me. Please see in-line for my comment.



Regards,

Young



-----Original Message-----

From: Rajan Rao [mailto:rrao@infinera.com]<mailto:[mailto:rrao@infinera.com]>

Sent: Thursday, August 09, 2012 7:18 PM

To: Leeyoung; Giovanni Martinelli (giomarti)

Cc: CCAMP; Subhendu Chattopadhyay; Ashok Kunjidhapatham; Khuzema Pithewan; Biao Lu; Mohit Misra

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



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.



YOUNG>> Bit-map is most basic representation of Action Field. If you prefer Bit-map set representation, then Action Field in Label Set TLV would be Action == 4, which is Bit Map set. We can make this value (==4) as only valid option, if you prefer. Inclusive List/ Inclusive Range might be still useful for compact encoding for some cases.





b)  A-bit is  not useful/redundant  we can take it out.



YOUNG>> It can be done that way. Not a problem.



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.



YOUNG>>  8 bit vs 3 bit is not an important issue. As you said, if PSC, TDM use 8-bit, we can put 8-bit flag back to encoding.





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



YOUNG>> Agreed.



c) Priority  field is not required as Action field identifies resources @ priority-p for the LSP being setup @ priority-p.



YOUNG>> Yes. Since LSP has its priority so we do not need to make use of priority field. ---- is this your logic?

Rajan>>  during LSP setup the LSP priority is already known (setup/holding).   I do not see any value in providing a label set that contains labels for priorities other that what is being requested.   I think it is sufficient for upstream to provide label set for the priority  for which LSP is being setup.



Would like to hear comments from others as well.



YOUNG>> So the only changed in this draft would be: (i) delete A bit,

YOUNG>> (ii) make priority bit == 8 (if others agree).  Routing draft

YOUNG>> will refer to this draft and will need to specify valid Action

YOUNG>> Fields for its use. (We agreed not to use Exclusive Range/List

YOUNG>> while use of Bit Map is agreed. Inclusive Range/List may need to

YOUNG>> be further debated.)



YOUNG>> Signaling draft will do the similar thing.



Rajan>>  it is perhaps cleaner to define a new TLV without  priority field for use in signaling.   This will avoid confusion.



Thanks

Rajan



-----Original Message-----

From: Leeyoung [mailto:leeyoung@huawei.com]<mailto:[mailto:leeyoung@huawei.com]>

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:rrao@infinera.com]<mailto:[mailto:rrao@infinera.com]>

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: ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org> [mailto:ccamp-bounces@ietf.org]<mailto:[mailto:ccamp-bounces@ietf.org]> 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:giomarti@cisco.com]<mailto:[mailto:giomarti@cisco.com]>

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: ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org> [mailto:ccamp-bounces@ietf.org]<mailto:[mailto:ccamp-bounces@ietf.org]> 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

>> CCAMP@ietf.org<mailto:CCAMP@ietf.org>

>> https://www.ietf.org/mailman/listinfo/ccamp

>



_______________________________________________

CCAMP mailing list

CCAMP@ietf.org<mailto:CCAMP@ietf.org>

https://www.ietf.org/mailman/listinfo/ccamp