Re: [Pce] Shepherd review of draft-ietf-pce-segment-routing-12
Hi Dhruv Thanks – I’ve applied these markups. See comments below (trimming all closed issues). I’ll post a new revision forthwith. Cheers Jon [[Dhruv Dhody]] Thanks, regarding MSD something like – The MSD (in OPEN message) discloses capabilities of the PCC (how many SIDs it supports), which could provide an indication of the abilities of the PCC. This information could be used to gain intelligence about devices in the network. [Jon2] Thanks for the text – I have added something similar. NEWER o An ordered set of IP addresses representing network nodes/links. o An ordered set of SID index values, with or without the corresponding IP addresses. o An ordered set of MPLS labels, with or without corresponding IP address. The PCC converts these into an MPLS label stack and next hop, as described in section 6.2.2. END NEWER [[Dhruv Dhody]] In the WIP you sent you have - “An ordered set of MPLS labels and IP addresses”. Let’s update it to what you have above! [Jon2] Oops! Fixed it. Suggestions: ** (1) In section 3, it says - An PCE can update an LSP that is initially established via RSVP-TE signaling to use an SR-TE path, by sending a PCUpd to the PCC that delegated the LSP to it ([RFC8231]). Similarly, an LSP initially created with an SR-TE path can be updated to use RSVP-TE signaling, if necessary. This capability is useful when a network is migrated from RSVP-TE to SR-TE technology. We should also add text for LSPs that are not delegated and in control with PCC, where PCC will trigger the migration and this should be reported to the PCE via the PCRpt message. [Jon] Not sure I understand… Are you saying that the PCC delegates the LSP and, at the same time, requests the PCC to migrate the LSP? What should the PCC set on the PCRpt to request a migration? I’m not sure if it makes sense, I would expect migrations to be driven from the controller downwards, not individually requested by the head-ends. [[Dhruv Dhody]] Consider a LSP that was not delegated and control is at the PCC. Via configuration the PCC is asked to migrate this to SR, the PCC could via PCReq/PCRep gets a new path based on SR and installs it in the forwarding and migrate to it. We would want a make-before-break like operations where via PCRpt message(s) the new LSP (with PST=SR) is reported and the old LSP is reported to be deleted. Thus IMHO the migration could be triggered at the PCC via configuration too. In section 8.2 we state that this is out of scope, but in section 3 it was mentioned only in scope of PCUpd message, thus making me wonder if we should also include the PCC triggered migration of LSP. [Jon2] OK – got it. I have added “A PCC can update an undelegated LSP that is initially established via RSVP-TE signaling to use an SR-TE path as follows. First, it requests an SR-TE Path from a PCE by sending a PCReq message. If it receives a suitable path, it establishes the path in the data plane, and then tears down the original RSVP-TE path. If the PCE is stateful, then the PCC sends PCRpt messages indicating that the new path is set up and the old path is torn down, per [RFC8231].” Another query NAI only SR-RRO is of no use. I think we should not allow that!! [Jon] I think it could make sense e.g. as a list of router IDs that the LSP visits. Personally, I think NAI-only overcomplicates the protocol in both ERO and RRO, but given that we allow it in ERO, I don’t see a reason to ban it from RRO. [[Dhruv Dhody]] My point of view was that when NAI-only ERO is sent by the PCE, the PCC needs to convert that into a viable SID-list based on its database. It would make sense for the PCC to report this to the PCE in form of SR-RRO. Thus it must contain the SID-index or label. Just returning the NAI-only to the PCE may not be that useful. The PCC always needs SID to install in the data plane and it is useful to report that to the PCE, thus I still feel we should not allow NAI-only in SR-RRO! But I can live with it if you do not wish to make this change. [Jon2] I worry the change is destabilizing because it begs further (sensible) questions like “do any fielded implementations do it?”, “is there any purpose to having NAI in the RRO at all?” or “should we define a new format for SR-RRO without the F and S bits?” Nobody has objected to the RRO format up to this point. So I’m going to leave it in there for now unless I get more pushback from the RTGDIR / ADs! (7) Section 5.5, is METRIC object without bound allowed? I.e. a path computation request to optimize MSD valid? [Jon] Agree this would make sense if the PCC does not impose an MSD. Changed the text to: NEW A PCC MAY request that PCE optimizes an individual path computation request to minimize the SID depth of the computed path by using the METRIC object defined in [RFC5440]. This document defines a new type for the METRIC object to be used for this purpos
Re: [Pce] Shepherd review of draft-ietf-pce-segment-routing-12
Thanks for the review, Dhruv! I'll think about your comments and get back to you SOON (possibly not until after my vacation next week). Cheers Jon From: Dhruv Dhody [mailto:dhruv.dh...@huawei.com] Sent: Thursday, August 9, 2018 12:36 PM To: pce@ietf.org Cc: pce-cha...@ietf.org; draft-ietf-pce-segment-routing@ietf.org; Dhruv Dhody Subject: Shepherd review of draft-ietf-pce-segment-routing-12 Hi, I am assigned the shepherded for this document. I have previously given my input and liked the direction of the update with the -12 version, but also found some new issues. Disclaimer - I discussed some of the points with the authors F2F during the IETF meeting as well. Major: *** (1) Though I appreciated the details in the new section 6.2.2. I feel the right place for this should be in 'draft-ietf-spring-segment-routing-mpls' because the source of the SID stack could be PCEP, BGP or Yang. The text related to the interpretation of the SID stack rightly belong in that draft and in this I-D should just refer it (and specify the PCEP specific error handling and procedures only). I hope the chairs and AD of the WG could conclude on that. We could initiate a separate thread to discuss this point with spring chairs/AD. (2) The change of the field ST (SID type) to NT (NAI type) was done in the last update. This change was done in the -12 version with the expectation that this is just a name change and would have no other impact. But since NAI is optional and might not be included, and in that case one would not be able to interpret what the SID represents when NAI is not provided. Though, it might be possible to find that information via searching the local database, there is no apparent benefit in making this change and limiting the knowledge of the SID type only when NAI is included. Changes would be needed in various places including Section 6.2.1. (3) There is no mention of the SR policy in the draft. This is a source of confusion, so a reference and relationship between them should be added in the Introduction. (4) I think we should enhance the security consideration section 9 a little bit more. Since a label stack can be pushed directly for the PCE, this would have a bigger security impact then a path that gets further signaled by RSVP-TE and verified in control plane. We should talk about MSD information as well. Minor: *** (1) I am not comfortable with the use of term LSDB, you would note no other SR documents uses it either. SR architecture also allow future innovation in control plane especially in the centralized mode. May be we should use the term SR-DB introduced by the policy draft? Or a generic term such as local database? (2) In section 3, it describes the 3 representations for SR-ERO, I have following suggestion - OLD: o An ordered set of IP addresses representing network nodes/links: In this case, the PCC needs to convert the IP addresses into the corresponding MPLS labels by consulting its Link State Database (LSDB). o An ordered set of SIDs, with or without the corresponding IP addresses. o An ordered set of MPLS labels and IP addresses: In this case, the PCC needs to convert the IP addresses into the corresponding SIDs by consulting its LSDB. NEW: o An ordered set of IP addresses representing network nodes/links. In this case, the PCC needs to convert the IP addresses into the corresponding MPLS labels by consulting its Link State Database (LSDB). o An ordered set of SID index values, with or without the corresponding IP addresses. The PCC needs to convert the index into the corresponding MPLS label stack as per [I-D.ietf-spring-segment-routing-mpls]. o An ordered set of MPLS labels, with or without corresponding IP address. The top label in the label stack received from the PCE is from the point of view of the ingress PCC and it must follow the procedures as described in [I-D.ietf-spring-segment-routing-mpls] while pushing the label stack. The idea behind this is to specify that PCE should prepare the label stack with the top label from the point of view of Ingress and label stack might change. The change could be an outgoing label change as per the SRGB of neighbor towards which the packet is sent; or it could be an adjacency label pop identifying the out-interface. - In section 6.2.1, we should remove this condition requiring NAI MUST be present for the first SR-ERO sub-object and corresponding error-code. - In Section 6.2.2.1, we should update the procedure and the next-hop is not identified from the NAI Regarding the text in section 6.2.2, once the agreement is met to move the text to the SR-MPLS document, the text needs to be modified accordingly from the point of view of a generic MPLS Control Plane Client (MCC). And we should simply refer to it saying PCC is one such client. Note that 'only NAI' in SR-ERO would
[Pce] Shepherd review of draft-ietf-pce-segment-routing-12
Hi, I am assigned the shepherded for this document. I have previously given my input and liked the direction of the update with the -12 version, but also found some new issues. Disclaimer - I discussed some of the points with the authors F2F during the IETF meeting as well. Major: *** (1) Though I appreciated the details in the new section 6.2.2. I feel the right place for this should be in 'draft-ietf-spring-segment-routing-mpls' because the source of the SID stack could be PCEP, BGP or Yang. The text related to the interpretation of the SID stack rightly belong in that draft and in this I-D should just refer it (and specify the PCEP specific error handling and procedures only). I hope the chairs and AD of the WG could conclude on that. We could initiate a separate thread to discuss this point with spring chairs/AD. (2) The change of the field ST (SID type) to NT (NAI type) was done in the last update. This change was done in the -12 version with the expectation that this is just a name change and would have no other impact. But since NAI is optional and might not be included, and in that case one would not be able to interpret what the SID represents when NAI is not provided. Though, it might be possible to find that information via searching the local database, there is no apparent benefit in making this change and limiting the knowledge of the SID type only when NAI is included. Changes would be needed in various places including Section 6.2.1. (3) There is no mention of the SR policy in the draft. This is a source of confusion, so a reference and relationship between them should be added in the Introduction. (4) I think we should enhance the security consideration section 9 a little bit more. Since a label stack can be pushed directly for the PCE, this would have a bigger security impact then a path that gets further signaled by RSVP-TE and verified in control plane. We should talk about MSD information as well. Minor: *** (1) I am not comfortable with the use of term LSDB, you would note no other SR documents uses it either. SR architecture also allow future innovation in control plane especially in the centralized mode. May be we should use the term SR-DB introduced by the policy draft? Or a generic term such as local database? (2) In section 3, it describes the 3 representations for SR-ERO, I have following suggestion - OLD: o An ordered set of IP addresses representing network nodes/links: In this case, the PCC needs to convert the IP addresses into the corresponding MPLS labels by consulting its Link State Database (LSDB). o An ordered set of SIDs, with or without the corresponding IP addresses. o An ordered set of MPLS labels and IP addresses: In this case, the PCC needs to convert the IP addresses into the corresponding SIDs by consulting its LSDB. NEW: o An ordered set of IP addresses representing network nodes/links. In this case, the PCC needs to convert the IP addresses into the corresponding MPLS labels by consulting its Link State Database (LSDB). o An ordered set of SID index values, with or without the corresponding IP addresses. The PCC needs to convert the index into the corresponding MPLS label stack as per [I-D.ietf-spring-segment-routing-mpls]. o An ordered set of MPLS labels, with or without corresponding IP address. The top label in the label stack received from the PCE is from the point of view of the ingress PCC and it must follow the procedures as described in [I-D.ietf-spring-segment-routing-mpls] while pushing the label stack. The idea behind this is to specify that PCE should prepare the label stack with the top label from the point of view of Ingress and label stack might change. The change could be an outgoing label change as per the SRGB of neighbor towards which the packet is sent; or it could be an adjacency label pop identifying the out-interface. - In section 6.2.1, we should remove this condition requiring NAI MUST be present for the first SR-ERO sub-object and corresponding error-code. - In Section 6.2.2.1, we should update the procedure and the next-hop is not identified from the NAI Regarding the text in section 6.2.2, once the agreement is met to move the text to the SR-MPLS document, the text needs to be modified accordingly from the point of view of a generic MPLS Control Plane Client (MCC). And we should simply refer to it saying PCC is one such client. Note that 'only NAI' in SR-ERO would be a unique feature for PCEP and thus section 6.2.2.3 would still be needed. (2) In section 5.3.1, it says - An SR-ERO subobject consists of a 32-bit header followed by the SID and/or the NAI associated with the SID. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
