Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

Adam Chappell <adam.chappell@gmail.com> Fri, 21 October 2016 12:36 UTC

Return-Path: <adam.chappell@gmail.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 A10D71295D9 for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 05:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.709
X-Spam-Level:
X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ypxM-GVj6fmW for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 05:36:41 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 14EB3129420 for <idr@ietf.org>; Fri, 21 Oct 2016 05:36:41 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id 139so222591548itm.1 for <idr@ietf.org>; Fri, 21 Oct 2016 05:36:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ktlMaKFL6LpesLHmgM/ti2NI35Pxg+WayeZLYqFo19c=; b=0wZIIs4fZigEUucGnq0b4jG0mKCKkCgxJ6ybQc5abPzhoAUE0SsnY+Nb8XrhEZ0Yz6 ZBzmKX1JZixVsG/OvPCv7DvCBENkDdy060oxkbBuEUbsYqhiaNlEP4y0M+DSAm6QTC7i QnfJyTjTzpGu45GJ9z3HCrWBswxMoy9V9nAGtVYKef+7zi4Th/4sOYjHTG0dllO7Ye3o 0IYzznpolPSlZ6RwefIHV0mhSqLDjY/f4ogcLQqvcOUwxtIygiBs+XesVwL+kUZAqrPV 57KyfF/N5CGHjmCg7giBuDahK3W3wM5KhdDUNd68+k6bdsHkP0JV3+slTcLMrRzJR8sG TPhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ktlMaKFL6LpesLHmgM/ti2NI35Pxg+WayeZLYqFo19c=; b=cWERUBqjJWdSj6PMQeFJAuk8KKCtXkUSx6UmREAIL/p2IIvPx77dD52KXjyZ0kW3h+ UJGChB2rzM0v6WF3WT7aFMrml0cZoPv/20XgkWtzJXgAi4GY8yBtnPezHeSckXfsunHg drvY4Yh6l+x0uEDsHOv9qC6mUKKeA41D+UwGW1WiQ9DNaf52z3TXxKfRgfkL/tesxvBR Gw5crBVHv6frbQkNF+6bBwX7aZWiOsei1yAHRnIBN/6eYPNZQqrB61ESlGuREjdu7USa ELzOj6UrltmhIh5AgH/rRi9FfP56fcNWmwKZMPnpsmaiGOOW50LvTfo/b7c045WIpWII pjwg==
X-Gm-Message-State: ABUngvfp4I4gYjF4AqM9KuERGfsrIEKmrT0X/EZV9d8zyvLDuZHY36LJ8AxKP0aOhLETF5gtOlKOzK0DI1z1Rw==
X-Received: by 10.107.133.13 with SMTP id h13mr761980iod.148.1477053400302; Fri, 21 Oct 2016 05:36:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.14.212 with HTTP; Fri, 21 Oct 2016 05:36:38 -0700 (PDT)
In-Reply-To: <adb00bcd7b8e45db857eae7019c646fc@XCH-ALN-014.cisco.com>
References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <adb00bcd7b8e45db857eae7019c646fc@XCH-ALN-014.cisco.com>
From: Adam Chappell <adam.chappell@gmail.com>
Date: Fri, 21 Oct 2016 14:36:38 +0200
Message-ID: <CAF3K5KvWM+NYqDQeaO89YrV5giptj+S4VheukdjOQXMLWg7Vxw@mail.gmail.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
Content-Type: multipart/alternative; boundary="001a113e88d03d4af1053f5f4b0b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/-vdz6EOm0x_1wBbon6BSRzFIzJQ>
Cc: heasley <heas@shrubbery.net>, IETF IDR WG <idr@ietf.org>, Sue Hares <shares@ndzh.com>
Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Oct 2016 12:36:43 -0000

Hi Jakob.

I must confess I find the original text slightly simpler, and I can't read
obvious benefit from the replacement text, because:

- Large Community attributes are tags on routes. They are going to go
exactly where advertisement policy says they should go, so not much point
calling out the case where they are received by multiple ASes or otherwise.

- If we think it's rude to use private ASNs or steal Job's ASN, it's an
operational matter identical to the one faced today.

- Propagation zone of LC attributes is influenceable by any peers in the
path; but any savvy operator is unwise to rely on behaviour associated with
unfettered or un-manipulated attributes. (Already covered with adequate
wording in sec. 7 I think).

