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" <ramon.casel...@cttc.es> To: <pce@ietf.org> Sent: Thursday, January 27, 2011 10:46 PM Subject: Re: [Pce] LABEL-SET as object and TLV in pcep-extensions-01 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, christian.kaas-peter...@tieto.com wrote: > 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. 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. > 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 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. > 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. > 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. > 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. 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 _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
