Subject: Re: [Pce] questions on gmpls extensions

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 24 Oct 2011 14:45:21 +0200

> 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

---

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

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-masked] [mailto:[email-masked]] On Behalf Of
> Margaria, Cyril (NSN - DE/Munich)
> Sent: Monday, October 24, 2011 2:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Pce] questions on gmpls extensions
> 
> >
> > Hi Folks,
> >
> Hi,
> 
> 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.
> 
> 
> >
> >         object and in the ENDPOINTS object Label_Request TLV - did I
> misread this?
> 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.
> 
> 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).
> "
> 
> 
> >
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce