Subject: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

From: Dhruv Dhody <[email-masked]>
Date: Fri, 4 Feb 2022 22:44:15 +0530

Hi WG,

This email begins the WG adoption poll for draft-tokar-pce-sid-algo-05.

https://datatracker.ietf.org/doc/draft-tokar-pce-sid-algo/

Should this draft be adopted by the PCE WG? Please state your reasons - Why
/ Why not? What needs to be fixed before or after adoption? Are you willing
to work on this draft? Review comments should be posted to the list.

Please respond by Monday 21st Feb 2022.

Have a great weekend.

Thanks!
Dhruv & Julien

---

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 7 Feb 2022 14:41:41 +0000

Hi PCE WG,

Support adoption. Seems reasonable to convey flex algo related constraint and status between PCE and PCC, and the document is written quite clear.

One general potential question/concern is the SR-ERO encoding of A-bit/Algorithm value, since it describes it comes after other optional fields. Assuming one day other documents continue to specify optional fields as well (backed by the flags), do we run the risk of potential mis-ordering of values between implementations? or is the expectation for all values to be in the same sequence of the flag definition? Seems like it’s reinventing tlv without the tlv overhead, but since the original SR-ERO object is already variable values, it does fit, and at this moment I have no other alternative suggestion...

Thanks
Andrew

From: Pce <[email-masked]> on behalf of Dhruv Dhody <[email-masked]>
Date: Friday, February 4, 2022 at 12:15 PM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi WG,

Should this draft be adopted by the PCE WG? Please state your reasons - Why / Why not? What needs to be fixed before or after adoption? Are you willing to work on this draft? Review comments should be posted to the list.

Have a great weekend.

Thanks!
Dhruv & Julien

---

From: Ketan Talaulikar <[email-masked]>
Date: Tue, 8 Feb 2022 23:08:29 +0530

Hi All,

I support the adoption of this document and have the following comments
(not blocking adoption) for the consideration of the authors & the WG.

1) While the algorithm was originally introduced for Prefix-SID in RFC8402,
it has since been also extended to cover Adjacency SID. I hope the text in
the draft can reflect that better. Also, some reference to IGP flex-algo
would be helpful since that is perhaps one of the key drivers for this work.

2) I would suggest using the "A" flag in the capabilities for Algorithm
than the currently used "S".

3) For the ERO encoding, we seem to be getting into problematic territory
as also indicated by Andrew. I would suggest that the ordering of optional
fields strictly follow the order in which flags are being introduced (i.e.
their bit position). This way, we at least don't get into random scenarios.
I am not sure if the ordering in the ASCII art is considered normative. In
the future, it would be best if we follow pure TLV/sub-TLV based encoding
at all times - i.e. always introduce capabilities for sub-TLVs even though
there might be none foreseen at the time of defining a new TLV.

4) For the LSPA Object, I presume the L (loose) flag is actually indicating
a "non-strict" adherence to the algo constraint. Somehow the "loose" term
may give a different impression. There is the preference for an algo and
then a strict requirement for an algo to be followed (e.g. for flex-algo).
Also, some clarity on the use of Adj-SIDs that don't have an associated
algo with them would be helpful.

Thanks,
Ketan

On Fri, Feb 4, 2022 at 10:45 PM Dhruv Dhody <[email-masked]> wrote:

> Should this draft be adopted by the PCE WG? Please state your reasons -
> Why / Why not? What needs to be fixed before or after adoption? Are you
> willing to work on this draft? Review comments should be posted to the list.
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>

---

From: "Samuel Sidor (ssidor)" <[email-masked]>
Date: Wed, 9 Feb 2022 08:22:41 +0000

Hi Ketan, Andrew,

Thanks a lot, for your comments.

  1.  There is already plan to add support for Adjacency SIDs. The draft will be extended (hopefully before IETF113 draft submission cut-off)
  2.  I will check that
  3.  (This is related to questions from Andrew) - Yes, this is coming from original definition of SR-ERO subobjects without having support for TLVs, so its extensibility is problematic. I like your suggestion about ordering of optional fields strictly following their bit positions.
  4.  “Loose” name is result of one of previous versions of this draft, where we had 2 different flags – “Fallback” and “Loose”, so names were chosen to point to difference between them. Then based on comments one of them was dropped, so now are free to modify that name if needed (feel free to suggest any alternative). I can add some section describing details for Adj SID handling.

