Hi Marina Say that the first label in the SR-ERO is L1. Then the PCE is instructing the PCC to push a stack of labels onto each packet that uses this LSP, where the outermost label is L1. How does the PCC know which next hop to send the labelled packet to? L1 does not identify the next hop; L1 is a label taken from the SRGB of the next hop.
If we assumed that all nodes use the same SRGB, then I agree, the PCC could look up L1 in its SRGB and work out what it refers to. But we can’t assume that all nodes have the same SRGB. Label L1 might not even be in the PCC’s SRGB. Cheers Jon From: Marina Fizgeer [mailto:marina.fizg...@ecitele.com] Sent: Wednesday, August 15, 2018 4:38 PM To: Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; Dhruv Dhody <dhruv.i...@gmail.com> Cc: pce@ietf.org; Siva Sivabalan (msiva) <ms...@cisco.com>; Clarence Filsfils (cfilsfil) <cfils...@cisco.com>; Jeff Tantsura <jefftant.i...@gmail.com>; wim.henderi...@alcatel-lucent.com; Michael Gorokhovsky <michael.gorokhov...@ecitele.com>; Alexander Vainshtein <alexander.vainsht...@ecitele.com>; Alexander Ferdman <alexander.ferd...@ecitele.com>; Ron Sdayoor <ron.sday...@ecitele.com>; Dhruv Dhody <dhruv.dh...@huawei.com> Subject: RE: [Pce] PCE segment routing extension Hi, Jonathan and Dhruv Thank you for reply. Please, see in line Best regards, Marina From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com] Sent: Wednesday, August 15, 2018 6:17 PM To: Dhruv Dhody <dhruv.i...@gmail.com<mailto:dhruv.i...@gmail.com>>; Marina Fizgeer <marina.fizg...@ecitele.com<mailto:marina.fizg...@ecitele.com>> Cc: pce@ietf.org<mailto:pce@ietf.org>; Siva Sivabalan (msiva) <ms...@cisco.com<mailto:ms...@cisco.com>>; Clarence Filsfils (cfilsfil) <cfils...@cisco.com<mailto:cfils...@cisco.com>>; Jeff Tantsura <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>; wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>; Michael Gorokhovsky <michael.gorokhov...@ecitele.com<mailto:michael.gorokhov...@ecitele.com>>; Alexander Vainshtein <alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>; Alexander Ferdman <alexander.ferd...@ecitele.com<mailto:alexander.ferd...@ecitele.com>>; Ron Sdayoor <ron.sday...@ecitele.com<mailto:ron.sday...@ecitele.com>>; Dhruv Dhody <dhruv.dh...@huawei.com<mailto:dhruv.dh...@huawei.com>> Subject: RE: [Pce] PCE segment routing extension Marina, Dhruv, Please see below. Cheers Jon From: Dhruv Dhody [mailto:dhruv.i...@gmail.com] Sent: Wednesday, August 15, 2018 2:59 PM To: Marina Fizgeer <marina.fizg...@ecitele.com<mailto:marina.fizg...@ecitele.com>> Cc: pce@ietf.org<mailto:pce@ietf.org>; Siva Sivabalan (msiva) <ms...@cisco.com<mailto:ms...@cisco.com>>; Clarence Filsfils (cfilsfil) <cfils...@cisco.com<mailto:cfils...@cisco.com>>; Jeff Tantsura <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>; wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>; Jonathan Hardwick <jonathan.hardw...@metaswitch.com<mailto:jonathan.hardw...@metaswitch.com>>; Michael Gorokhovsky <michael.gorokhov...@ecitele.com<mailto:michael.gorokhov...@ecitele.com>>; Alexander Vainshtein <alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>; Alexander Ferdman <alexander.ferd...@ecitele.com<mailto:alexander.ferd...@ecitele.com>>; ron.sday...@ecitele.com<mailto:ron.sday...@ecitele.com>; Dhruv Dhody <dhruv.dh...@huawei.com<mailto:dhruv.dh...@huawei.com>> Subject: Re: [Pce] PCE segment routing extension Hi Marina, I am the document shephered [1] for this I-D. I am working with the authors in the final stages towards RFC publication. Please see inline for my response. Thanks! Dhruv [1] https://mailarchive.ietf.org/arch/msg/pce/38-FbYFEE33bTP6-yUXkKKGN8xw On Wed, Aug 15, 2018 at 5:22 PM Marina Fizgeer <marina.fizg...@ecitele.com<mailto:marina.fizg...@ecitele.com>> wrote: Dear authors of draft-ietf-pce-segment-routing-12, My colleagues and I are interested in some clarifications: 1. In section 6.2.1 “If the first SR-ERO represents an MPLS label value then the NAI field MUST NOT be absent…” In case of binding SID as first SR-ERO, it can be MPLS label only, without NAI. [Dhruv]: I am working with the authors in removing the restriction, you will find my rationale in [1]. But also note that while preparing MPLS label stack at PCE, this label stack should be from the POV of the ingress PCC. [Jon] The difficulty is knowing which label space the first SR-ERO label comes from. If it is a label from the PCC’s own SRGB then it can be used to infer the next hop. If it is a label from the first downstream router’s SRGB, then the PCC needs more information to determine the next hop. The draft currently assumes the latter. [MF: ] Actually the next hop resolution for Node (prefix) SID can be performed in PCC only, for example, ECMP or LFA use cases, where there are multiple next hops. So, PCE shall send label in SRGB range of PCC, otherwise PCC cannot resolve it even though NAI is presented 2. This draft defines the new error codes related to SR-ERO conversion, that were not defined in previous version. What is expected behavior of PCC in additional to sending error message. For example: In case PCUpd for PCE initiated LSP, PCE sends new SR-ERO objects to PCC. PCC shall validate and interpret the SR-ERO EROs. If SR-EROs cannot be converted to an MPLS label stack and a next hop, PCC shall send PCErr message with Error-Type “Reception of an invalid object”. What is expected handling of new SR-EROs in updating LSP – LSP shall stay with old SR-ERO objects or with new ones, but in down state? [Dhruv]: I agree that this should be clearly stated. Keeping the principle of make before break, staying on wil old SR path makes sense! [Jon] I agree that this clarification should be added. Thanks! Dhruv Best regards, Marina Fizgeer Email: marina.fizg...@gmail.com<mailto:marina.fizg...@gmail.com> marina.fizg...@ecitele.com<mailto:marina.fizg...@ecitele.com> ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________ _______________________________________________ Pce mailing list Pce@ietf.org<mailto:Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce