Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15

Alvaro Retana <aretana.ietf@gmail.com> Tue, 04 August 2020 20:01 UTC

Return-Path: <aretana.ietf@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 D482F3A1168; Tue, 4 Aug 2020 13:01:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 0TJKgWdK08WC; Tue, 4 Aug 2020 13:01:50 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 EC4993A1162; Tue, 4 Aug 2020 13:01:49 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id a14so38573143wra.5; Tue, 04 Aug 2020 13:01:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=ykmqHTapJRueQFfoSSCB7v4K/g0G+WmUdgByiCzDQg4=; b=j1apdBX7BFgLb8iNjzfzj9j3tJic/BuNXq11pAkcUwlnZUBAi96OCoLXf39KbYrldn AKGNXEl8piEXNfA7n9+0dS/Z6Zio2BL7u3Vo3DRtLV2Yk77+qYyYgO5QxSXSzu5Zewny 6hWJPmMSN5dgF7ZtL9Jb04mcaDe8cV6PtzfbPXrKC+egIhpWndfQnugYTmYBXlsbaW8Y Ktog4XK7luPiC2KPgefqDAsPqqD5zHYRLb9KCcheyfEjlJL0JSsQt1EM66Mb4FWaw+QK h2efjS+DxKl5vVqFFyaKYgiJBMbgT6CjuLjrfy21JGY1ewrvnm2ztqEIyZ1rZeJmYQAl Pc+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=ykmqHTapJRueQFfoSSCB7v4K/g0G+WmUdgByiCzDQg4=; b=PISKGUCsHl4kBbr4I0baMUPzt1hmifqXqRD11KR0ERHTud95MROVeGVnk9Z4AllzUK KagRfpT5V6GSJDARIuvAgjhp3aH4zyyHmh3IJ5/Aza5V6hg2SYYT6eY8fLuymBAhy43X fHQXOrTLkzbRdzwCjk67av3xo1TQM6YMeNSUlLsuZSaJHaUTq08vEsnlci1DuxLgKPK8 Ry9wN8XY/4nSh0sGyhcrN6QRPdSVa/XHSxtzlcUYrFoJ7+S5S1Kj0KiiSww5nMzIjrBw gVfC2N0eZWv10ZTcT6hGziVhmsb/0UBAjpW+UCxH0742PnNboigMabC1eaKkYR2IUhNl nhzA==
X-Gm-Message-State: AOAM530yGx3EbgzFpIKt1qmGmoVKftLTlCYAkNQV8fjnsGENJLVn6Lmz kbxXOoauMoN86qg1e7H656tD7yyV4Ie7HN6ukVU=
X-Google-Smtp-Source: ABdhPJy6BcU+40hcZT3dWnte1XcH9eLxpYyWJ1jVxjenedZF9CuO1rDr12WfICJpbhQLunto/4ZjTQpNc2WywW1IieU=
X-Received: by 2002:adf:b353:: with SMTP id k19mr4152921wrd.159.1596571307911; Tue, 04 Aug 2020 13:01:47 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 4 Aug 2020 15:01:46 -0500
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <4A8D5D53-B3D2-4ACC-876C-F70D2B2EDC46@juniper.net>
References: <CAMMESsw09LGWWhqyJ_0=jRimUN+_UuCjaXHCdqF9zkpaxSQgVQ@mail.gmail.com> <4A8D5D53-B3D2-4ACC-876C-F70D2B2EDC46@juniper.net>
MIME-Version: 1.0
Date: Tue, 4 Aug 2020 15:01:46 -0500
Message-ID: <CAMMESszqiNNoGpW_=39Jo5UNckFFrWU8=zTk5O2NGTFwnr7=QQ@mail.gmail.com>
To: John Scudder <jgs@juniper.net>
Cc: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf. org" <idr@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/QXFYyGEGZZE9D1JdmWRbooU5MQs>
Subject: Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15
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, 04 Aug 2020 20:01:52 -0000

On July 16, 2020 at 8:54:11 PM, John Scudder wrote:


John:

Hi!


> (And note that I’m replying as a co-author now.)

Thanks for taking the lead on this document!


...
> I found a number of overlooked points as I worked through this reply, so
> we’ve issued -17 to correct them. This reply is with respect to that
> version.

I made some comments/replies below.  And I also made some comments
in-line in -17 (sent separately); in some cases that seemed clearer.


I still have issues with "belonging" and reachability...specially in
the case of multiple routing tables.  The Scoping section mentions
that "it is intended that the Tunnel Encapsulation attribute be used
only within a well-defined scope".  This makes me think: if the scope
is well-defined (specially in the case of common administration), then
some of the checks ("belonging", for example) could be easily avoided
by configuration (policy)...and others (reachability) would be easier
to constrain.  As I read through the document I can't help but think
of the general case -- in part because of the transitivity, but also
because the intended scope is not called out until much later.
Consider moving the Scoping section closer to the start...and then
defining some of the behavior in that context.  The intended use is
just that, "intended", so the general operation will still have to be
considered, but the normative pieces may become easier to specify.

[I hope that made sense...]


Thanks!

Alvaro.


...
> We added 5566 and 5640 to the list of obsoleted RFCs, along with an
> explanation.

[major] The IANA assignments made for those RFCs need to be declared
obsolete in the IANA Considerations section.


[major] The reference to rfc5640 should be Informative.


