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

Hi PK,

Please check inline below for responses.

From: Przemyslaw Krol <[email protected]>
Sent: 20 November 2019 09:36
To: Ketan Talaulikar (ketant) <[email protected]>
Cc: Nandan Saha <[email protected]>; [email protected]; Prakash Badrinarayanan <[email protected]>; Manoharan Sundaramoorthy <[email protected]>
Subject: 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.
[KT] Ack


3.  Color Extended Community

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

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?
[KT] By itself, the NO_ADVERTISE indicates that the update should not be propagated (in general). If an RT is present, then it has to match the local BGP router-id otherwise the SR Policy is not usable on the local router. So I am not sure if this would be an error condition. However, I agree that this combination has not been covered in the spec and we can look for further feedback from the WG before concluding on this.

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?
[KT] The reason to not propagate for EBGP is security reasons since SR Policy information should not be send over to a different administrative domain. Even though Sec 4.2.4 had a MAY for IBGP propagation, we had this text in the introduction Sec 1 which was contradictory and hence clarified.

BGP can then be used to
   propagate the SR Policies and candidate paths.  The usual BGP rules
   for BGP propagation and "bestpath selection" are used.


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?
[KT] BGP propagation rules are followed normally. The only special case is for EBGP due to the security reasons and this has been discussed in the Security Considerations section.

Thanks,
Ketan

thanks,
pk


On Wed, Nov 20, 2019 at 7:51 AM Ketan Talaulikar (ketant) <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>>
Sent: 20 November 2019 00:47
To: Ketan Talaulikar (ketant) <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; Prakash Badrinarayanan <[email protected]<mailto:[email protected]>>; Manoharan Sundaramoorthy <[email protected]<mailto:[email protected]>>
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) <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> On Behalf Of [email protected]<mailto:[email protected]>
Sent: 19 November 2019 14:25
To: [email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
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<http://tools.ietf.org>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Idr mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/idr


--
Przemyslaw Gniewomir "PK" Krol |
  Network Engineer
ing | [email protected]<mailto:[email protected]>

_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr