Hi Lyndon,
I gave some extra thoughts about this, the switching type and encoding are not
enough to understand the label, I found a counter example :
- in SDH a VC4-4c label address the "starting" timeslot
--> without knowledge of the signal type its not possible to
distinguish between a VC4 and a VC4-4c, except if you mandate that
for this switching layer the Associated Traffic spec
(GENERALIZED-BANDWIDTH) is present.
- For ODU the label is relative to the HO-ODU, so this can change along the
path, so its also not possible to interpret it.
In that regard we cannot restrict the label chosen end-to-end, so the LABEL_SET
is not applicable but
but label inclusion/exclusion in the IRO/XRO would make sense.
The following text is considered:
The IRO as defined in [RFC5440] is used to include specific objects
in the path. RSVP allows to include label definition, in order to
fullfill requierement 13 the IRO should support the new TLV Type as
defined in [RFC3473]:
The L bit of such sub-object has no meaning within an IRO.
The XRO can follow the same semantic and encoding as in RFC5521
WG feedback is welcomed.
Best regards / Mit freundlichen Grüßen
Cyril Margaria
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Margaria, Cyril (NSN - DE/Munich)
> Sent: Monday, October 24, 2011 2:45 PM
> To: [email protected]
> Cc: [email protected]
> Subject: Re: [Pce] questions on gmpls extensions
>
> >
> > Hi Folks,
> >
> Hi,
>
> > I support completion of the GMPLS PCE extensions, but I did have a
> couple of questions on the draft:
> >
> > 1) How are the label set and suggested label objects used, given
> that labels are local
> > significance? Are these used only for the egress interface?
>
> The label set and suggested label are used to restrict the label for a
> given layer with end-to-end scope, the switching type and encoding are
> provided to interpret correctly the labels and scope the layer (for
> instance when combined with the inter-layer document where the path can
> use several layers).
> The switching type and encoding should in my opinion provide enough
> information to decode the label. If you think this is not enough,
> examples would be greatly appreciated.
>
>
> >
> > 2) Switching Type and LSP Encoding Type look like they could be
> in two spots, in the SWITCH-LAYER
> > object and in the ENDPOINTS object Label_Request TLV - did I
> misread this?
> > Or if this is correct, when would you use one vs. the other?
>
> In fact they could be in more than two spot, considering the inter-
> layer extensions :-) In case of mono-layer request they should be
> consistent, but in case of inter-layer requests the TE-LSP endpoint and
> layers considered might not have the same switching capabilities.
>
> Having separate switching type and encoding for the endpoint is
> explained in the document:
> "The REQ-ADAP-CAP object from [I-D.ietf-pce-inter-layer-ext] can be
> used in case of mono-layer request, however in case of multilayer it is
> possible to have in the future more than one object, so it is better to
> have a dedicated TLV for the label and label request (the scope is then
> more clear).
> "
>
>
> >
> > I did not find this on the archives, my apologies if this has been
> asked and answered before.
>
> I do not recall those to be asked. I hope the document and my answers
> address fully your questions.
> Any other clarification/questions is appreciated.
>
> Best regards,
> Cyril
> >
> > Cheers,
> >
> >Lyndon
>
>
>
>
>
>
>
> _______________________________________________
> Pce mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
