Re: [Idr] I-D Action: draft-previdi-idr-segment-routing-te-policy-07.txt
Nandan Saha <nandan@arista.com> Fri, 06 October 2017 14:39 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 D163013209C for <idr@ietfa.amsl.com>; Fri, 6 Oct 2017 07:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 kKKzq0Bt4quo for <idr@ietfa.amsl.com>; Fri, 6 Oct 2017 07:38:53 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 96E181342E9 for <idr@ietf.org>; Fri, 6 Oct 2017 07:38:52 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id k4so8354359wmc.1 for <idr@ietf.org>; Fri, 06 Oct 2017 07:38:52 -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 :cc; bh=HJSl3UPa+iOQsKrloiV70KhE0qp4VT0EwrJEpPQeu5o=; b=KO0oACTSiuhxk23VisIxICxCHHEGwVHx4hTcklHQSVzHUyWS1zh/gvQ7bcEUduK8yP oZDsMWaMv9xTwxD2ExJE6vYi2rlpTjEHQQvaNPfdVjOTsZUriINgKjzPKRf+xEfL6jyH J6bFRFqdyprfNUvSg/TzUaLo2mTuAkXg8rngA=
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:cc; bh=HJSl3UPa+iOQsKrloiV70KhE0qp4VT0EwrJEpPQeu5o=; b=aI0T1+iLaeX9ekwK7FPp87HKP43vZ8yLlq5LpMj1gnwieAEBy93NupaYrxLHOkx4t1 NYf3S8Q8RVjL4kyG73wJZQTQ+rs0fgKSzQrRdOHjY5SwmGDWqex4H4wg6tv5ykkpJoU9 JwqGgi5xKS/CdKw3tljNolef7Gn9ZA7Bpph/1k9Z1okJc44w+uypoQgzejNDCjxp23Rp Iule3TtVMdI09H20J6Sk76z0eBUbdib0LXd3lg/HshxPU/t9HqyKKJd4vkU1Sl0l1Cav xX4VCvlv9y8ptw0ODEA7KB6U9H5N3WxWM5d4XG2V/gnimaiYs9+83+MTQfZINcpPYuk7 Wo6g==
X-Gm-Message-State: AMCzsaUv5tpsNsHUVwnR0lm2TMNj/RCwRKB9S1Qxj/fxrv/xnN13LnC1 Jd2lfHJFt02Ui3RzHHIqwYvzHkGICbVpJdjdFP9mFJuP6MU=
X-Google-Smtp-Source: AOwi7QBtIcLYTtTqZtp4sLTA+sFHdKLUsqaSAs6bl9X7wEhYAti/wZKatGOy5qdGHQHNvZPIBRE51M4rI0xiKOsssoA=
X-Received: by 10.80.172.74 with SMTP id w10mr3556021edc.257.1507300730941; Fri, 06 Oct 2017 07:38:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.244.22 with HTTP; Fri, 6 Oct 2017 07:38:50 -0700 (PDT)
In-Reply-To: <CAE+itjcuxbNHrwVq4wcgBC11rX=PwYUsvm3su5Axwko3X1beZw@mail.gmail.com>
References: <149824800169.17379.9099679082498238196@ietfa.amsl.com> <CAE+itjf-1OPtKbADxAVft5+XufAWo3ebbXsamS+Mpt_2cTwzzg@mail.gmail.com> <CAB3683F-D029-4387-86A6-382E61A51ACD@previdi.net> <CAE+itjd1mE7_a+SA=dBhGrJNtcGWt1WTiRddTsEC4vp=COdOLQ@mail.gmail.com> <CAE+itjcuxbNHrwVq4wcgBC11rX=PwYUsvm3su5Axwko3X1beZw@mail.gmail.com>
From: Nandan Saha <nandan@arista.com>
Date: Fri, 06 Oct 2017 20:08:50 +0530
Message-ID: <CAE+itjcJK8TcszPyTto4ZfXz4LHr3Z9i9PbkuePHOWsuufPfzg@mail.gmail.com>
To: stefano previdi <stefano@previdi.net>
Cc: idr@ietf.org
Content-Type: multipart/alternative; boundary="f403045c434ca34242055ae1cc22"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/rXEo9xHfJV_kCv3_sF0KAeWvEVo>
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: Fri, 06 Oct 2017 14:39:01 -0000
Hi, Some more questions / comments 1. Behavior when only one of Color / Remote end point sub-tlv is present in the Tunnel encap tlv. Should the match on either color or remote end point be done for acceptance? For example the color sub-tlv is present, but the remote end point isn't. So the color of the color sub-tlv must match the color in the NLRI. Or should the condition for matching of color / remote end point be done only if both color and remote end point are present. 2. What is the rationale for including remote end point / color sub tlvs in the tunnel encap tlv. The NLRI already has the color and endpoint. Why is there an option to also include a end point and color in the tunnel encap tlv and then have to make sure it matches the NLRI? 3. What should be the behavior when a sub tlv in the tunnel encap attribute is malformed? Should it follow the error handling defined in https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-07#section-11 4. This draft says that the remote end point MAY be present, but draft-ietf-dr-tunnel-encaps seems to imply that it is a MUST. https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-07#section-3.1 says <<< If the Remote Endpoint sub-TLV is malformed, the TLV containing it is also considered to be malformed, and the entire TLV MUST be ignored. >>> Later in section 11, https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-07#section-11 <<< A TLV that does not contain exactly one Remote Endpoint sub-TLV MUST be treated as if it contained a malformed Remote Endpoint sub-TLV. >>> To me this looks like a tunnel end point TLV MUST have a valid remote endpoint sub-tlv. Can this draft make it clear that it is overriding this requirement of draft-idr-tunnel-encaps? 5. Conflicting mandate for malformed NLRI handling. In section 4.2.1 of this draft, the first bullet point's 2nd sentence is <<< 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] >>> Where as the last sentence in section 4.2.1 is <<< A unacceptable SR Policy update that has an invalid NLRI portion MUST trigger a reset of the BGP session >>> Can the draft be updated to simply remove the reference to treat-as-withdraw in the first statement since one cannot withdraw a NLRI if one cannot parse it; and also because it conflicts with the 2nd mandate. Thanks, Nandan On Sat, Sep 30, 2017 at 11:15 AM, Nandan Saha <nandan@arista.com> wrote: > Hello again, > I had a couple of further questions / clarifications. > 1. Binding SID Sub tlv encoding: > Please confirm that the BSID Sub-tlv with length = 6 (4 octet SID) > contains the MPLS label in the lower 20 bits. > Btw, is a Binding SID always a full label and never an index? It's not > mentioned so explicitly in draft-filsfils-spring-segment-routing-policy-01 > > 2. How to treat received weight sub-tlv with weight=0 ? > If we plug weight = 0 in the formula in section 7.1 of the SR TE draft, > https://tools.ietf.org/html/draft-filsfils-spring-segment- > routing-policy-01#section-7.1, then we end up with 0/Sw, so the segment > list won't get any traffic (essentially the segment list isn't present). > To me a weight = 0 seems useless and if we allow it we will get into some > strange corner cases, like if the policy has only one segment list, but its > weight is 0, should it then be treated as an unacceptable policy and > treat-as-withdraw? > It would be simpler to either limit the weight to be > 0 and if 0 is > received treat it as if no weight was received. Does that make sense? > Any thoughts on this? > > Thanks, > Nandan > > On Wed, Jul 19, 2017 at 1:01 PM, Nandan Saha <nandan@arista.com> wrote: > >> Thank you Stefano for clarifying. >> >> On Mon, Jul 17, 2017 at 6:12 PM, stefano previdi <stefano@previdi.net> >> wrote: >> >>> Hi Nandan, >>> >>> sorry for being late. See below. >>> >>> >>> > On Jul 3, 2017, at 2:14 PM, Nandan Saha <nandan@arista.com> wrote: >>> > >>> > 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? >>> >>> no. >>> >>> >>> > 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? >>> >>> >>> there’s no such concept of “summary address” for the endpoint encoding. >>> The draft is going to be updated and the term “summary address” will be >>> removed from the endpoint filed description. Sorry for the confusiuon. >>> >>> >>> > 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. >>> >>> >>> you just have to check the nlri length. >>> >>> >>> > 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.” >>> >>> >>> that is correct. >>> >>> s. >>> >>> >>> > >>> > 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-rout >>> ing-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-r >>> outing-te-policy/ >>> >> >>> >> There are also htmlized versions available at: >>> >> https://tools.ietf.org/html/draft-previdi-idr-segment-routin >>> g-te-policy-07 >>> >> https://datatracker.ietf.org/doc/html/draft-previdi-idr-segm >>> ent-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 >>> > >>> > _______________________________________________ >>> > Idr mailing list >>> > Idr@ietf.org >>> > https://www.ietf.org/mailman/listinfo/idr >>> >>> >> >
- Re: [Idr] I-D Action: draft-previdi-idr-segment-r… Nandan Saha
- [Idr] I-D Action: draft-previdi-idr-segment-routi… internet-drafts
- Re: [Idr] I-D Action: draft-previdi-idr-segment-r… Nandan Saha
- Re: [Idr] I-D Action: draft-previdi-idr-segment-r… stefano previdi
- Re: [Idr] I-D Action: draft-previdi-idr-segment-r… Nandan Saha
- Re: [Idr] I-D Action: draft-previdi-idr-segment-r… Nandan Saha
- Re: [Idr] I-D Action: draft-previdi-idr-segment-r… Eric C Rosen
- Re: [Idr] I-D Action: draft-previdi-idr-segment-r… Robert Raszuk
- Re: [Idr] I-D Action: draft-previdi-idr-segment-r… Eric C Rosen
- Re: [Idr] I-D Action: draft-previdi-idr-segment-r… Robert Raszuk
- Re: [Idr] I-D Action: draft-previdi-idr-segment-r… Eric C Rosen
- Re: [Idr] I-D Action: draft-previdi-idr-segment-r… Nandan Saha
- Re: [Idr] I-D Action: draft-previdi-idr-segment-r… Eric C Rosen
- Re: [Idr] I-D Action: draft-previdi-idr-segment-r… Gaurav Dawra (gdawra)