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

[Ketan Talaulikar <[e-mail]>]

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.


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

KT> Yes.


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


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


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


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


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


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


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


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