Regards,
Samuel

From: Pce <[email-masked]> On Behalf Of Ketan Talaulikar
Sent: Tuesday, February 8, 2022 6:38 PM
To: Dhruv Dhody <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi All,

I support the adoption of this document and have the following comments (not blocking adoption) for the consideration of the authors & the WG.

1) While the algorithm was originally introduced for Prefix-SID in RFC8402, it has since been also extended to cover Adjacency SID. I hope the text in the draft can reflect that better. Also, some reference to IGP flex-algo would be helpful since that is perhaps one of the key drivers for this work.

2) I would suggest using the "A" flag in the capabilities for Algorithm than the currently used "S".

3) For the ERO encoding, we seem to be getting into problematic territory as also indicated by Andrew. I would suggest that the ordering of optional fields strictly follow the order in which flags are being introduced (i.e. their bit position). This way, we at least don't get into random scenarios. I am not sure if the ordering in the ASCII art is considered normative. In the future, it would be best if we follow pure TLV/sub-TLV based encoding at all times - i.e. always introduce capabilities for sub-TLVs even though there might be none foreseen at the time of defining a new TLV.

4) For the LSPA Object, I presume the L (loose) flag is actually indicating a "non-strict" adherence to the algo constraint. Somehow the "loose" term may give a different impression. There is the preference for an algo and then a strict requirement for an algo to be followed (e.g. for flex-algo). Also, some clarity on the use of Adj-SIDs that don't have an associated algo with them would be helpful.

Thanks,
Ketan

On Fri, Feb 4, 2022 at 10:45 PM Dhruv Dhody <[email-masked]<mailto:[email-masked]>> wrote:
Hi WG,

Have a great weekend.

Thanks!
Dhruv & Julien
_______________________________________________
Pce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce

---

From: "Mike Koldychev (mkoldych)" <[email-masked]>
Date: Wed, 9 Feb 2022 14:34:22 +0000

Support adoption. This document is necessary to implement flex-algo with PCE.

Thanks,
Mike.

From: Pce <[email-masked]> On Behalf Of Dhruv Dhody
Sent: Friday, February 4, 2022 12:14 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi WG,

Have a great weekend.

Thanks!
Dhruv & Julien

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 18 Feb 2022 09:37:50 +0530

Hi WG,

A reminder to please respond to the WG adoption poll by Monday!

Please be more vocal. The silence makes it difficult to judge consensus.

Also, the IPR responses from Alex, Shuping, and Mahendra are missing still.

Thanks!
Dhruv & Julien

---

From: Mahendra Negi <[email-masked]>
Date: Fri, 18 Feb 2022 10:17:38 +0530

Hi All,

I support the adoption, this is a necessary document to extend
flex-algorithm support in PCEP.

Regards,

Mahendra

---

From: <[email-masked]>
Date: Fri, 18 Feb 2022 14:49:18 +0800 (CST)

Hi Chairs, WG,

Support as a co-author.
After enabling flexible algorithm in IGP domain, the SID stack depth  can be significantly reduced, which makes SR-TE path across multiple domains benefit by including algorithm related SIDs, with shorter SID list and higher packet encapsulation efficiency. The mechanism proposed in this document enables the controller to install the SR-TE path related to the algorithm to the network node.

Regards,
PSF

------------------原始邮件------------------
发件人：DhruvDhody
收件人：[email-masked];
抄送人：[email-masked];Mahendra Negi;
日 期 ：2022年02月18日 12:08
主 题 ：Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05
_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

Hi WG,

Thanks!
Dhruv & Julien

Have a great weekend.

Thanks!
Dhruv & Julien

---

From: <[email-masked]>
Date: Fri, 18 Feb 2022 08:30:04 +0000

Hello all,

I support also the adoption of this draft.

Regards

Olivier

Le 18/02/2022 à 05:07, Dhruv Dhody a écrit :
Hi WG,

Thanks!
Dhruv & Julien

On Fri, Feb 4, 2022 at 10:44 PM Dhruv Dhody <[email-masked]<mailto:[email-masked]>> wrote:
Hi WG,

Have a great weekend.

Thanks!
Dhruv & Julien

--
[Orange logo] <http://www.orange.com>

Olivier Dugeon
Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/iTeQ

fixe : +33 2 96 07 28 80
mobile : +33 6 82 90 37 85
[email-masked]<mailto:[email-masked]>