...
> > (4) Use Cases
> >
> > rfc5512 gave an overview of the use case (mostly intra-AS), but this
> > document doesn't mention use cases either as an introduction to the
> > problem being solved or in the form of Operational Considerations.
> > Sections 9 and 10 would be a good start for that type of section, but
> > having a general description of the problem upfront (in the
> > Introduction maybe) would be ideal. Again, because this document
> > Obsoletes rfc5512, then we can't really rely on the information there.
> > I'm looking for a few paragraphs, mostly directed at readers that may
> > not be familiar with rfc5512 and the potential applications.
>
> Added Section 1.4, "Use Case for The Tunnel Encapsulation Attribute”.

[] Consider moving this new section towards the front so the
motivation is before the text about the changes.

[] I also put some inline comments in -17.



> > (5) When does an IP address "belong" to an AS?
...
> This is completely redone. See Section 3.1.1, “Validating the Address
> Field”.

[] The text is now better...but I think some work is still needed in
terms of clarity (I put comments inline in -17).


...
> > [minor] rfc4271 consistency: s/best path/best route/g

[] There are a couple of these remaining.


...
> > [nit] s/encapsulation sub-TLV/Encapsulation sub-TLV/g

[] Some of these are still in the text.


...
> > 1054 4.2. Router's MAC Extended Community

[] We've been talking about this section in a separate message...


...
> > 1080 5. Semantics and Usage of the Tunnel Encapsulation attribute
...
> > 1135 * The tunnel is specified in a TLV whose Tunnel Endpoint sub-TLV
> > 1136 identifies an IP address that is reachable.
> >
> > [major] How is reachability determined? Where (which table) should
> > the address be looked up in? In the sequence above, the destination
> > address of P and the address of the endpoint may be resolvable in
> > different tables...
>
> Now says:
>
> * The tunnel is specified in a TLV whose Tunnel Egress Endpoint
> sub-TLV identifies an IP address that is reachable. This IP
> address may be reachable via one or more forwarding tables.
> Local policy may determine these forwarding tables and is
> outside the scope of this document. The reachability condition
> is evaluated as per [RFC4271].

The very next sentence says: "Then router R MUST send packet P through
one of the feasible tunnels..."   This creates a big problem: the
normative action depends on the feasibility of the tunnel, which
depends on the reachability of the IP address -- but the mechanism to
verify that is out of scope. :-(

How does R know that it is doing the right thing?

> > [BTW, please also take a look at
> > draft-ietf-idr-bgp-bestpath-selection-criteria, which I think tries to
> > define a related, if not the same, concept.]

I find myself in a quandary:

- On one hand, the WG has already recognized that clarifying the
selection criteria is important, specially in the case of multiple
possible tables.  It did this by requesting publication of
draft-ietf-idr-bgp-bestpath-selection-criteria.  Ideally we could just
reference that document here...but if it doesn't progress then we're
stuck with a Normative reference...

- OTOH, we can pretend that rfc4271 is clear -- or at least that a
document will eventually Update it...and not mention what that
document may be...while knowing that rfc4271 doesn't provide any
guidance and thus leaving the specification incomplete...

<sigh>


draft-ietf-idr-bgp-bestpath-selection-criteria also talks about
policy...but provides no specifics.  Can you at least provide
information about possible policies and their effect?



...
> > 1198 If a Tunnel Encapsulation attribute specifies several tunnels, the
> > 1199 way in which a router chooses which one to use is a matter of policy,
> > 1200 subject to the following constraint: if a router can determine that a
> > 1201 given tunnel is not functional, it MUST NOT use that tunnel. In
> > 1202 particular, if the tunnel is identified in a TLV that has a Tunnel
> > 1203 Endpoint sub-TLV, and if the IP address specified in the sub-TLV is
> > 1204 not reachable from router R, then the tunnel MUST be considered non-
> > 1205 functional. Other means of determining whether a given tunnel is
> > 1206 functional MAY be used; specification of such means is outside the
> > 1207 scope of this specification. Of course, if a non-functional tunnel
> > 1208 later becomes functional, router R SHOULD reevaluate its choice of
> > 1209 tunnels.
> >
> > [major] "not functional" What does that mean? How can that be
> > determined? Is a "functional" tunnel the same as "feasible tunnel"
> > (from earlier in this section)? If so, please use consistent
> > terminology.
>
> Now says:
>
> If a Tunnel Encapsulation attribute specifies several tunnels, the
> way in which a router chooses which one to use is a matter of policy,
> In addition to the reachability to the address of the egress endpoint
> of the tunnel, other policy factors MAY be used to determine the
> feasibility of the tunnel. The policy factors are beyond the scope
> of this document.

[major] This same section lists 3 conditions for feasibility...and a
required action (MUST...) following.  This new text adds optional
extra conditions to the feasibility, creating a Normative
inconsistency.

Maybe "Then router R MUST send packet P..." can be softened (SHOULD),
and the information in this paragraph can be moved closer to better
position the exception.  Note that the paragraph immediately after
"Then router R MUST send packet P..." already talks about local policy
to select between tunnels, so there's some redundancy that should be
eliminated.


> > [major] The paragraph specifies the same thing as about 6-7 paragraphs
> > above (but calling it feasible). Please specify things only once.
> > IOW, this paragraph seems redundant (if functional and feasible are in
> > fact the same thing).
>
> I think this is resolved now.

The difference is the use of normative language...



...
> > 1459 9. Applicability Restrictions
...

I appreciate the changes in this section...  Everything you wrote in
the document and here is true: there's no substitute for good design,
and anything can go wrong.  I'm thinking about the overall value of
this section...I'm ok leaving it, it just feels like it doesn't say
much that is not covered in the Security Considerations (for example).