Subject: [Pce] LABEL-SET as object and TLV in pcep-extensions-01

From: <[email-masked]>
Date: Wed, 26 Jan 2011 21:46:32 +0200

Reading the draft-ietf-pce-gmpls-pcep-extensions-01 document, the definition
and use of LABEL-REQUEST, LABEL-SET, and SUGGESTED-LABEL-SET need further 
clarification.  The clarification concerns the said items being both objects 
and TLVs.

I'll consider LABEL-SET in detail.

LABEL-SET as an object is specified in section 2.5, but half-way
through the section, LABEL-SET is referred to as a TLV appearing in the
ERO object (and so LABEL-SET is a TLV of an RSVP object).  Further 
LABEL-SET is also a TLV specified in section 2.4.2.5,
where it appears in the new Generalized endpoint Object Type for the
END-POINTS object.  Therefore I should like to have the following clarified.

In a PCReq, LABEL-SET can appear both as a PCEP object in its own right, and as
a PCEP TLV in the END-POINTS object, when the END-POINTS object is the new
Generalized endpoint Object Type.  It is not clear to me, what difference
it makes to the semantics of the PCReq, whether LABEL-SET appears as
an object, as a TLV in END-POINTS, or indeed can appear in both places.

It is not clearly stated in the draft, but I think the LABEL-SET can appear
in a PCRep as a PCEP object listing useable labels for the path returned.
What is stated is that the LABEL-SET can appear as a TLV being part of
the ERO returned.  If LABEL-SET indeed can be returned as a separate object,
the syntax for the <response> appearing at the beginning of chapter 2
should be updated to reflect that.

Because LABEL-SET is added as a new object, this should be added to
the IANA considerations, section 5.1.

I am not fully clear as to whether all the above observations for the
LABEL-SET are equally applicable to LABEL-REQUEST and SUGGESTED-LABEL-SET,
but also these two are introduced both as objects and TLVs.

Also correct the packet layout in sections 2.2 and 2.3 such that
it is clear Traffic Spec and Min Traffic Spec can be seen having         
variable size.

Christian

---

From: Ramon Casellas <[email-masked]>
Date: Thu, 27 Jan 2011 15:46:10 +0100

Dear Christian, PCErs

Thank you for your comments, this is indeed one of the open issues in 
the draft. Please see inline for some of my views.

On 26/01/2011 20:46, [email-masked] wrote:

> clarification.

We have had some discussions about this in the past, and I am afraid we 
still don't have a consensus. The main problem with the LABEL_SET object 
(and to some extent with SUGGESTED_LABEL and UPSTREAM_LABEL) is that the 
semantics are slightly different depending of the context. Let me 
explain, and apologies if this is well-known,
it is clear that in MPLS-TE (or GMPLS PSC, etc) labels are, by 
definition, local to a link between two nodes. A LABEL_SET defines which 
labels are usable in that scope. However, when deploying GMPLS for WSON 
(and other swcap such as PBB-TE) there are technological constraints 
such as the Wavelength Continuity Constraint. With this in mind, the 
LABEL_SET in WSON has been "abused" to imply which labels are usable end 
to end. (e.g. the LABELSET includes which labels are usable and it is 
trimmed by nodes along the path, or re-expanded when a regenerator / 
converter is used. Lack of LABELSET is typically assumed as a failure to 
find continuous wavelengths. However, in MPLS lack of LABEL_SET implies 
that any label is ok).

Since the GMPLS extensions need to apply at all layers, we have 
seemingly opposite concepts: on the one hand, MPLS defines a label as 
local to a link representing a FEC, WSON a label is implicitly a 
wavelength, end-to-end within a transparent segment without converters. 
Things can get much worse :) when considering translucent networks where 
the label has to remain constant along one or more transparent segments. 
If we assume that, regardless of how it is encoded (TLV, top level 
object, etc) , in a PCEP request the LABEL_SET is supposed to convey 
constraints in the path computation, and in a PCEP response it is 
supposed to convey attributes, without knowledge of the swcap the 
request applies to, or with extra assumptions, it is not possible to 
know what the constraints apply to.

