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

["Samuel Sidor (ssidor)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Ketan Talaulikar
Sent: Tuesday, February 8, 2022 6:38 PM
To: Dhruv Dhody <[e-mail]>
Cc: [e-mail]; [e-mail]
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 <[e-mail]<mailto:[e-mail]>> wrote:
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
_______________________________________________
Pce mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/pce