Subject: Re: [Pce] Shepherd review of draft-ietf-pce-segment-routing-12

From: Dhruv Dhody <[email-masked]>
Date: Fri, 5 Oct 2018 08:04:46 +0000

Hi Jon,

Thanks for your reply and apologies for a bit of delay (was on a business trip). See replies inline, where required. I am also include the file with minor edits for you to incorporate (see diff<https://github.com/dhruvdhody-huawei/ietf/commit/6ea3564dd6d81b4bacfefbc7955a0e417d8af6c5?diff=split>).

I will prepare the shepherd report now!

Thanks!
Dhruv

Dhruv Dhody
Lead Architect
Network Business Line
Huawei Technologies India Pvt. Ltd.
Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield
Bengaluru, Karnataka - 560066
Tel: + 91-80-49160700 Ext 71583 II Email: [email-masked]<mailto:[email-masked]>
[Huawei-small]
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

From: Jonathan Hardwick [mailto:[email-masked]]
Sent: 24 September 2018 22:03
To: Dhruv Dhody <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; Dhruv Dhody <[email-masked]>
Subject: RE: Shepherd review of draft-ietf-pce-segment-routing-12

Hi Dhruv

Many thanks again for your review and for your patience as I worked through the points you've raised.  Please find my replies below, and the current WIP attached.  I'll resubmit once we've converged on the open issues below.

Kind regards
Jon

From: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, 9 August, 2018 12:36 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
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.

[Jon] As discussed, we can back out these details.  I think it is sufficient to refer the reader to section 4 of draft-ietf-spring-segment-routing-policy.  I replaced 6.2.2 with the following, briefer text.

NEW
6.2.2.  Interpreting the SR-ERO
   The SR-ERO contains a sequence of subobjects.  According to
   [I-D.ietf-spring-segment-routing-policy], each SR-ERO subobject in
   the sequence identifies a segment that the traffic will be directed
   to, in the order given.  That is, the first subobject identifies the
   first segment the traffic will be directed to, the second SR-ERO
   subobject represents the second segment, and so on.

   The PCC interprets the SR-ERO by converting it to an MPLS label stack
   plus a next hop.  The PCC sends packets along the segment routed path
   by prepending the MPLS label stack onto the packets and sending the
   resulting, modified packet to the next hop.

   The PCC uses a different procedure to do this conversion, depending
   on the information that the PCE has provided in the subobjects.

   o  If the subobjects contain SID index values, then the PCC converts
      them into the corresponding MPLS labels by following the procedure
      defined in [I-D.ietf-spring-segment-routing-mpls].

   o  If the subobjects contain NAI only, then the PCC first converts
      each NAI into a SID index value by looking it up in its local
      database, and then proceeds as above.

   o  If the subobjects contain MPLS labels, then the PCC looks up the
      offset of the first subobject's label in its SRGB or SRLB.
      This gives the first SID.  The PCC pushes the labels in any
      remaining subobjects onto the packet (with the final subobject
      specifying the bottom-of-stack label) and then directs the packet
      to the segment identified by the first SID.
END NEW
[[Dhruv Dhody]] This is good.

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

[Jon] Dhruv, I've thought about this some more since we discussed it face to face, and I am not sure that this field ever did specify the type of the SID (despite its original name).  For instance, there are three values representing an adjacency: if the SID is provided and the NAI is not provided, which value do I use?  But there is no value defined for a (general) prefix SID or for a binding SID.  This field defines the format of the NAI, if present.  If the NAI is absent then the information this field gives about the SID is, at best, open to interpretation.  This was the reason for renaming the field - to make it clear what an implementation can actually deduce from it.
[[Dhruv Dhody]] I can live with this. One can always find the type of SID by searching in local database.

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

[Jon] I have added the following text to the introduction:

NEW
   This specification provides a mechanism for a network controller
   (acting as a PCE) to instantiate candidate paths for an SR Policy
   onto a head-end node (acting as a PCC) using PCEP.  For more
   information on the SR Policiy Architecture, see
   [I-D.ietf-spring-segment-routing-policy].
END NEW
[[Dhruv Dhody]] This works, thanks!

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

[Jon] I've added the following paragraph to cover your point about RSVP-TE.  But what do you think we should say about MSD?

NEW
   Note that this specification enables a network controller to
   instantiate a path in the network without the use of a hop-by-hop
   signaling protocol (such as RSVP-TE).  This creates an additional
   vulnerability if the security mechanisms of [RFC5440] and [RFC8281]
   are not used, because an attacker could create a path which is not
   subjected to the further verification checks that would be performed
   by the signaling protocol.
END NEW
[[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.

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?

[Jon] Changed to SR-DB.

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

[Jon] Now that I have rewritten 6.2.2, I think we can simplify the above as follows.

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!

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.
[Jon] Agreed.

- In Section 6.2.2.1, we should update the procedure and the next-hop is not identified from the NAI
[Jon] Done.

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.
[Jon] I think it's already covered in the SR-policy draft.  I don't think it's needed in the base SR-MPLS draft.
[[Dhruv Dhody]] Ok.

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.
[Jon] I think that's handled by my new 6.2.2 text, above.

(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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|   Type=36   |     Length    |  NT   |     Flags     |F|S|C|M|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         SID (optional)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                   NAI (variable, optional)                  //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I think it is wrong to consider the first 32-bit as a header as per RFC 3209 specification.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
   |L|    Type     |     Length    | (Subobject contents)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+

[Jon] Agreed, have reworded.

(3) Section 6.1, the N flag indicates the capability to get SID from NAI, so it should be applicable when only NAI is sent.
OLD:
   If a PCC sets the N flag to 1, then the PCE MAY send NAI to the PCC
   within the SR-ERO subobject (see Section 6.2).  Otherwise, the PCE
   MUST NOT send NAI to the PCC.
NEW:
   If a PCC sets the N flag to 1, then the PCE MAY send NAI only to the PCC
   within the SR-ERO subobject (see Section 6.2).  Otherwise, the PCE
   MUST NOT send NAI only to the PCC.

[Jon] Agreed. Changed your wording slightly:
NEWER
   If a PCC sets the N flag to 1, then the PCE MAY send an SR-ERO
   subobject containing NAI and no SID (see Section 6.2).  Otherwise,
   the PCE MUST NOT send an SR-ERO subobject containing NAI and no SID.
END NEWER
[[Dhruv Dhody]] This is good.

(4) Section 6.2.1, it says -
   If a PCC receives an SR-ERO subobject in which the S bit is set to
   zero and the M bit is set to 1 (that is, it represents an MPLS label
   value), its value (20 most significant bits) MUST be larger than 15,
   unless it is a special purpose label, such as an Entropy Label
   Indicator (ELI).

Since all labels < 15 are special-purpose label, the above sentence isn't correct. Do you mean ELI is the only special purpose label that is allowed? Or we should simply say the label should be valid from PCC's point of view without worrying about special-purpose label.

[Jon] I'm not sure where that text came from - it effectively says "labels must not be special-purpose labels, unless they are special purpose labels"! It makes no sense to accept an Implicit-NULL, but I can imagine there might be use cases for most, if not all, of the other special purpose labels.  The PCC should take the ultimate decision.  I have changed the text as follows.

NEW
   If a PCC receives an SR-ERO subobject in which the S bit is set to
   zero and the M bit is set to 1, then the subobject contains an MPLS
   label.  The PCC MAY choose not to accept a label provided by the PCE,
   based on it local policy.  The PCC MUST NOT accept MPLS label value 3
   (Implicit NULL), but it MAY accept other special purpose MPLS label
   values.  If the PCC decides not to accept an MPLS label value, it
   MUST send a PCErr message with Error-Type = 10 ("Reception of an
   invalid object") and Error Value = 2 ("Bad label value").
END NEW
[[Dhruv Dhody]] Agreed.

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.

(2) In section 5.1, can we describe the value part of the sub-TLV in the order, currently we have MSD, Reserved and then flags.
Also, we should state if future extension can define new flags (and create a corresponding IANA registry) and unassigned bits in the flags MUST be set to 0.
Since MSD value 0 as a special purpose, we should mention that and provide reference to section 5.5

[Jon] OK

(3) In section 5.3.1 (M bit in Flag field), we should reference SR I-D while describing the interpretation of index.
OLD:
      *  M: If this bit is set to 1, the SID value represents an MPLS
         label stack entry as specified in [RFC3032].  Otherwise, the
         SID value is an administratively configured value which acts as
         an index into an MPLS label space.
NEW:
      *  M: If this bit is set to 1, the SID value represents an MPLS
         label stack entry as specified in [RFC3032].  Otherwise, the
         SID value is an administratively configured value which represents
         an index into an MPLS label space (either SRGB or SRLB) as per
         [RFC8402].

[Jon] OK

(4) In section 5.3.1, can we add a little more description for SID.
OLD:
SID  is the Segment Identifier.
NEW:
SID is the Segment Identifier. According to the M bit, it contains
either:

  * A 4 octet index defining the offset into an MPLS label space as
    per [RFC8402].
  * A 4 octet MPLS label stack entry where the 20 rightmost bits are
    used for encoding the label value as per [RFC3032].

[Jon] OK

(5) In section 5.3.2, It would be nice to explicitly mention the length of the NAI field in each case.
[Jon] OK

(6) Section 5.4, we should add little bit more meat to this section to clearly state what does RRO represents in case of SR-TE LSP. Currently we simply say that -

   A PCC can record an SR-TE LSP and report the LSP to a PCE via the
   RRO.

PCC reports the state of LSP to the PCE. RRO represents the actual path in the PCRpt message, thus the RRO for SR-TE represents the SID list applied by the PCC. This could be represented as MPLS label stack or as the list of indexes. In some cases, the ERO (intended path) and RRO (actual path) might be different based on local policy applied by the PCC. We should state that procedures as per [RFC8231] with no change.

[Jon] OK, I have updated the text as follows.

NEW
   A PCC reports an SR-TE LSP to a PCE by sending a PCRpt message, per
   [RFC8231].  The RRO on this message represents the SID list that was
   applied by the PCC, that is, the actual path taken by the LSP.  The
   procedures of [RFC8231] with respect to the RRO apply equally to this
   specification without change.
END NEW

I have also made the following change to bring the RRO in line with the agreement for the ERO, above.  *Do you agree with this change?*

OLD
   A PCC MUST assume that the SR-RRO subobjects are organized such that
   the first subobject relative to the beginning of the RRO contains the
   information about the topmost label, and the last subobject contains
   information about the bottommost label of the SR-TE LSP.
NEW
   A PCC MUST order the SR-RRO subobjects such that the first subobject
   relative to the beginning of the RRO identifies the first segment
   visited by the SR-TE LSP, and the last subobject identifies the final
   segment of the SR-TE LSP, that is, its endpoint.
END
[[Dhruv Dhody]] This is fine!

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.

(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 purpose, as follows:

   o  T = 11: Maximum SID Depth of the requested path.

   If the PCC includes a METRIC object of this type on a path
   computation request, then the PCE MUST minimize the SID depth of the
   computed path.  If the B (bound) bit is set to to 1 in the METRIC
   object, then the PCE MUST NOT return a path whose SID depth exceeds
   the given metric-value.  If the PCC did not set the L bit in its SR-
   PCE-CAPABILITY TLV, then it MUST set the B bit to 1.  If the PCC set
   the L bit in its SR-PCE-CAPABILITY TLV, then it MAY set the B bit to
   zero, which indicates that the PCE should minimize the SID depth
   without imposing an absolute maximum value.
END NEW
[[Dhruv Dhody]] This is good. But I am not sure about the relationship between L bit (in TLV) and B bit (in METRIC). Though a PCC did not impose any limit on MSD, it could still ask for a smaller SID stack (optimization)?

(8) Section 6.2.1, it says -

   If a PCC receives an SR-ERO subobject in which the S bit is set to
   zero and the M bit is set to zero (that is, it represents an index
   value), then the SID MUST be a node-SID, an adjacency-SID or a
   binding-SID.  If the SID is not one of these types, the PCC MUST send
   a PCErr message with Error-Type = 10 ("Reception of an invalid
   object") and Error Value = TBD10 ("Bad SID type in SR-ERO").  If the
   SID is an Adjacency-SID then the L flag MUST NOT be set.  If the L
   flag is set for an Adjacency-SID then the PCC MUST send a PCErr
   message with Error-Type = 10 ("Reception of an invalid object") and
   Error-Value = 11 ("Malformed object").

Shouldn't we just say that PCC should support the SID type and leave the door open for any other SID type use for ex anycast SID or any other future SID type?

[Jon] What I was really thinking here was that it would be invalid to have a prefix-SID in the list (unless it's a node SID).  I've reworded as follows:

NEW
   If a PCC receives an SR-ERO subobject in which the S bit is set to
   zero and the M bit is set to zero, then the subobject contains a SID
   index value.  If the SID is a prefix-SID but not a node-SID, then the
   PCC MUST send a PCErr message with Error-Type = 10 ("Reception of an
   invalid object") and Error Value = TBD9 ("Bad SID type in SR-ERO").
   If the SID is an Adjacency-SID then the L flag MUST NOT be set.  If
   the L flag is set for an Adjacency-SID then the PCC MUST send a PCErr
   message with Error-Type = 10 ("Reception of an invalid object") and
   Error-Value = 11 ("Malformed object").
END NEW
[[Dhruv Dhody]] This is better but I feel we should not include the prefix SID check. There are use-cases to include prefix SID as the bottom SID (Refer SR policy draft)!

(8) Section 6.2.2.4, this error is not clear -

   o  If the PCC cannot find an SRGB in the LSDB, it MUST send a PCErr
      message with Error-Type = 10 ("Reception of an invalid object")
      and Error-Value = TBD5 ("Could not find SRGB").

Does it mean that a particular node does not support SR or did not advertise SRGB and thus PCC is unaware of the SRGB information of that node?

[Jon] If the PCE has provided the PCC with a list of SID index values, then the PCC needs to use the SRGBs of the nodes on the path to convert the SIDs into labels.  If the PCC cannot find a given node's SRGB in its local SR-DB (e.g. someone forgot to turn on SR on that node) then it sends this error.  Have updated text to:

NEW
   o  If the PCC needs to convert a SID into an MPLS label value but
      cannot find the corresponding router's SRGB in the SR-DB, it MUST
      send a PCErr message with Error-Type = 10 ("Reception of an
      invalid object") and Error-Value = TBD5 ("Could not find SRGB").
END NEW

Similar for SRLB.

Nits:
*****

(1) https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-12.txt - all easy to fix with a new update!
(2) s/ PATH_SETUP_TYPE/PATH-SETUP-TYPE/
(3) s/PATH_SETUP_TYPE_CAPABILITY/PATH-SETUP-TYPE-CAPABILITY/
(4) We have used the term octet mostly except for 2 instances of bytes. Suggest to use the same term.
(5) Section 8.1
OLD:
   o  When a PCC requests a path for an LSP, it can nominate a preferred
      path setup type by including it in the PATH-SETUP-TYPE TLV in the
      RP object of the PCInitiate message.
NEW:
   o  When a PCC requests a path for an LSP, it can nominate a preferred
      path setup type by including it in the PATH-SETUP-TYPE TLV in the
      RP object of the PCReq message.
(6) Section 8.3, for the first 2 bullets only L flag is mentioned. I think we should also include the N flag.

[Jon] OK to all the above.

(7) The heading for section 10.1 is PCEP objects where as its content is about SE-ERO and SR-RRO sub-objects in RSVP registry!

[Jon] Have changed the title to "PCEP ERO and RRO subobjects".

Thanks again!

Looking forward to resolving the above points and moving the document quickly.

Regards,
Dhruv

Dhruv Dhody
Lead Architect
Network Business Line
Huawei Technologies India Pvt. Ltd.
Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield
Bengaluru, Karnataka - 560066
Tel: + 91-80-49160700 Ext 71583 II Email: [email-masked]<mailto:[email-masked]>
[Huawei-small]
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

---

From: Jonathan Hardwick <[email-masked]>
Date: Fri, 12 Oct 2018 16:23:58 +0000

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 –

[Jon2] Thanks for the text – I have added something similar.

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:
**************

[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].”

[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!

NEW

[Jon2] I have changed it to make it clearer, hopefully:

OLD
   If the PCC set
   If the PCC set
  1 or zero.
END

Shouldn’t we just say that PCC should support the SID type and leave the door open for any other SID type use for ex anycast SID or any other future SID type?

[Jon] What I was really thinking here was that it would be invalid to have a prefix-SID in the list (unless it’s a node SID).  I’ve reworded as follows:

NEW

[Jon2] OK – I have retired the following text (and error code TBD9):
“If the SID is a prefix-SID but not a node-SID, then the
   PCC MUST send a PCErr message with Error-Type = 10 ("Reception of an
   invalid object") and Error Value = TBD9 ("Bad SID type in SR-ERO").
“