> ERO object (and so LABEL-SET is a TLV of an RSVP object).  Further

In my opinion, this is indeed a problem with the draft in its current 
form, but I haven't yet reported to Editors about this. I am unsure how 
a variable sized object such as the ERO can include TLVs. At what point 
does the parser stop parsing subobjects to start parsing TLVs?, the 
first TLV would be wrongly parsed as a (possibly unknown) sub-object. 
The intended use as I suggested then was as RSVP ERO sub-object, not as 
TLV.

FWIW, I am a proponent of LABEL_SET as top level object, also  ENDPOINTS 
TLV since we need to convey info say.e.g about tunability of an 
interface, and, additionally, as a new ERO subobject.

> an object, as a TLV in END-POINTS, or indeed can appear in both places.

As you point out, there is still a lot of work to do in this area. My 
(subjective) view is as follows:

Request

a) - a LABEL_SET within ENDPOINTS (as TLV) applies at that endpoint and 
swcap and constraints the endpoint. The direct use case would be 
transceiver tunability

b) - a LABEL_SET within a request (not exactly within a PCReq, although 
people commonly refer to objects within a PCReq) was defined to cover 
the case of "the labels that apply to the end-to-end path" and "only 
consider these labels for wavelenght allocation"

c) - a LABEL_SET within a SVEC tuple could (To be done, for further 
study) convey constraints that apply to all involved requests, in line 
with previous bullet.

Response

d) - a LABEL_SET as a new ERO sub-object  (not as TLV) as I suggested 
would be the only meaningful way that a PCE could restrain the use of a 
set of labels in a link along the path. RSVP-TE could easily generate 
the outgoing Labelset object directly while processing the ERO 
sub-object. This would extend the "explicit label control", to support 
"explicit labelset control": a new sub-object would be needed that would 
constrain the possible labels in the scope of the link that the 
subobject applies to, unambiguously.

e) - a LABEL_SET as a top level object (within the path attributes) 
would convey the initial outgoing LABEL_SET for the LSP. Whether this 
refers to the end to end path or just a hop, we don't know, and that's 
dependent on the context.

> in a PCRep as a PCEP object listing useable labels for the path returned.
This is in line with what I just mentioned. We used to add a LABEL_SET 
top level object such as this extension in WSON, implying b) and e) but 
it was not completely satisfactory.
It was clear that "Usable labels for the path" implies label continuity 
constraint or some other related constraint that does not necessarily 
apply to local labels and all swcap that the PCEP extensions for GMPLS 
should cover.  In other words, a _Path_ LABEL_SET does not make sense if 
labels can change. If you consider all switching capabilities 
generically, what would a LABEL_SET mean in a response within a PCRep? 
the set of usable labels for the "first hop"?, for the "transparent 
segment"?, for the "end to end path"?

However, for maximum flexibility we would like to be able to constrain 
and convey information about resources for cases such as WSON. How do 
you extend PCEP to support the use cases of WSON / LSC while remaining 
generic for say, PSC or MPLS-TP? that's what we would like to cover with 
the draft.

Thank you for your comments clearly highlighting that more work is 
needed in this area :)

Corrections and comments more than welcome.

Best regards,

Ramon

-- 
Ramon Casellas, Ph.D.
Research Associate - Optical Networking Area -- http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
Av. Carl Friedrich Gauss 7 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 16 -- Fax. +34 93 645 29 01

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 31 Jan 2011 14:33:03 +0800

Hi Ramon and Christian,

I agree with Ramon that we should refine the description on the Label format  (Lebel,Label_Set, Suggested_Label)  based on the different cases  in PCReq and PCRep messages (e.g. Endpoints, E2E constraint, ERO, SVEC).

Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

----- Original Message ----- 
From: "Ramon Casellas" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 27, 2011 10:46 PM
Subject: Re: [Pce] LABEL-SET as object and TLV in pcep-extensions-01

Dear Christian, PCErs

Request

Response

Best regards,

Ramon

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 31 Jan 2011 14:23:51 +0100

Hi all, 

I also agree that works is needed to clarify the Label set object scope
and procedure, 
Please see inline for some of my comments

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Ramon Casellas
> Sent: Thursday, January 27, 2011 3:46 PM
> To: [email-masked]

I do not fully agree here, I do notsee WSON abusing the LABEL_SET: 
In WSON the label set is ustill pdated by each node along the path 
to reflect the link-local label that can be allocated by a node.
Label switching constraint do apply, but as you stated 3R allow to 
have a different label set.

> know what the constraints apply to.

I do agree, The LABEL_SET in the PCReq restricts the label to be 
allocated (if any) by the PCE along the path This is more restrictive 
than the LABEL_SET seen in signaling, it make sense as a kind of policy 
input . For instance in WSON context using specific wavelength range 
because of optical/modulation format  quality policy, or because of 
network-wide label allocation policy.

The presence of the LABE_SET should not imply that the label has to be 
the same end-to-end. The indication that the route should use a single 
label end-to-end should use another attribute, which is open for
discussion.

> The intended use as I suggested then was as RSVP ERO sub-object, not
as

The text does not describe the LABEL-SET as ERO sub-object, it specify :
"Any label included in the ERO object on the response must comply with
the
   restrictions stated in the LABEL SET,".
This apply to the labels in ERO. I think this could be rephrased to
avoid
reader confusion.

Having the LABEL-SET as ERO sub-object should be discussed in the
context
of ccamp WG.

<cut, I agree with Ramon>

> segment"?, for the "end to end path"?

The draft should be revised to indicate that the LABEL-SET is allowed in
the respons, 
That each label-set TLV should be scoped by the corresponding label
request and is 
significant for the first HOP of the layer.

Best regards, 
Cyril

---

From: Ramon Casellas <[email-masked]>
Date: Mon, 31 Jan 2011 15:08:08 +0100

Cyril, all

Please see inline

> have a different label set.
Probably I should have written it better :) : "abused" in the sense 
that, although perfectly valid, is used (and almost mandatory) to obtain 
the end-to-end labels, although some may (questionably/arguably) object 
that it was not the initial spirit of the LABEL_SET given its local 
nature in "MPLS-TE".
In any case, we are in line in this aspect, it was basically "background".

> label end-to-end should use another attribute, which is open for

Good point. A LABEL_SET within a request applies to all links along the 
path, and not necessarily assume end-to-end uniqueness (WCC). So a 
LABEL_SET within a request is a constraint that applies to all links of 
all the paths of the corresponding response, right?

> therestrictions stated in the LABEL SET,".

No it does not :) ... I replied to the original question mentioning the 
TLV within an ERO (Christian's comment was "What is stated is that the 
LABEL-SET can appear as a TLV being part of the ERO returned"). I have 
not actually found that text in the draft (?) but I meant that  is IMHO 
wrong (not being able to see the boundary between subobjects and TLVs 
while parsing) , and that I understand that the way to have the "TLV" 
within the ERO would be by means of a new sub-object. Such "LABEL_SET 
sub-object" was my own suggestion (not currently in draft).
.

> context of ccamp WG.
fully agree

Thanks

R.

---

From: <[email-masked]>
Date: Mon, 31 Jan 2011 16:15:15 +0200

Just for clarification: I misinterpreted the sentence in sec 2.5 "Any label included ..."
to mean the LABEL-SET was included in the ERO.  Sorry for the confusion.

Christian

No it does not :) ... I replied to the original question mentioning the
TLV within an ERO (Christian's comment was "What is stated is that the
LABEL-SET can appear as a TLV being part of the ERO returned"). I have
not actually found that text in the draft (?)