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

"Ketan Talaulikar (ketant)" <[email protected]> Wed, 20 Nov 2019 08:18:48 +0000
Newsgroups gmane.ietf.idr
Message-ID <CY4PR11MB1541256505A4B3A17B858BB4C14F0@CY4PR11MB1541.namprd11.prod.outlook.com>
Hi Nandan,

Will adding the following text in Sec 5 address your concern?

An SR Policy update that is determined to be not acceptable, and therefore malformed, based on rules described in section 4.2.1 MUST be handled by the "treat-as-withdraw" strategy.

Thanks,
Ketan

From: Nandan Saha <[email protected]>
Sent: 20 November 2019 11:02
To: Ketan Talaulikar (ketant) <[email protected]>
Cc: [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

Hi Ketan,
 Please see inline, [nandan]

On Wed, Nov 20, 2019 at 5:21 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.
I don't think this is sufficient, since the acceptance can fail even if the RT_TGT and NO_ADV communities aren't present. These are not part of Tunnel Encap Attribute nor NLRI.

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]
https://www.ietf.org/mailman/listinfo/idr