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

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Tue, 19 November 2019 23:51 UTC

Return-Path: <ketant@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D66712089B for <idr@ietfa.amsl.com>; Tue, 19 Nov 2019 15:51:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iSVhD143; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hfGrpisz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLKmlM39nwqv for <idr@ietfa.amsl.com>; Tue, 19 Nov 2019 15:51:11 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7808A12008C for <idr@ietf.org>; Tue, 19 Nov 2019 15:51:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26932; q=dns/txt; s=iport; t=1574207471; x=1575417071; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=j2b6TAd/yAyDWmeqGbjCrb6u4nN/jwpLgiGve1BkhW0=; b=iSVhD143it/Uw/NUJa4sXDtJ3HJ7MJny/FgOQPn4VIuUIujrIeZrY0Oo XS51IS/ZPt1qZb7aH2WFyxXI8K73bgK7nAj33jUofgwySZ9C8g+dUvxtL pKvAWK5ttiCoZ7G26k9TSsqNLXo3AdEkB4NUoqnwqDB/+MLvT3+yAJFbj A=;
IronPort-PHdr: 9a23:bgm2ohz04R+H4HDXCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5YR2N/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1kAgMQSkRYnBZuGBFHyKuLCZC0hF8MEX1hgrDm2
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AYAAAQf9Rd/5FdJa1lGwEBAQEBAQEFAQEBEQEBAwMBAQGBagYBAQELAYEbLyQFJwVsWCAECyqEKoNGA4RahhmCXn+XAYEuFIEQA1QJAQEBDAEBGAEMCAIBAYRAAheCDiQ0CQ4CAw0BAQQBAQECAQUEbYU3DIVRAQEBAQMBARARChMBASwLAQsEAgEIEQQBASgDAgICJQsUCQgCBA4FCAwOgwGBeU0DLgEOpwMCgTiIYHWBMoJ+AQEFgTgCDkGDBBiCFwmBNgGMFBiBQD+BEUaCFzU+gmIBAQIBARaBLwEZKwkIglIygiyQE4VHiUaPDQqCK4cahSaJKoI+c4Z1j2uQCYZ3kVACBAIEBQIOAQEFgT8TOYFYcBUaIYJsCUcRFJEagScBCYJChRSFP3SBKI4RAQE
X-IronPort-AV: E=Sophos;i="5.69,219,1571702400"; d="scan'208,217";a="376291398"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Nov 2019 23:51:10 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id xAJNpAds017011 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Nov 2019 23:51:10 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Nov 2019 17:51:09 -0600
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Nov 2019 17:51:08 -0600
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 19 Nov 2019 17:51:08 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k8xT7BF3nyvQkmwPH6UX64Z36P32Oq6nsVzy1mDDZF5P8aliTMgJmd+hS5vxP4yAO2op99f4kR3i5L4vRLR3IFIGc8YhmPRIK2EuFptqRzCCHWJkm1smt3LETXb1aZ9ZzhRjiQZMwZ5IG1+JRzkLOTnUyamriMN57HASDQqR+CbuEdCZ69wS3Z1B11+fK/L/y/tDDsX2B2jELXvOBUqWS+mGlwhTyfldIssyVB+qtC45jm9H3rMU/POwRO6+vhACghxVNjyK/9CbnseZqWS0WdqXvQJxjZ4JB1UUn7bcVPvSO6MdvJ3tfrwoGLmrU0UXY/7itRFVVvi4ZqH3CHYeUg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j2b6TAd/yAyDWmeqGbjCrb6u4nN/jwpLgiGve1BkhW0=; b=jiyvO1r8uR0goGXUaVJhG8FhQKjSqYzWhqFLmSnIR9oznstU8jQDAPj9Fw4ARYIClYt2L2FhdXscA2giEeyrMRaIjgikJyja+6y66bHRW+izXM9YDngU/Ax9NQsNwDx/opCuGSFCIDKGj0MfmNAC6418ExmSkDxYzhjoE/Urlqygj9sPhb1393rkRE+OOg65Jhj6K5oWm21dFIEUC1SaqdsN5TQ5hJHM7OMTj8Gua3Xr4WjlrbzaqduUUXYpll6AYXdxizsW0nhlfbBbYvBBsnzAiC5+a1HXR3YCSzdK+gsuR2wn2oYbwb8lAjEj2Vu9ZUsUs4SsKY3cXUxC+vZlvw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j2b6TAd/yAyDWmeqGbjCrb6u4nN/jwpLgiGve1BkhW0=; b=hfGrpiszZC7U0Cm+G251909Ks0leJCHZZWTYv+v3Zl/fIPfpPDDXWegJt2ieXDnu74u6ANAg0IYUo6K5lG7u8uFM3V02sma/dpnvsGjxZ/Bdar7Z+LJiAtEtHyap9J/GalTKunPbNDgQUutKxw/pnDGQU0oFcCqIBcHYNGDyECc=
Received: from CY4PR11MB1541.namprd11.prod.outlook.com (10.172.68.150) by CY4PR11MB1255.namprd11.prod.outlook.com (10.173.17.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.23; Tue, 19 Nov 2019 23:51:07 +0000
Received: from CY4PR11MB1541.namprd11.prod.outlook.com ([fe80::d3a:84a6:be65:e33f]) by CY4PR11MB1541.namprd11.prod.outlook.com ([fe80::d3a:84a6:be65:e33f%11]) with mapi id 15.20.2451.031; Tue, 19 Nov 2019 23:51:07 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Nandan Saha <nandan@arista.com>
CC: "idr@ietf.org" <idr@ietf.org>, Prakash Badrinarayanan <prakash@arista.com>, Manoharan Sundaramoorthy <manoharan@arista.com>
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt
Thread-Index: AQHVnqIyRXgT11tsQk2IdX+1xczyjKeSIKDggACT7gCAAHQ9cA==
Date: Tue, 19 Nov 2019 23:51:07 +0000
Message-ID: <CY4PR11MB15414543EC96BB90BC1167D8C14C0@CY4PR11MB1541.namprd11.prod.outlook.com>
References: <157414471256.14003.6244444687150312939@ietfa.amsl.com> <CY4PR11MB1541D63781E529E2B2613F05C14C0@CY4PR11MB1541.namprd11.prod.outlook.com> <CAE+itjeJzygag3K4bA=KpDQgNie7shG8Z47YpMjfjMFF7aq=Tg@mail.gmail.com>
In-Reply-To: <CAE+itjeJzygag3K4bA=KpDQgNie7shG8Z47YpMjfjMFF7aq=Tg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ketant@cisco.com;
x-originating-ip: [2001:420:c0d4:1002::6d]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 15534b4b-8732-48c4-0f68-08d76d4b58b2
x-ms-traffictypediagnostic: CY4PR11MB1255:
x-microsoft-antispam-prvs: <CY4PR11MB12555E8FADF178D70A39B069C14C0@CY4PR11MB1255.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 022649CC2C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(346002)(366004)(136003)(396003)(189003)(199004)(53754006)(52084003)(13464003)(71200400001)(81156014)(81166006)(8676002)(66476007)(6306002)(64756008)(66446008)(55016002)(66556008)(236005)(66946007)(54896002)(9686003)(606006)(486006)(6436002)(229853002)(71190400001)(76176011)(33656002)(446003)(6506007)(7696005)(186003)(53546011)(2906002)(46003)(476003)(14444005)(256004)(99286004)(11346002)(316002)(4001150100001)(54906003)(25786009)(86362001)(102836004)(6116002)(74316002)(6246003)(790700001)(14454004)(966005)(478600001)(8936002)(7736002)(9326002)(66574012)(5660300002)(52536014)(76116006)(4326008)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB1255; H:CY4PR11MB1541.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 7T19eUU8UUYaSjOwu3bzmcxB5KUEh58RJegKgeMqFPobOM9a8YHEUFM6G1FlWluRibjbSUtEUbFGG/yB55vL/Qb2dmZZ6BSj1qsGZaGV6zSf1KakVmCJWjSBkCNuIt9fijUqjXef1QcAd1/bvk0pJuR4c4+qduM1T7W0s7erM3+EGhRGz1kbH8S8jsJQ/zQpTLhdLqRsX/lOgenqu7xuQV3ve8QaGuh00TTmEuJ7nWGcO9OwJw7r+kL7W83Hf/xFQ2wPqzJdbauKxKKI4j7zaCI2Nd9ijSUbItU2KvxPQz5BjhYotkp9TGzifxYn6FELpIKI6CNYuk99/B1m4tQ0+TGnxVxEKXxU3MEfDlVNtuC8w1OWAafY6rj3rb2tBSvv2wAfwz0FqBPz1g1CAFhNWEJltJSkSCDeYIrLvDpLeIJjGeO45NuQ+e7qDf++hwo7
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CY4PR11MB15414543EC96BB90BC1167D8C14C0CY4PR11MB1541namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 15534b4b-8732-48c4-0f68-08d76d4b58b2
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2019 23:51:07.2854 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hWQBZ9xOk6U2Qy8PEeG3WA6dcpjUsyB/2EYuPnfz75EhVctauK3FSmC6izDBxheoZ/A+BRJbROq07/QGPc7p1g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1255
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/fIjRHa8uQTLLfndPvPgCO0Rx0Ak>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Nov 2019 23:51:16 -0000

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<mailto: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<mailto:idr-bounces@ietf.org>> On Behalf Of internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Sent: 19 November 2019 14:25
To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>
Cc: idr@ietf.org<mailto: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<http://tools.ietf.org>.

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

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr