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

Nandan Saha <nandan@arista.com> Mon, 03 July 2017 12:14 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 C3FE2126557 for <idr@ietfa.amsl.com>; Mon, 3 Jul 2017 05:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 c3vH-Dr3Qziw for <idr@ietfa.amsl.com>; Mon, 3 Jul 2017 05:14:22 -0700 (PDT)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 EB143126BF6 for <idr@ietf.org>; Mon, 3 Jul 2017 05:14:21 -0700 (PDT)
Received: by mail-ua0-x231.google.com with SMTP id z22so108256453uah.1 for <idr@ietf.org>; Mon, 03 Jul 2017 05:14:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=hw7De9DLosNZHRTRdyVOL8MvIebc8zblLyylM/0Yr3c=; b=ZlfgpJrmpK8dSKdrjqv3tpV45vmJ6mcaSAPIhGjM6g9A8C4T/vwx8HpzhLZ2lMO5mn CcIgh32GVTOHL2ACKBe4Kl217HhHvJbiuCSvjsRdz1iKMNMLkxf9IB4kNnCsehPl+leV TPlnYVaC1y/aCviU0hRL4W1LxoUGA/enIhJxo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=hw7De9DLosNZHRTRdyVOL8MvIebc8zblLyylM/0Yr3c=; b=LhK6IIQUO5TZEoTuTPVKE8h3/afZZ6f0kv9C3h2TkYfPNELGjdvYOgClDL/9c/A/Ri tlb5XQDdh+1fIxJ6ucYzyZAHQjC+cGnLK4wxRSwzlHZCBCG00rLbaKGiYxOPZ2dRMA6T I4x06aSX8TMUMObb7KOEa+dBtR9HiP9zPQ5hHoUdLijiZTgTBTqebmgS8g1l0tnTLmXu Ahg6upNMTJYOsi3/sT+9b2CcBnZBWi0NiXd6fIbaupHT6gojIEaHEyFpIZhQE7V1pvDn f9Emx8wCpJayVnfuN3IYr5bwj9qp5Vg7p2KsiY8697m1pcnTVw5rPSQrpGMzvr9V7gy6 CryA==
X-Gm-Message-State: AKS2vOy0giOpQA+p/2a4shN02eyGlCH4G9yhzhM+9I3gN9d1Vfpgwfcs io7458WAxbskFYxAV5tUviX8xH2cANnyrOdn7Q==
X-Received: by 10.159.59.175 with SMTP id r47mr14435445uah.91.1499084060791; Mon, 03 Jul 2017 05:14:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.4.46 with HTTP; Mon, 3 Jul 2017 05:14:20 -0700 (PDT)
In-Reply-To: <149824800169.17379.9099679082498238196@ietfa.amsl.com>
References: <149824800169.17379.9099679082498238196@ietfa.amsl.com>
From: Nandan Saha <nandan@arista.com>
Date: Mon, 03 Jul 2017 17:44:20 +0530
Message-ID: <CAE+itjf-1OPtKbADxAVft5+XufAWo3ebbXsamS+Mpt_2cTwzzg@mail.gmail.com>
To: idr@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ij4OcFUzMwRMhOaani55WsbzlJ8>
Subject: Re: [Idr] I-D Action: draft-previdi-idr-segment-routing-te-policy-07.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 03 Jul 2017 12:14:26 -0000

Hello!

 I have some questions on the NLRI encoding.
1. Can the value of NLRI length be less than 96 for IPv4 AFI and less
than 192 for IPv6 AFI? IOW, can it be less than full mask length for
the end point address?
2. If the answer to (1) is "yes", then what is the rationale for
keeping the end point address field of the NLRI fixed length? (4 or 16
bytes depending on AFI). Should the end point become variable length
like the NLRI encoding defined in RFC4760?
3. If the answer to (1) is "no", how are summary addresses to be represented?


Another question which is unrelated to the changes in version 7 of the draft.
Section "4.2.1. Acceptance of an SR Policy NLRI" says
 " If the NLRI is not one of the legal lengths, a router supporting
this document and that imports the route MUST consider it to be
malformed and MUST apply the "treat-as-withdraw" strategy of [RFC7606]
"
It's not clear to me how a receiver can extract a valid route from a
malformed NLRI. The "treat-as-withdraw" can be applied if the NLRI is
well formed but some other attributes are malformed, which seems to be
implied by the following line at the end of the subsection
"A unacceptable SR Policy update that has an invalid NLRI portion MUST
trigger a reset of the BGP session."

Thank you!
Best regards,
Nandan

On Sat, Jun 24, 2017 at 1:30 AM, <internet-drafts@ietf.org> wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Inter-Domain Routing of the IETF.
>
>         Title           : Advertising Segment Routing Policies in BGP
>         Authors         : Stefano Previdi
>                           Clarence Filsfils
>                           Paul Mattes
>                           Eric Rosen
>                           Steven Lin
>         Filename        : draft-previdi-idr-segment-routing-te-policy-07.txt
>         Pages           : 30
>         Date            : 2017-06-23
>
> Abstract:
>    This document defines a new BGP SAFI with a new NLRI in order to
>    advertise a candidate path of a Segment Routing Policy (SR Policy).
>    An SR Policy is a set of candidate paths 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 candidate paths.  New sub-TLVs for the Tunnel
>    Encapsulation Attribute are defined.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-previdi-idr-segment-routing-te-policy/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-previdi-idr-segment-routing-te-policy-07
> https://datatracker.ietf.org/doc/html/draft-previdi-idr-segment-routing-te-policy-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-previdi-idr-segment-routing-te-policy-07
>
>
> 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