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

[Ketan Talaulikar <[e-mail]>]

Hi Sue,

Please check inline below for responses with KT2 and I am available for a
phone call to discuss further.


On Thu, Jun 16, 2022 at 1:17 AM Susan Hares <[e-mail]> wrote:

> 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.
>
>
>
>
>
> On Sat, Jun 11, 2022 at 1:54 AM Susan Hares <[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
>
>
>
> 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
>
>
>
> 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.
>

KT2> Could you point me to an IDR implementation report where this level of
details related to error handling is being documented so I can follow the
same? We can try to reach out to the developers at the various vendors in
the report to see if they can help/fill in those details. Perhaps you could
poll the WG once the updated version of the draft is posted?


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

KT2>  Please poll the WG once the updated version of the draft is posted.

>
>
> 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. This document
> updates RFC9012 by defining some of those flag bits.
>
>
>
> Sue> You must indicate which AFI/SAFIs these flags work for.
>

KT2> Please see a further response which clarifies this.


> Please note you must provide implementation report on the flags.
>

KT2> We do have that already under "Color Extended Community Support for
Steering over SR Policy" in the implementation report.


> 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 is similar.
>
>
>
> Sue> See section 6 paragraph 1 of RFC9012 – where it specifies the
> semantics.
>

KT2> Exactly and it remains unchanged by this draft. So all those AFI/SAFI
specified in RFC9012 Sec 6 para 1 use the Color Extended Community and we
are not introducing anything new in this document. As a reminder, this
document does not specify the use of Color Extended Community with the new
AFI=1/2, SAFI=73.

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

KT2> You are correct about the range for weight. It is not being explicitly
called out though in the SR Policy draft which is now at the RFC editor.
Also, we are missing the text that says it is a 4-octet value, and I will
fix this.


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

KT2> Ack. Will fix this.

Thanks,
Ketan


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