Hi Stephane, please see inline
On 14 November 2016 at 13:05, <[email protected]> wrote: > > > *From:* Pce [mailto:[email protected]] *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. > >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
