Re: [Idr] draft-ietf-idr-segment-routing-te-policy-17.txt

[Susan Hares <[e-mail]>]

Ketan:

See my comments inline.  We are getting very close with this draft.

You will need a revision on the draft to section 3.
We need additional information in the implementation report before I can call for comments.

Please let me know if discussing this on a phone call will help.

Sue

From: Ketan Talaulikar <[e-mail]>
Sent: Wednesday, June 15, 2022 1:55 PM
To: Susan Hares <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Dongjie (Jimmy) <[e-mail]>
Subject: Re: draft-ietf-idr-segment-routing-te-policy-17.txt

Hi Sue, Thanks for your review and feedback. Please check inline for responses.  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzM4YWFlZDQ3NTIwMTI2NWJiODUyOWI3NmU2OWU1ZjgwLzE2NTUzMTU2OTUuOTI=#key=3b0a178212dbe27cdce9bdc600bfa1bc>  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>

Hi Sue,

Thanks for your review and feedback.

Please check inline for responses.


On Sat, Jun 11, 2022 at 1:54 AM Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
Stefano, Clarence, Ketan, Paul, Dhanendra and Steven:

Thank  you for your continued support in standardizing this specification.

My latest shepherd’s report is based on -17.txt.
It has 3 parts: implementation report issues, technical issues, and editorial nits.
Please let me know if you have any questions.

As always, I welcome the opportunity to chat with one or all of the authors to
quickly resolve any issues.

Sue Hares

Implementation report issues
----------------------------------------
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-segment-routing-te-policy%20implementations%20<https://shared.outlook.inky.com/link?domain=trac.ietf.org&t=h.eJxFjkFuwyAQRa8SIXUXjCEdYrLKVbAZ2yPbYMFEURvl7jXZdDnvSe_PSzzyKm4nMTPv5aYUZz80hDw2KU-fS1HI6kkLqZD9yLJKeTBZcNowsszpwRQnySj3tNLw82Va2vYVq_VMKZaDiPNJLHUpIh9p3UJnnTaqzD5jucfwOzdD2tSl8x7D9xVMq42Fvu_AuP5q0TqEsWuVtgAXDdZB40ytYq0uyD7y5_P7tHlaa6zaUO0_ef8BfxlNGQ.MEQCIFqyGazbRaLwtUC0hJuM3iiSOeOkkSaxC_LUGJsZo3gtAiAmYNkFUlpaHa_3puZdh5_P7q6pBb_FsQmtxWPwdRI0AQ>

According to this implementations report, we do not have any implementations that support:
TLV 15, 20, 129, and 130 in the following report:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-segment-routing-te-policy%20implementations%20<https://shared.outlook.inky.com/link?domain=trac.ietf.org&t=h.eJxFjkFuwyAQRa8SIXUXjCEdYrLKVbAZ2yPbYMFEURvl7jXZdDnvSe_PSzzyKm4nMTPv5aYUZz80hDw2KU-fS1HI6kkLqZD9yLJKeTBZcNowsszpwRQnySj3tNLw82Va2vYVq_VMKZaDiPNJLHUpIh9p3UJnnTaqzD5jucfwOzdD2tSl8x7D9xVMq42Fvu_AuP5q0TqEsWuVtgAXDdZB40ytYq0uyD7y5_P7tHlaa6zaUO0_ef8BfxlNGQ.MEQCIFqyGazbRaLwtUC0hJuM3iiSOeOkkSaxC_LUGJsZo3gtAiAmYNkFUlpaHa_3puZdh5_P7q6pBb_FsQmtxWPwdRI0AQ>

KT> Yes, that is correct AFAIK.
[Thank you for letting me know.]


The following is missing from the basic implementation report:
1) Is Error handling in section 5 is included in the base support?

KT> Yes.
Sue> Would you fill-in/check the error handling section in the implementation report based on that understanding.
2) What Segment type SubTLVs (Segment type A-K) have been implemented in these implementations?

KT> AFAIK all the listed implementations support the Type A (i.e. MPLS Label). I believe one of the implementations also support SRv6 SID. I will request the WG members from the vendors to update the implementation report (or drop me and the IDR chairs an email so we can update on your behalf).

Sue> I will need this information prior to querying the WG regarding the implementations.
Drop me an email when you are done.

After you provide these details, I will query the IDR WG to determine if the
IDR finds this level of support sufficient to pass the document as is to the IESG.

Technical issues (Shepherd’s report)
=====================================
1) Color Extended community (section 3)
Level of Issue: small if NLRIs with SAFI 73 (AFI=1/SAFI=73, AFI=2/SAFI=73)

The Color Extended community specifies setting the bit flags in the Color Extended Community [RFC9012] section 4.3.  However, you are specifying setting the flag bits which RFC9012 specifies you must set to zero.

