Re: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt

Howdy Ketan,

Few nits:

2.2. SR Policy and Tunnel Encapsulation Attribute
If more than one TLV of type "SR Policy"
   appears, the update is considered malformed and the "treat-as-
   withdraw" strategy of [RFC7606] is applied.

Given this version introduces an explicit error handling section (5.  Error
Handling), would it be reasonable to delete this? I believe this has been
done for other tlv/sub-tlvs already.

3.  Color Extended Community

two bits from the RESERVED field (as
 defined in [I-D.ietf-idr-tunnel-encaps]) *is are* used as follows

4.2.1. Acceptance of an SR Policy NLRI This section explicitly requires
either Route Target(s) or Community in order to consider policy valid:

The SR Policy update MUST have either the NO_ADVERTISE community
      *or* at least one route-target

and clearly states the behavior when both are missing (policy not
accepted). Do you see a value in stating the behavior when both are
present? Based on the above wording this would deem policy not acceptable
and in consequence neither accepted locally not propagated down (must not
accepted, not necessarily usable, in order to propagate as stated in the
following section). Should it be clearly stated as erroneous condition?

4.2.4. Propagation of an SR Policy

It seems that the original wording was referring to just BGP when
addressing the default propagation. In the current version, there is a
distinction between EBGP (do not propagate) and IBGP (propagate). What is
the reason for such distinction?

Additionally,

A BGP node advertises a received SR Policy NLRI to its IBGP neighbors
according to normal IBGP propagation rules.

this would imply that if a node receives an advertisement by IBGP it would
not propagate it down via IBGP ("normal IBGP propagation rules"), is that
correct? If so, this section really describes a case when a node receives
SRTE policy via EBGP. Given the distinction between IBGP and EBGP
introduced in this version, would it make sense to be more specific in this
case as well?

thanks,
pk

On Wed, Nov 20, 2019 at 7:51 AM Ketan Talaulikar (ketant) <ketant@cisco.com>
wrote:

> Hi Nandan,
>
>
>
> When the acceptance criteria fails, the update is considered malformed and
> the TAW or AFI/SAFI disable or session reset would be the error handling
> based on what the specific error is as described in sec 5.
>
>
>
> In Sec 4.2.1 we have the following text.
>
>
>
> A router that receives an SR Policy update that is not valid
>
>    according to these criteria MUST treat the update as malformed and
>
>    the SR Policy candidate path MUST NOT be passed to the SRPM.
>
>
>
> Then in the Sec 5 for error handling we specify the treatment for errors
> in the NLRI part, the Tunnel Encap Attribute (it’s existing TLVs) and then
> the new ones introduced in this document. E.g. for the TLV/sub-TLVs in the
> Tunnel Encap attribute (new and old)
>
>
>
> In case of any error detected, either
>
>    at the attribute or its TLV/sub-TLV level, the "treat-as-withdraw"
>
>    strategy of [RFC7606 <https://tools.ietf.org/html/rfc7606>] MUST be applied.
>
>
>
> Hope that clarifies.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Nandan Saha <nandan@arista.com>
> *Sent:* 20 November 2019 00:47
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>
> *Cc:* idr@ietf.org; Prakash Badrinarayanan <prakash@arista.com>;
> Manoharan Sundaramoorthy <manoharan@arista.com>
> *Subject:* Re: [Idr] I-D Action:
> draft-ietf-idr-segment-routing-te-policy-08.txt
>
>
>
> Hi Ketan,
>
>  Thank you for the updated version. I'm still reviewing it, but spotted
> something I wanted to quickly clarify.
>
>
>
> ver-7 of section "4.2.1. Acceptance of an SR Policy NLRI" had text
> mandating RFC7606 TAW if acceptance criteria fail. In ver-8 this has been
> removed, and I can't quite tell what text in section "5 Error Handling"
> covers this? I'm assuming we still want to do TAW if acceptance criteria
> fail.
>
> Please clarify.
>
>
>
> Thanks,
>
> Nandan
>
>
>
>
>
> On Tue, Nov 19, 2019 at 1:39 PM Ketan Talaulikar (ketant) <
> ketant@cisco.com> wrote:
>
> Hi All,
>
> This update of the draft is to get it ready for the WG to review towards
> WGLC .
>
> The following is the high level overview of the changes:
>
> 1) Introduced Error Handling section where all these aspects have been
> consolidated.
>
> 2) Added the request for IANA registry for Color Extended Community
> reserved field. Changed the process to Specification Required and added DE
> guidelines since the flags and other space is too small for FCFS.
>
> 3) Added security consideration section.
>
> 4) Add the clarification for handling of route target during propagation
> as per the request and discussions on the mailer and also clarified the
> matching with BGP Router ID part.
>
> 5) Changed the segment type naming from numbers to alphabets to align with
> upcoming update in the draft-ietf-segment-routing-policy to remove
> confusion between the segment types and the protocol code-points as
> discussed on the Spring and IDR lists recently.
>
> Besides this, there are other minor and editorial changes to prepare for
> WGLC.
>
> We are also trying to capture all the implementation reports at the wiki
> below and would request WG members to help update the same as there are
> multiple shipping implementations of this specification:
>
>
> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-segment-routing-te-policy%20implementations%20
>
> Also note that the draft is on IDR agenda for presentation on Thu in
> Singapore.
>
> Thanks,
> Ketan (on behalf of co-authors)
>
> -----Original Message-----
> From: Idr <idr-bounces@ietf.org> On Behalf Of internet-drafts@ietf.org
> Sent: 19 November 2019 14:25
> To: i-d-announce@ietf.org
> Cc: idr@ietf.org
> Subject: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Inter-Domain Routing WG of the IETF.
>
>         Title           : Advertising Segment
>     Routing Policies in BGP
>         Authors         : Stefano Previdi
>                           Clarence Filsfils
>                           Ketan Talaulikar
>                           Paul Mattes
>                           Eric Rosen
>                           Dhanendra Jain
>                           Steven Lin
>         Filename        : draft-ietf-idr-segment-routing-te-policy-08.txt
>         Pages           : 38
>         Date            : 2019-11-18
>
> Abstract:
>    This document defines a new BGP SAFI with a new NLRI in order to
>    advertise a candidate path of a Segment Routing (SR) Policy.  An SR
>    Policy is a set of candidate paths, each consisting of one or more
>    segment lists.  The headend of an SR Policy may learn multiple
>    candidate paths for an SR Policy.  Candidate paths may be learned via
>    a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP.
>    This document specifies the way in which BGP may be used to
>    distribute SR Policy candidate paths.  New sub-TLVs for the Tunnel
>    Encapsulation Attribute are defined for signaling information about
>    these candidate paths.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-idr-segment-routing-te-policy/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-08
>
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-08
>
> A diff from the previous version is available at:
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-segment-routing-te-policy-08
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

-- 
Przemyslaw Gniewomir "PK" Krol |   Network Engineer ing | pkrol@google.com