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

Nandan Saha <nandan@arista.com> Wed, 20 November 2019 03:01 UTC

Return-Path: <nandan@arista.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 D91661202A0 for <idr@ietfa.amsl.com>; Tue, 19 Nov 2019 19:01:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=arista.com
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 JZluLp5fKTyR for <idr@ietfa.amsl.com>; Tue, 19 Nov 2019 19:01:50 -0800 (PST)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E5A1201E0 for <idr@ietf.org>; Tue, 19 Nov 2019 19:01:50 -0800 (PST)
Received: by mail-ot1-x334.google.com with SMTP id w24so19458270otk.6 for <idr@ietf.org>; Tue, 19 Nov 2019 19:01:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=googlenew; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sFYuo+NbXZFXY2md64YK2NbAFbGERZF0EsKNJf4qh38=; b=RAIA4DRTQ+/qPsf+G1TUxWa5ldrgllpHTWlesw/pEJT+eM0FAxEFiRSfZ0X6HIC/k6 Im5z1+05rCVgXDm77zsrOhRMfn7OFFpe/4aS39TtGn2tS44YQvQeNtkMuRoPw+hZYoTU 4pHT0EAQfcZqLqA8jbJSeNuRoDy+pfjtNCDXYA3OGnj89N5HC4e0wbyGSg/P0H0R86ZN 1WQz0/4u8edu9ixrTWjnRsqzBVYFQTf1MQmraISyrIC964T4TZuqmitXDJxLlrvHmGvg 5dN9fQ+95ACRpopLS936+dNMW/VIPOXxTonMSmEz8fcFNP3Nehqf5N1+wY2HBjx5zQxW u54w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sFYuo+NbXZFXY2md64YK2NbAFbGERZF0EsKNJf4qh38=; b=SlWXvd6QEHXimPkMC9/9KTGRN7m9m/b61b71z/wIvGjA0/wqawh2VNdnQIZIRlSLkL HGY082KuvdcG6vtgvtXqWTC5GeqJ/agvw/EMfZyNmC9JjayfiZh8ZnJCnfk9SCJpxTMI 2mUrOpx68PYosqh4WcoR6gbWGTc9SfsfjzKsVAwyOOEN8ymylvzQjZjJCaoLX+/308ug T7rRlqqI/HgHOnkx2niI3CkDMP9owot2o1+RSfJHuREjAgcp9uKY2lEVB1p9px9jMFWd 6/SUJxcvoPRP9I6CgXwCqM0Yvi3o0plIwN1l6pR1WaY9/1FtBO/GW5i5cq+neikaBhSx RvMA==
X-Gm-Message-State: APjAAAXpx58+nUCX/77TIs5nvOYBWOOvgYoX/8oX7aglU1kFKxFS67K8 8xT6guLfYzLL/PAxI0o2veMYRHNUBHWG7Sza3ZGyEA==
X-Google-Smtp-Source: APXvYqyOzzLAfs71PGXJsIyx1BcLSe2G6KTRSDUbu2d5xmYkOuElTx/pY7QgWfr1SC2zQF89+1eTn/PpgIk8hssq3TY=
X-Received: by 2002:a9d:82e:: with SMTP id 43mr193374oty.23.1574218909685; Tue, 19 Nov 2019 19:01:49 -0800 (PST)
MIME-Version: 1.0
References: <157414471256.14003.6244444687150312939@ietfa.amsl.com> <CY4PR11MB1541D63781E529E2B2613F05C14C0@CY4PR11MB1541.namprd11.prod.outlook.com> <CAE+itjeJzygag3K4bA=KpDQgNie7shG8Z47YpMjfjMFF7aq=Tg@mail.gmail.com> <CY4PR11MB15414543EC96BB90BC1167D8C14C0@CY4PR11MB1541.namprd11.prod.outlook.com>
In-Reply-To: <CY4PR11MB15414543EC96BB90BC1167D8C14C0@CY4PR11MB1541.namprd11.prod.outlook.com>
From: Nandan Saha <nandan@arista.com>
Date: Wed, 20 Nov 2019 08:31:37 +0530
Message-ID: <CAE+itjcjNM+adLS_7ej4m=LFPixRo4OaWLondFzdngP_jCsW1g@mail.gmail.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: "idr@ietf.org" <idr@ietf.org>, Prakash Badrinarayanan <prakash@arista.com>, Manoharan Sundaramoorthy <manoharan@arista.com>
Content-Type: multipart/alternative; boundary="000000000000e9494a0597be667a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/g1AN7i8Fr_SgYGmnX99XMzO6j_k>
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: Wed, 20 Nov 2019 03:01:59 -0000

Hi Ketan,
 Please see inline, [nandan]

On Wed, Nov 20, 2019 at 5:21 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.
>
> 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 <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
>
>