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

[Cyril Margaria <[e-mail]>]

Hi Stephane,

please see inline

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

>
>
> *From:* Pce [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.
  - if NAI->SID translation is supported, What is the procedure/error code
if a PCC cannot  resolve a NAI to a SID?

 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..


> 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.


> 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.

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)
  - 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)

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.
>
>