KT> RFC9012 introduced the Flags field but did not define any flags and hence the set to zero - https://datatracker.ietf.org/doc/html/rfc9012#section-4.3<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJxFzkEOgyAUBNCrNHTbgqAfxZVXQfiKUaHB302b3r3STbczk5d5s2feWH9hgehx9EJ4S5aydStmviBNPOVZ-OREoH0TeXKmkup6oKMlxXvDa3a7sLUIEencygo6baQSR7AZjyH6V-Au7aLurEXftKBOQMM4dqDM2GrUBmHqKiE1QC1BG-BGFRWLuiLZSL8rw7zbZStYaX1p_8nnCxtbPSQ.MEYCIQDUUvlmnhPdSh6X5FQ2k3OWQVOQODOddUQ6ZBjNPbLznwIhALIUlmnI91RYigD8XkXsu1WHQ3gGgcTSB72n6vt4wW7E>. This document updates RFC9012 by defining some of those flag bits.

Sue> You must indicate which AFI/SAFIs these flags work for.
Please note you must provide implementation report on the flags.
I’ll need an update to the draft and an update to the document on this information.


Are you defining the color Extended Community only for the AFI/SAFI pairs defined in this document?

AFI=1/SAFI=73, AFI=2, SAFI=73

KT> No. They apply to BGP service routes mostly (e.g. L3VPN, EVPN, etc.).
 Sue> See above comment.  You must specify which AFI/SAFIs the Extended Community flags
Apply to.  Your implementation reports must match that.

If so, please add to the text of section 3 (and sprinkle in where appropriate in the RFC)
that these additions to the Color Extended Community are specific to these
NLRI (AFI=1/SAFI=2).

If not, please explain carefully which NLRI (AFI/SAFI pairs) your
Additions to Extended Community apply to.

KT> Is this really required?

RFC9012 which specifies the Color Extended Community did not impose any limitations on the AFI/SAFI to be used. The usage described in https://datatracker.ietf.org/doc/html/rfc9012#section-8<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJxFjkESgyAQBL9ikWsCglkET34FYRVLxRRuLknl75Fccp2Z7po3e-aVdRWLRI-jEyI4cpSdXzDzGWnke55E2L2ItK0ij97WUl0O9DTv6WbYtWJL4RPSuZQ1GG2lEkd0GY8-hVfkft9EY5zDcG9BnbiGYTCg7NBq1BZhNLWQGqCRoC1wq4oVi3VBcol-R_ppc_NaZKUNpf0nny-9ETzH.MEUCIHfzZQgpJ6XL6jT2ewLSjPzNKcHCv7YuN1osOgetGfueAiEA10_N-rvl8ZjvAXqFpcI6UXikP-ti7FW0LE30E8MPt6E> is similar.

Sue> See section 6 paragraph 1 of RFC9012 – where it specifies the semantics.

2)  Technical issue (sections 2.4.4.1, 2.4.4.2, 2.4.4.9, 2.4.4.10, and 2.4.4.11
Level: Small  – just needs tightening the text

The following ranges need to be specified:
a) weight value – give range or indicate any bit pattern [section 2.4.4.1),

KT> The reference to the SR Policy draft provides this info and we did not want to repeat it here.
Sue> It provides the information, but I could not locate the range.
If you have reference in the SR Policy draft for the range of weight (0-all 1st),
I’m glad to withdraw my comment.
b) section 2.4.4.2.2 (segment B)
Old/length is variable/
New/length is variable (18 if SRv6 Endpoint and SID structure field is not included, 24 if the field is included). /

Note: You may modify wording if the length values are specified.

Please make similar  changes to specify valid lengths in section 2.4.4.9 (segment I) and
Section 2.4.4.2.10 (Segment J) and  the ranges of valid lengths in 2.4.4.11 (segment K).

KT> Whether the "SRv6 Endpoint and SID structure field" is present or not is indicated by the B-Flag in the Segment Flags field and not by the length. I feel it is more appropriate to keep it variable. In some of the segment types, there are more than one optional field and so a few combinations.
 Sue> I’m looking for variable (valid-value-1, valid-valid-2).
You made this change for most of the parameters.




Editorial nits:
1) abstract –
Old text:/This document defines a new BGP SAFI with a new NLRI/

Question:  Since you are defining this with two pairs (AFI=1/SAFI=73, AFI=2, SAFI=73),
IMHO, this is two NLRI formats.  It is a small point, but this editorial nit
Is sprinkled across all the pages.

KT> Ack. Will fix.


2) section 1 paragraph 8, starting with “this document defines a new BGP Address family.
You are defining two new AFI/SAFI pairs using a new Subsequent Address Family Identifier (SAFI)

KT> Ack. Will fix.


Please adjust this paragraph to be consistent with current technology.
Review paragraphs 10 (starting “Typically, “) and paragraph 14 (starting “The BGP Extensions”).
for the same error.

KT> I did not understand the error that you are referring to on para 10. Fixed for para 14.
Sue> them could be replaced to a specific reference to NLRI.  However, It is a nit so you may skip it.

3) English errors in Introduction

Old Text: /
Typically a controller defines the set of policies and advertise
them to policy head-end routers (typically ingress routers).  The/
New text:/
Typically a controller defines the set of policies and advertises
them to policy head-end routers(typically ingress routers).  These /

KT> Will fix.

Thanks,
Ketan


(subject-verb alignment) plus “Reference to set”.