Hi Fabien and Adrian, Looking at the discussion, path computation itself and a protocol staff such as PCEP are a different thing. I believe, touch upon by Dan, that our cspf draft is a kind of guideline how to consider GMPLS-specific constrains including encoding type for path computation. I hope that the cspf draft help Fabien to understand parameters.
If you need any help for GMPLS specific extensions, please let me know. With best regards, Tomo Adrian Farrel wrote: > Hi Fabien, > >> Reading the generic and inter layer requirement documents it is not >> clear to me if Switching Type is really specific to inter layer >> application. >> As far as I understand inter-layer requirement refers to path >> computation which result path may comprise multiple layer technologies. >> Though I understand Switching type is required in this context, it is >> also >> required for mono layer path computation in a multi-layer environment >> (e.g. to computate a Lambda path using a TE Database that contains >> also TDM TE Links). >> So it is more a GMPLS specific requirement to me. > > I think you are correct. That is, the switching type constraint is > required in the multi-layer context, but it may have wider applicability. > > Provided that the multi-layer work progress quite quickly, I would > suggest that it is convenient to group all of the protocol extensions > together. You can then select from the set of optional objects as > necessary for your application. I would hope that you would provide your > review input to the multi-layer work to ensure that the protocol > extensions give you what you need. > > On the other hand, if the multi-layer work seems to get stuck or held > up, then I would understand you pushing to get the "GMPLS-specific" > extensions done separately. > >> Acually it is not clear to me what is the scope of generic and >> "application specific" requirements. Generic Requirement RFC4657 >> section 5.1.16 >> mention Switching and encoding type as "GMPLS specific requirements". >> Does it mean "GMPLS specific" is "considered as generic? > > Hmmm. > This is a line we have not succeeded in drawing very clearly. > > However, where we seem to have arrived is that the PCEP I-D contains the > protocol definition and "core" functional units. Other units that were > identified in 4657 (such as XRO, objective funcions, ...) are going into > seperate I-Ds. Following that model, the GMPLS-specific work definitely > goes into a separate draft. As above, I am comfortable for that to be in > the multi-layer I-D (perhaps we re-name to "GMPLS and multi-layer"?) to > help keep the number of I-Ds manageable. > >> Concerning the necessity of "encoding type" in PCEP I have to admit >> that I'm not sure to correctly understand the meaning of this >> parameter in the GMPLS >> architecture :-). > > I think this puts you in the majority! > >> What I understand at least is that it is both an interface and >> an LSP property, so from this it seems to be required in PCEP. >> I would be interested to see discussion about encoding type >> requirement in PCEP cause it may clarify the encoding type meaning to >> me ;-). > > So my view (other will surely correct me :-) is that encoding type is > only needed where the signal is unpacked for some reason. Typically, > this only happens at end points, so the PCE function is to ensure that > the destination interface is capable of decoding the signal and > delivering the data. In general, it has been considered that the > destination capabilities are either known to the ingress (guaranteed LSP > setup success - you wouldn't even bother trying to set up an LSP to > someone you knew couldn't understand you) or are not known in which case > the LSP will either succeed or fail (but no amount of re-routing will > help). Now, it *is* possible that different interfaces on the egress > have different levels of support for encoding types, but this has > generally been considered as very advanced and not worth optimising for. > > However, recent discussion has suggested that in certain technologies, > signal regeneration also requires knowledge of the encoding type. This > would certainly expand the requirement for PCE to know about encoding > type. I am not sure about the hardware specifics here and perhaps > someone can enlighten us. > > Cheers, > Adrian > > > _______________________________________________ > Pce mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
