Re: [Pce] Comments on draft-ietf-pce-segment-routing-08

[<[e-mail]>]

Hi Cyril,

Please find some inline comments.

Brgds,

From: Pce [mailto:[e-mail]] On Behalf Of Cyril Margaria
Sent: Monday, November 14, 2016 23:40
To: [e-mail]
Subject: [Pce] Comments on draft-ietf-pce-segment-routing-08


Dear PCE'ers

I reviewed the document and I have the following comments/questions:

1)              The document implies that the PCC has to /MUST do IP address to SID conversion, I  think that it would allow a more simpler PCC if that capability is optional  and negotiated with additional error codes to indicate that the NAI SR-EROs are not supported.

[SLI] Usage of NAI in the SR-ERO is already optional today but driven by PCE. Do you mean that the PCC should drive the PCE computation result behavior ? A new object may be created for this purpose as a new path constraint. But you also may fall into situations where the PCE does not support this new constraint requested by PCC. Then, it would be good to impose one method to be supported and others to be optional, this will ensure a real interoperability between all implementations. I would also prefer to limit the options… (does mixing SID and NAI make sense ? I do not see the use case behind)



2)              One aspect of the SR-ERO processing is that,  when building the label stack, the PCC should have enough information to decide on the outgoing link (this can be provided by the PCE). It will be good if the document state could spell out this part of the procedure and indicates any specific SR-ERO procedure. For instance one solution could be  that the PCE may use IP address or Adjacency SID to indicate the outgoing link.

[SLI] Are you in the case of SID only used in ERO ? If NAI is used, outgoing if can be deduced from the first hop NAI, if NAI is not used, then it becomes not trivial and honestly I do not see how to deduce the interface (PCC cannot check its outgoing label database, as the same value may be used by multiple neighbors). NAI should be a MUST for the first hop ?

3)              Taking the outgoing link selection into account, the Maximum Stack Depth (MSD) calculation may be not trivial: for instance if the first hop is a local Adjacency-SID, then the label will not be stacked, but it will if the first hop is a Prefix SID it may be counted (non-adjacent node or adjacent node without PHP) but it may not be counted (adjacent node, with PHP). I think the draft should clarify it.

[SLI] I do not see why the first hop could be a local Adj-SID… if the ERO represents the stack to be used for the push operation, and if it starts with an Adj-SID, the Adj-SID should represent the first real forwarding operation. Going back to oif point, if NAI isn’t used, how can a PCC know that the first Adj-SID is a local SID or a neighbor’s SID ? If SID only is used and starts with an Adj-SID, the SR-ERO may be encoded using: NAI,Adj-SID,SID#1,SID#2,SID#3,…SID#n. The first hop defines only the oif.

In case the stack starts with a Node-SID, we may have:Node-SID+NAI,SID#1,SID#2,SID#3 …

Using this, we are always inline with MSD as we never send an ERO with more labels than supported.





Thanks,

Cyril







_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.