_________________________________________________________________________________________________________________________

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.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 18 Feb 2022 09:08:45 +0000

Hi WG, chairs,

I just read the latest version of this document. In general incorporating Algorithm into PCEP could be useful. While I have the below questions on this version and it would be helpful if they can be resolved before adoption.

1.       This document introduces the algorithm constraint in the LSPA object, which means the algorithm needs to be considered in the computation of the path. IMO this is important for computing a loop-free path. While the draft also says that the “the PCE MAY insert prefix SIDs with a different Algorithm in order to successfully compute a path.” Mixing SIDs with different algorithms in a path has the risk of loops. It is suggested that the document provides some analysis about such risk, and the example of scenarios where mixing SIDs with different algorithms is safe and desired.

2.       This is related to the first question. If the analysis shows that using SIDs with different algorithms in a path is not a good idea, then it would be unnecessary to carry the algorithm ID in SERO subobjects, instead carrying it as a path attribute would be enough.

3.       Assuming the answer to question 2 is YES, the SR-ERO and SRv6-ERO subobjects were defined with a fixed format (do not support sub-TLVs), this document introduces an additional optional field to those sub-objects, and use a new flag to indicate the existence of the new optional field. To my understanding this is not a usual approach for protocol extension. Usually a new Type needs to be defined for a new format. It would be necessary to understand the implication of using flags to indicate the modification to the format of an existing object.

4.       The term “SID Algorithm” in this document is different from that is used in the RFCs of SR/SRv6 IGP/BGP extensions, where it is called “SR-Algorithm”. Suggest to make them consistent.

Best regards,
Jie

From: Pce [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Friday, February 18, 2022 12:08 PM
To: [email-masked]
Cc: [email-masked]; Mahendra Negi <[email-masked]>
Subject: Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi WG,

Thanks!
Dhruv & Julien

Have a great weekend.

Thanks!
Dhruv & Julien

---

From: "Samuel Sidor (ssidor)" <[email-masked]>
Date: Fri, 18 Feb 2022 11:26:49 +0000

Hi Jie,

Combining responses for 1. and 2. as those are related:

Encoding of SID/ERO-subobject level was used, because of multiple reasons:

a)      We may need to signal SL, which is explicitly configured by user (not just computed by PCE) and in such case user can potentially mix SIDs with different algorithms (if user is accepting risk of loops or if user knows that it cannot happen for various reasons in that specific case).

b)     Different algorithm ID != different algorithm. With flex-algo different ID can be used for identification of same algorithm (e.g. in different IGP domains). Mixing SIDs with different algorithm ID in such case is safe, but we would not be able to signal such path in PCEP.

c)      Also related to explicit SL – in some cases, user may configure SL explicitly on headend. Headend may not be able to resolve complete SL, so it may not be sure if algorithm of all SIDs is same.

3. We defined new types in older version of this draft – see:
https://datatracker.ietf.org/doc/html/draft-tokar-pce-sid-algo-03#section-6.1
but there were multiple comments indicating that it is resulting in too many new types (we need to extend draft for Adjacency SIDs as well) and it would be hard to maintain it for future – e.g. for cases where new NAI types are added. With this change we would have to double number of NAI types. Any extension like this in the future would double it again.

4. Makes sense. We will align it.

Regards,
Samuel

From: Dongjie (Jimmy) <[email-masked]>
Sent: Friday, February 18, 2022 10:09 AM
To: Dhruv Dhody <[email-masked]>; [email-masked]
Cc: [email-masked]; Mahendra Negi <[email-masked]>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi WG, chairs,

Best regards,
Jie

From: Pce [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Friday, February 18, 2022 12:08 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Mahendra Negi <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi WG,

Thanks!
Dhruv & Julien

Have a great weekend.

Thanks!
Dhruv & Julien

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 21 Feb 2022 15:44:33 +0000

Hi Samuel,

Thanks for your reply. Please see further inline:

From: Samuel Sidor (ssidor) [mailto:[email-masked]]
Sent: Friday, February 18, 2022 7:27 PM
To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Dhruv Dhody <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Mahendra Negi <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Jie,

[Jie] Do you mean using PCEP to signal a configured SID list which consists of SIDs with different algorithms? To avoid the risk of loop, normally user would prefer to configure either SID list with strict path, or SIDs with consistent algorithm. Even if it is known that there is no loop, different algorithms represent different requirements to the path, logically can a path built with different algorithms meet specific requirement?

Thus it would be helpful to describe the typical scenario(s) of configuring SIDs with different algorithms .

[Jie] I agree in the inter-domain case, the same algorithm can be represented using different IDs, and SIDs associated with different algorithm IDs can be used to build an inter-domain path to meet certain requirement. I’d suggest to add some description about this case to the document, and it would be better to limit the usage of different algorithm IDs in the ERO to this inter-domain case only.

[Jie] Understood.

[Jie] Thanks for the pointer, I understand the cost of introducing new NAI types. While comparing to the format of SID types in BGP SR Policy, there is a fixed algorithm field and a A Flag is used to indicate whether this field carries an algorithm value or not. Perhaps another approach is to update the format of the existing NAI types to include the algorithm field. This could also better align the NAI types in PCEP with the Segment types in BGP.

Thoughts?

Best regards,
Jie

Regards,
Samuel

From: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, February 18, 2022 10:09 AM
To: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Mahendra Negi <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi WG, chairs,

Best regards,
Jie

Hi WG,

Thanks!
Dhruv & Julien

Have a great weekend.

Thanks!
Dhruv & Julien

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 22 Feb 2022 15:12:59 +0530

Hi WG,

The adoption poll is closed. The I-D is adopted as a PCE WG item.

Authors,

Please submit the existing I-D as draft-ietf-pce-sid-algo-00. You have also
received various comments and suggestions for improvements. Please handle
them in the -01 version. Do think about adding text describing your
motivations behind the various design choices to help the reader understand
them.

Thank you,
Dhruv & Julien

---

From: "Samuel Sidor (ssidor)" <[email-masked]>
Date: Tue, 22 Feb 2022 09:49:20 +0000

Hi Jie,

Thanks for your comments. Please see inline <S>:

Regards,
Samuel

From: Dongjie (Jimmy) <[email-masked]>
Sent: Monday, February 21, 2022 4:45 PM
To: Samuel Sidor (ssidor) <[email-masked]>
Cc: [email-masked]; Dhruv Dhody <[email-masked]>; [email-masked]; Mahendra Negi <[email-masked]>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Samuel,

Hi Jie,

<S> In most of the cases, requirements == algo used, but there are cases, where it may not be possible. Some examples.

·        case b) bellow (inter-domain)

·        support for less capable nodes (e.g. some node/nodes without SSPF/Algo1 support, but user want to use SSPF SIDs wherever possible and where user knows that it is still safe to mix SIDs). Implementation (PCE/PCC) can have local policy (e.g. some configuration) to decide if potentially unsafe paths should be used or blocked.

As soon as we have at least possible use case (even if it is corner case), it may be bad idea to block it on protocol level. I agree that it may be good to describe use cases above in the draft.

<S> I’m not sure if we can really have hard requirement for PCC or PCE to check it. E.g. in case of configured SID list on PCC - PCC may not have visibility to whole topology in case of inter-domain paths, so it may not be able to verify it. E.g. consider that user configured SID list like this:

1.      Label 26000 (algo 128)

2.      Label 26005 (algo 129)
PCC can just blindly report such path to PCE even if it does not know if both SIDs are in same area/domain or not. If we will strictly say that it is not valid, then user configured path can result in breaking protocol level limitations. Same applies to PCE, which can be potentially used only as a proxy.

[Jie] Understood.

Thoughts?

<S> In case of approach with fixed algorithm field – what is the benefit of always including algorithm field even if it is not used? Because PCEP implementation will have to support both formats of SR-ERO – with and without algorithm field anyway (backward compatibility with implementations with algo draft support), so if algorithm is not really specified, we will just increase size of encoded ERO with no added value.

For approach with updating existing NAI types – yes, I think that it can be done, but:

1.      At least for me, SID Algo logically does not belong into NAI – even based on name NAI is supposed to be used for Node or Adjacency identifiers – I’m not sure how algo is identifying node or adjacency here.

2.      NAI is optional – it will be required to include NAI even if it is not really needed in specific cases

3.      Draft would still have to update them one by one, so it will have similar problem as original version of this draft – limited/expensive extensibility.

Best regards,
Jie

Regards,
Samuel

Hi WG, chairs,

Best regards,
Jie

Hi WG,

Thanks!
Dhruv & Julien

Have a great weekend.

Thanks!
Dhruv & Julien