I think the new statement might actually be back-to-front in what it says.
It seems to say that we should use the ASN that defined the LD1 and LD2
parts that we wish to make use of, which isn't helpful. We probably agree
that the ASN referenced in the GA field has ultimate authority on the
definition of semantics and is probably the only AS one can practically
rely on to effect such semantics. So if it helps, perhaps state that?

-- Adam.





On 21 October 2016 at 00:13, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:

> In addition, to deal with the values for the GA field, we will replace
>
>    The Global Administrator field is intended to allow different
>    Autonomous Systems to define Large BGP Communities without collision.
>
> with
>
>   A Large Community that
>   is intended to be sent to multiple ASes SHOULD contain an ASN
>   in the Global Administrator field. The ASN SHOULD be one that
>   is assigned to the entity
>   that defines the meaning of the rest of the Large Community.
>   This allows a route to carry multiple Large Communities, the meaning
>   of each being defined by different independent entities.
>
> Thanks,
> Jakob.
>
>
> > -----Original Message-----
> > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders
> > Sent: Thursday, October 20, 2016 3:00 PM
> > To: Jeffrey Haas <jhaas@pfrc.org>
> > Cc: heasley <heas@shrubbery.net>; IETF IDR WG <idr@ietf.org>; Sue Hares
> <shares@ndzh.com>
> > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt
> (10/17/2016 to 10/31/2016)
> >
> > Hi working group,
> >
> > On Tue, Oct 18, 2016 at 04:38:00PM -0400, Jeffrey Haas wrote:
> > >
> > > > On Oct 18, 2016, at 3:15 PM, Job Snijders <job@ntt.net> wrote:
> > > >
> > > >>
> > > >> Part of the idea behind reserving 65535:*:* was to reserve a space
> that
> > > >> could later be used for well-knowns, if that was desired - but to
> not
> > > >> spend time now arguing about details of what well-knowns are
> necessary.
> > > >>
> > > >> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs.
> > > >
> > > > Jeff argues that a justification should be added. Maybe someone can
> > > > pitch in one or two sentences that explain why these are reserved?
> > >
> > > That's certainly part of it.  While I think many people can see the
> > > reason why you might want to do such a reservation, to do so you
> > > should have a practical reason in the document.
> > >
> > > For the 65535:*:* case, for symmetry with RFC 1997, you'd probably
> > > want to note that if it's used for that symmetry that either the
> > > existing well known community registry is used at IANA or that a new
> > > one would need to be created.  Alternatively, you just say the work is
> > > expected and defer to a future document.
> > >
> > > Note by doing this, you're setting up some expectations about
> > > translation of communities from one space to another.  FWIW, I don't
> > > recommend this and simply suggest that you recommend *not* using these
> > > for common use in case someone decides that they want to do so.  I
> > > know your organization and others such as Deutsche Telecom have some
> > > thoughts about what translation infrastructure might look like, and
> > > such mechanisms would have impact.
> > >
> > > With regard to the 0: and max-uint32: cases, after dealing with the
> > > headaches associated with helping with documents such as the as0 and
> > > RFC 7300 and putting in some restrictions in the configuration...
> > > followed by having to take them away, I'm very reluctant to put in
> > > anything beyond "we think it's a bad idea to use these, so pretty
> > > please don't"
> >
> > After some off-list back and forth with John Heasley, Adam Chappell,
> > Jeff Haas and the authors, we came up with the following text to address
> > the above raised concern.
> >
> > This will be part of -04.
> >
> > """"
> > 5.  Reserved Large BGP Community values
> >
> >    The following Global Administrator values are reserved: 0 (the first
> >    ASN) [RFC7607], 65535 (UINT_MAX) and 4294967295 (the last ASN)
> >    [RFC7300].  Operators SHOULD NOT use these Global Administrator
> >    values.
> >
> >    Although this document does not define any Special-Use Large BGP
> >    Communities, the Global Administrator values specified above could be
> >    used if there is a future need for them.
> > """
> >
> > A preview of the -03 / -04 diff is available here:
> >
> > https://htmlpreview.github.io/?https://github.com/large-bgp-
> communities/large-bgp-communities/blob/master/draft-
> > ietf-idr-large-community-04-from-3.diff.html
> >
> > Kind regards,
> >
> > Job
> >
> > _______________________________________________
> > 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
>



-- 

-- Adam.