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

[<[e-mail]>]

Hi

More inline [SLI2]

From: Cyril Margaria [mailto:[e-mail]]
Sent: Wednesday, November 16, 2016 23:37
To: LITKOWSKI Stephane OBS/OINIS
Cc: [e-mail]
Subject: Re: [Pce] Comments on draft-ietf-pce-segment-routing-08

Hi Stephane,

please see inline

On 14 November 2016 at 13:05, <[e-mail]<mailto:[e-mail]>> wrote:

From: Pce [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Cyril Margaria
Sent: Monday, November 14, 2016 23:40
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 ?

I think the PCC should be able to indicate if it supports NAI->SID translation.
I see the following point missing :
  - There is no capability negotiation or specific error code to indicate that the PCC does not support S flag set to 0.
[SLI2] Yes this can be negotiated but must not prevent the session to go up if one speaker does not support it, in this case, they will just not use NAI->SID translation. But we can also think of PCE that are not capable of computing the label stack, so this may be negotiated also. And in case the two speaker does not have any match (NAI or SID), we may consider that SR extensions cannot be used.
  - if NAI->SID translation is supported, What is the procedure/error code if a PCC cannot  resolve a NAI to a SID?
[SLI2] At least we need a way to inform PCE why the path cannot get up. And as a reason PCC can give “Not possible to encode path”

 From PCE perspective this is a change in the format of the ERO, this does not influence the path computation.



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 agree, the draft should mandate one method for SR support, but the other should be negotiated..
[SLI2] Ok

I would also prefer to limit the options… (does mixing SID and NAI make sense ? I do not see the use case behind)

The ERO should (points below excluded) be consistent, mixing SID-Only and NAI-Only does not make much sense. Having both NAI and SID does make sense for troubleshooting though.

[SLI2] This should be crystal clear in the draft.

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 ?
I think NAI is a must for the first hop.

[SLI2] Ok, so this is something to add in the draft.

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 ?
 I agree, if the PCC does not support NAI->SID, the first hop MUST include a NAI for out interface selection.


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.


This works if the first hop for outgoing link selection correspond to an ADj-SID, I am not sure on the Node SID, it believe it depends if its a neigbhor and PHP flag:


Following that for SID PCC only this would give the following stacks:
  - NAI,Adj-SID,SID#1,SID#2,SID#3: stack is SID#1,SID#2,SID#3 (stack size: 3)
[SLI2] Why a size of 3, while I see 4 SIDs ?

  - Node-SID+NAI,SID#1,SID#2,SID#3:
       -  if the Node is adjacent with PHP:      SID#1,SID#2,SID#3 (stack size: 3)
       -  if the Node is adjacent without PHP: Node-SID,SID#1,SID#2,SID#3 (stack size: 4)
       -  if the Node is  not adjacent :               Node-SID,SID#1,SID#2,SID#3 (stack size: 4)
[SLI2] I do not see why PHP matters here.
If I’m connected to the node that I need to forward to, I do not need any SID, I can just forward my traffic on the link with the next labels in the stack but I do not need to care about PHP as I’m not using an ILM->NHLFE action here that’s just a push.

For PCC supporting NAI translation:
  - NAI#0+(SID#0),NAI#1+(SID#1),NAI#2+(SID#2),NAI#3(+SID#3): stack is SID#1,SID#2,SID#3 (stack size: 3)
  - NAI#0+(Node-SID#0),NAI#1+(SID#1),NAI#2+(SID#2),NAI#3(+SID#3):
       -  if the Node is adjacent with PHP:      SID#1,SID#2,SID#3 (stack size: 3)
       -  if the Node is adjacent without PHP: Node-SID#0,SID#1,SID#2,SID#3 (stack size: 4)
       -  if the Node is  not adjacent :              Node-SID#0,SID#1,SID#2,SID#3 (stack size: 4)


Thanks,
Cyril







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.


_________________________________________________________________________________________________________________________

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.