From nobody Fri Sep 18 04:54:39 2020 Return-Path: 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 5FE063A0544; Fri, 18 Sep 2020 04:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 9xPSQYaDwj30; Fri, 18 Sep 2020 04:54:36 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 9CEA73A0475; Fri, 18 Sep 2020 04:54:35 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.25.170.45; From: "Susan Hares" To: "'Alvaro Retana'" , "'John Scudder'" Cc: , "'idr@ietf. org'" , References: <4A8D5D53-B3D2-4ACC-876C-F70D2B2EDC46@juniper.net> <612D7795-D53A-498E-BB5E-F231A32954F2@juniper.net> In-Reply-To: Date: Fri, 18 Sep 2020 07:54:29 -0400 Message-ID: <006701d68db2$7786b3e0$66941ba0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJH7ekTdpypUgfVEnnZV4D7E+BXwwLfcsRDArs4M+YC6px+LwMmwv8GqC4orAA= Content-Language: en-us X-Antivirus: AVG (VPS 200918-0, 09/18/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2020 11:54:38 -0000 John and Alvaro:=20 Do you want me to do a complete new shepherd review at this point? =20 Cheers, Sue=20 -----Original Message----- From: Alvaro Retana [mailto:aretana.ietf@gmail.com]=20 Sent: Thursday, September 17, 2020 6:18 PM To: John Scudder Cc: idr-chairs@ietf.org; idr@ietf. org; = draft-ietf-idr-tunnel-encaps@ietf.org Subject: Re: AD Review of draft-ietf-idr-tunnel-encaps-15 On September 11, 2020 at 11:25:31 AM, John Scudder wrote: John: Hi! Just a couple of comments... Just one actionable change related to the = reachability issue: you're right, we should move on. 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. > > Is =E2=80=9Cobsolete=E2=80=9D an IANA thing? I=E2=80=99ve added a = subsection to the IANA=20 > section as requested, but asked them to mark the code points as = =E2=80=9Cdeprecated=E2=80=9D. Yes, "obsolete" is an IANA thing. rfc8126: "Specific entries in a = registry can be marked as "obsolete" (no longer in use) or "deprecated" = (use is not recommended)." You used both terms in =C2=A713.1 to refer to the code points. You're = right, deprecating is the right action, but IANA may be confused by the = use of both. This is a minor point, so we can wait for them to ask = about it. :-) ... > >>> 1054 4.2. Router's MAC Extended Community > > > > [] We've been talking about this section in a separate message... > > OK. To loop the WG in on the conclusion of that, it appears that=20 > draft-ietf-bess-evpn-inter-subnet-forwarding only allows a single=20 > Router=E2=80=99s MAC (authors have been asked to clarify) so assuming = that=E2=80=99s=20 > right, we must pick one or the other if it=E2=80=99s encoded twice in = two ways=20 > with different values. In -18 I=E2=80=99ve changed the text to say = =E2=80=9Cuse the=20 > EC=E2=80=9D instead of the former =E2=80=9Cuse the sub-TLV=E2=80=9D. FYI... I have a DISCUSS on draft-ietf-bess-evpn-inter-subnet-forwarding precisely due to the lack of sync with this document. I hope that the = authors provide an answer and align with the changes here. > >>> 1080 5. Semantics and Usage of the Tunnel Encapsulation attribute ... > All of this is true. Basically, we can either hang progress of this=20 > document up for a potentially long time waiting for something that may = > never come: a detailed specification of exactly when a route is, and=20 > isn=E2=80=99t, resolvable, or we can admit it=E2=80=99s an imperfect = world and move=20 > forward. I will observe that despite 4271=E2=80=99s lack of = prescriptiveness,=20 > somehow we have many interoperable implementations of BGP. I suspect=20 > this is because when an implementor looks at route resolution, = it=E2=80=99s a=20 > little like Justice Potter Stewart looking at other material: = =E2=80=9C[I=20 > can=E2=80=99t define it but] I know it when I see it.=E2=80=9D > > I tried to make the paragraph clearer by adding a final clause. The=20 > last sentence now reads, "The reachability condition is evaluated as=20 > per [RFC4271], but the essence is that if the router could forward a=20 > packet addressed to the IP address, the IP address is = "reachable=E2=80=9D.=E2=80=9D We=20 > could absolutely pick this short summary to shreds if we chose = =E2=80=94 see=20 > above. It=E2=80=99s not meant to be prescriptive, only descriptive. Ok. Let's go with an "intermediate" approach, so that we don't try to say = too much, but (hopefully) say enough: NEW> * The tunnel is specified in a TLV whose Tunnel Egress Endpoint = sub-TLV identifies an IP address that is reachable. The reachability = condition is evaluated as per [RFC4271]. If the IP address is reachable via more than one forwarding table, local policy is used to determine which table to use.