Re: [Lsr] Fwd: New Version Notification for draft-ietf-ospf-ospfv2-hbit-09.txt

Alvaro Retana <aretana.ietf@gmail.com> Fri, 20 September 2019 20:11 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7C11208BF for <lsr@ietfa.amsl.com>; Fri, 20 Sep 2019 13:11:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Level:
X-Spam-Status: No, score=-0.997 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 hvjmMkbNO5vu for <lsr@ietfa.amsl.com>; Fri, 20 Sep 2019 13:11:38 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 B14B2120099 for <lsr@ietf.org>; Fri, 20 Sep 2019 13:11:37 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id v38so7561362edm.7 for <lsr@ietf.org>; Fri, 20 Sep 2019 13:11:37 -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; bh=3JqV5wy5PcgVAJhIomNJjBvys4sz7OCFkHHLIWy0MRA=; b=RP3iN+5xiBvcrSCBN2DFHvEbCUPDNc5q8DySc4iMJNYYgQYjUHs8rodBAG6ufCmcFG eZqGpRRk1Zlv0FguQoWJLbvfOQzDj5jF9izsoBaRGxqY06qlqqa/3kM9PJoL2bo/cwlt sns/u6Oj4N09RY9tblqd9JQtqRB6xUOkFxXRNr/29XZVm5oEtMtU/Rm1BzCQo1nsKYkE jTIPyW0Y2/Cygr5Z0o72TLNwklsVW9qBCPyHJxcVpnIfeflGyWXbsnYXhhcnLMOnYWZT LcD3Ka0gDayRkUuCRL6Ue1J8n18hnQGwwPDlr2tv1OJpjCZBO4AJn6yQ0kL2XiZ8sNNy AkOA==
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; bh=3JqV5wy5PcgVAJhIomNJjBvys4sz7OCFkHHLIWy0MRA=; b=M9sK05oV5LxJtprrKfXpk0nmaK/g2OwPtc2X8q8+hqdmX15G+4gkTZLReCTctBTrdZ zWMQXrY4caeN/dUw4FeUPlABMjai+nN1mDkY+EREGCt9IssxjtGUx2dFW40p9tQ6mg65 kVcHK664IJJ+9CzeFC4ukQR74xbMXVAZKsG2MCIfxLeWWF9Q22xdYy4V0hS/JGZzEXa5 vAL/TZIGZPF2GfLoiKVed8aUQ32OsFWFR1uYz8r4TQQ0aJgLUINVSOHJL6KUEKHB1T+B 92Ayx9/pg9nc3FYCilV+KwqpRY4xJ/cyGNK4VZ+CnvzwIDlmWZu3ZfcgPWkQk7q8PeDq LQrQ==
X-Gm-Message-State: APjAAAW8PuU6RhgPHAGKYVuiTugH2MuQ2Y4UhZPmPEPp5JDIf7vBLQoj naQWYIXVYWfqvxFOE0dg2cNlOlvx4V99ty/rqb4=
X-Google-Smtp-Source: APXvYqxTahEW3Zz1r0URh5wzjtObNd2qXJuvIZHHaleI9s3QjObd3sTP8f00ttdWNdeLo3+z0xhV1rHmcJXIkxS7qKI=
X-Received: by 2002:a50:e719:: with SMTP id a25mr23990988edn.258.1569010295995; Fri, 20 Sep 2019 13:11:35 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 20 Sep 2019 13:11:35 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CAG-CQxo9kMWMXxiDDa4ZSm7ADVS+aPLzRuehDBf1W4jYjGxx2w@mail.gmail.com>
References: <156843700176.32063.1393096099535829916.idtracker@ietfa.amsl.com> <CAG-CQxo9kMWMXxiDDa4ZSm7ADVS+aPLzRuehDBf1W4jYjGxx2w@mail.gmail.com> <CAG-CQxo9kMWMXxiDDa4ZSm7ADVS+aPLzRuehDBf1W4jYjGxx2w@mail.gmail.com>
MIME-Version: 1.0
Date: Fri, 20 Sep 2019 13:11:35 -0700
Message-ID: <CAMMESsyqP4w3m6E_CFXfRvAO99ihXJuEzTL+3b3fT=s051LqAw@mail.gmail.com>
To: Padma Pillay-Esnault <padma.ietf@gmail.com>
Cc: Yingzhen Qu <yingzhen.ietf@gmail.com>, manbhard@cisco.com, "Acee Lindem (acee)" <acee@cisco.com>, Keyur Patel <keyur@arrcus.com>, "Serpil Bayraktar (serpil)" <serpil@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000578264059301ad76"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/zs4cfS9z7vXbK_sNHku4-66nEQg>
Subject: Re: [Lsr] Fwd: New Version Notification for draft-ietf-ospf-ospfv2-hbit-09.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Sep 2019 20:11:40 -0000

On September 14, 2019 at 1:12:51 AM, Padma Pillay-Esnault (
padma.ietf@gmail.com) wrote:

FYI  the draft is posted.


Padma:

Hi!

Thanks for the revision!

I went through the changes and have some mostly-editorial nits/minor
comments (see below, based on -09).  There are a couple of major items,
introduced by the new text, that should be addressed before moving on:

(1) §3 (last paragraph) introduces different behavior for permanently vs
temporarily acting as a host.  From the point of view of the H-bit, what is
the difference?  It seems to me that in both cases the H-bit would be set:
the router would be acting as a host NOW.  How long it keeps the H-bit set
seems to be the distinction between permanent and temporary...but the
behavior should not change because of that.  IOW, the specification of what
happens when the H-bit is set should be singular -- you may be able to
soften some of the MUSTs (to SHOULD) if the exceptions are justified other
than using time.

(2) The last bullet in §5...adds the fact that support for the H-bit can be
verified from the RI LSA *or* the router-LSA itself.  That fact is not
considered before: if the RI LSA hasn't been received (or doesn't include
the new capability), but the router-LSA does have the H-bit set, should it
be assumed that the router supports the capability?  Because this option
hasn't been mentioned before (requiring the capability to be advertised), I
think we should simply eliminate that last bullet.

Thanks!

Alvaro.

[Line numbers from idnits.]

...
14 Abstract

16   The Open Shortest Path First Version 2 (OSPFv2) does not have a
17   mechanism for a node to repel transit traffic if it is on the
18   shortest path.  This document assigns a new bit (Host-bit) in the
19   OSPF Router-LSA bit registry and in the OSPF Router Informational
20   Capability Bits Registry that enables a host router to advertise that
21   it is a non-transit router.  It also describes the changes needed to
22   support the Host-bit in the domain.  In addition, this document
23   updates OSPF Stub Router Advertisement (RFC6987) to advertise for
24   type-2 External and NSSA LSAs with a high cost in order to repel
25   traffic effectively.

[minor] s/This document assigns a new bit (Host-bit) in the OSPF Router-LSA
bit registry and in the OSPF Router Informational Capability Bits Registry
that enables a host router to advertise that it is a non-transit
router./This document defines a new bit (Host-bit) that enables a router to
advertise that it is a non-transit router."

[nit] s/to advertise for type-2/to advertise type-2

[minor] s/OSPF Stub Router Advertisement (RFC6987)/RFC 6987


...
75 1.  Introduction
...
105   This document describes the Host-bit (H-Bit)functionality that
106   prevents other OSPFv2 routers from using the router for transit
107   traffic in OSPFv2 routing domains.  This document defines the Host-
108   bit in the OSPFv2 Router Properties Registry and if the host-bit is
109   set then the calculation of the shortest-path tree for an area, as
110   described in section 16.1 of [RFC2328], is modified by including a
111   new check to verify that transit vertices DO NOT have the host-bit
112   set.

[nit] s/(H-Bit)functionality/(H-Bit) functionality

[minor] s/This document defines the Host-bit in the OSPFv2 Router
Properties Registry and if the host-bit is set then the calculation of the
shortest-path tree...transit vertices DO NOT have the host-bit set./If the
host-bit is set then the calculation of the shortest-path tree...transit
vertices DO NOT have the host-bit set (see Section 4).

[nit] Please be consistent: Host-bit, host-bit, H-bit...

[minor] Add some text here (with a forward reference to Section 6) about
the Update to rfc6987.

...
122 3.  Host-bit Support

124   This document defines a new router-LSA bit known as the Host Bit or
125   the H-bit.  An OSPFv2 router advertising a router-LSA with the H-bit
126   set indicates that it MUST NOT be used as a transit router (see
127   section 4) by other OSPFv2 routers in the area supporting the
128   functionality.

[nit] s/section 4/Section 4

130   If the host-bit is NOT set routers MUST act transit routers as
131   described in [RFC2328] ensuring backward compatibility.

[minor] I don't think there's really Normative value in using MUST to say:
"behave as always".  I would even go as far as removing the sentence...but
if you want to keep it, here's a suggestion...

NEW (suggestion)>
   If the H-bit is not set then backwards compatibility is achieved as the
   behavior will be the same as in [RFC2328].


...
166                          Host Bit in Router-LSA

168                 0 1 2 3 4 5 6 7
169                 +-+-+-+-+-+-+-+-+
170                 |H|0|0|N|W|V|E|B|
171                 +-+-+-+-+-+-+-+-+

173                                 Host Bit

[minor] Label this figure too.

175   Bit H is the high-order bit of the OSPF as shown above.  When set, an
176   OSPFv2 router is a Host (non-transit) router and is incapable of
177   forwarding transit traffic.  In this mode, the other OSPFv2 routers
178   in the area MUST NOT use the host router for transit traffic, but use
179   the host router only for its local destinations.

[minor] "Bit H is the high-order bit of the OSPF as shown above."  Of the
OSPF what??

[minor] s/but use the host router only for its local destinations./but may
send traffic to its local destinations.

181   An OSPFv2 router originating a router-LSA with the H-bit set MUST
182   advertise all its router links with a link cost of MaxLinkMetric
183   [RFC6987].  This is to increase the applicability of the H-bit to
184   partial deployments where it is the responsibility of the operator to
185   ensure that OSPFv2 routers not supporting the H-bit do not install
186   routes causing routing loops.

[minor] s/advertise all its router links/advertise all its non-stub links

[minor] I see that §5 has the same text, and it is explicitly talking about
partial deployments.  Let's take the second sentence out (the explanation
will come later).

[nit] s/routing loop/forwarding loop/g


188   When the H-bit is set, an Area Border Router (ABR) MUST advertise the
189   same H-bit setting in its self-originated router-LSAs for all
190   attached areas.  The consistency of the setting will prevent inter-
191   area traffic transiting through the router by suppressing
192   advertisement of prefixes from other routers in the area in its
193   summary LSAs.  Only IPv4 prefixes associated with its local
194   interfaces MUST be advertised in summary LSAs to provide reachability
195   to end hosts attached behind a router with the H-bit set.

[nit] s/summary LSAs/summary-LSAs

[nit] s/attached behind a router/attached to a router

197   When the H-bit is set the host router cannot act as an AS Boundary
198   Router (ASBR).  Indeed, ASBR are transit routers to prefixes that are
199   typically imported through redistribution of prefixes of other
200   routing protocols.  Therefore, non-local IPv4 prefixes, e.g., those
201   exported from other routing protocols, MUST NOT be advertised in AS-
202   external-LSAs for routers acting permanently as a host.  However, in
203   use cases such as an overloaded router or a router being gracefully
204   isolated, these routers are only temporarily acting as host routers
205   and therefore SHOULD continue to advertise their External LSAs but
206   ensure that they do not attract traffic.  In addition to the
207   procedure described above, temporary host routers advertising type
208   2-metric External LSAs MUST set the metrics to LSInfinity to repel
209   traffic.(see Section 6 of this document).

[minor] s/exported/imported

[minor] s/MUST NOT be advertised in AS-external-LSAs for routers acting
permanently as a host./MUST NOT be advertised in AS-external-LSAs if the
H-bit is set.

[major] The new text introduces different behavior for permanently vs
temporarily acting as a host.  From the point of view of the H-bit, what is
the difference?  It seems to me that in both cases the H-bit would be set:
the router would be acting as a host NOW.  How long it keeps the H-bit set
seems to be the distinction between permanent and temporary...but the
behavior should not change because of that.  IOW, the specification of what
happens when the H-bit is set should be singular -- you may be able to
soften some of the MUSTs (to SHOULD) if the exceptions are justified other
than using time.


...
237 5.  Auto Discovery and Backward Compatibility

239   To avoid the possibility of any routing loops due to partial
240   deployment, this document defines a OSPF Router Information (RI) LSA
241   [RFC7770] with and an area flooding scope and a new bit assigned in
242   the OSPF Router Informational Capability Bits Registry.  Bit:

[nit] s/avoid/reduce

[minor] s/defines a OSPF Router Information (RI) LSA [RFC7770] with and an
area flooding scope and a new bit assigned in the OSPF Router Informational
Capability Bits Registry. Bit:/defines an OSPF Router Information (RI) LSA
[RFC7770] capability.  The RI LSA MUST be area-scoped.

244                  Bit       Capabilities

246                  7         Host Router Support capability

[nit] Name this table.

...
253   In normal operations, there is no guarantee that the RI LSA will
254   reach all routers in an area in a timely manner that may result in
255   rooting loops in partial deployments.  For example, in a new router
256   joins an area which previous had only H-bit capable routers with
257   H-bit set then it may take some time for the RI to propagate to all
258   routers.

[nit] s/operations,/operation

[nit] s/manner that may result in rooting loops/manner, which may result in
forwarding loops

[nit] s/in a new router/if a new router

[nit] s/which previous had only H-bit capable routers with H-bit/which
previously had only H-bit capable routers with the H-bit


...
268   o  All routers, with the H-bit set, MUST advertise all of the
269      router's non-local links with a metric equal to MaxLinkMetric in
270      its LSAs in order to avoid OSPFv2 (unless last resort) routers not
271      supporting the H-bit from attempting to use it for transit
272      traffic.

[minor] s/router's non-local links/router's non-stub links

[minor] s/MaxLinkMetric/MaxLinkMetric [RFC6987]

274   o  All routers supporting H-Bit MUST check all the RI LSAs of nodes
275      in the area before actively running the modified SPF to account
276      for the H-bit in order to verify that all routers are in routing
277      capability.  If any router does not have the H-Bit support then
278      all routers in the areas MUST run the normal SPF.

[minor] s/If any router does not have the H-Bit support then all routers in
the areas MUST run the normal SPF./If any router does not advertise the
Host Router Support capability then the SPF Modifications (Section 4) MUST
NOT be used in the area.

280   o  Any router not supporting the H-bit capability is detected (by
281      examination of RI- LSA or RTR LSA in the area database) then all
282      routers in the area MUST revert back to normal operations.

[major] This last paragraph is a repetition of the one before it.  But it
adds the fact that support can be verified from the RI LSA *or* the
router-LSA itself.  That fact is not considered before: if the RI LSA
hasn't been received (or doesn't include the new capability), but the
router-LSA does have the H-bit set...

284 6.  OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics

286   When calculating the path to an OSPF AS-External-LSA or NSSA-LSA with
287   a Type-2 metric, the advertised Type-2 metric is taken as more
288   significant than the OSPF intra-area or inter-area path.  Hence,
289   advertising the links with MaxLinkMetric as specified in [RFC6987]
290   does not discourage transit traffic when calculating AS external or
291   NSSA routes with Type-2 metrics.

[minor] s/NSSA-LSA/NSSA-LSA [RFC3101]  Also, please add an Informative
reference.

293   Consequently, OSPF routers implementing [RFC6987] and required to be
294   the last resort transit then they MUST advertise a Type-2 metric of
295   LSInfinity-1 for any self-originated type 2 AS-External-LSAs or NSSA-
296   LSAs.  However, in situations, the router needs to repel traffic and
297   acts as a host router then, in addition of the host bit procedure
298   described in this document they MUST advertise a Type-2 metric of
299   LSInfinity for any self-originated type 2 AS-External-LSAs or NSSA-
300   LSAs.

[major] I think the text above is confusing because of the parts about
"required to be the last resort transit" or "needs to repel traffic", which
are not easily verified and normatively hard to enforce.  Also, rfc6987
doesn't use rfc2119 keywords...

NEW>
   Consequently, [RFC6987] is updated so that the Type-2 metric in any
self-originated AS-External-LSAs or NSSA-LSAs is advertised as LSInfinity-1
[RFC2328].  If the H-bit is set, then the Type-2 metric MUST be set to
LSInfinity.


302 7.  IANA Considerations
...
311   This document requests the IANA to assign the Bit Number value of 7
312   to the Host Router Support Capability in the OSPF Router
313   Informational Capability Bits Registry.  [RFC7770]

[nit] That reference is not needed.


...
319 8.  Security Considerations

321   This document introduces the H-bit which is a capability that
322   restricts the use of a router for transit except for its local
323   destinations.  This is a subset of the operations of a normal router
324   and therefore should not introduce new security considerations beyond
325   those already known in OSPF.  The feature, however does introduce the
326   flooding of a capability information that allows discovery and
327   verification that all routers in an area are capable before turning
328   on the feature.  In the event that a rogue or buggy router advertises
329   incorrectly its capability there are two possible cases:

[minor] s/transit except for its local destinations./transit, while only
its local destinations are reachable.

[nit] s/known in OSPF/known in OSPF [RFC2328]

331   o  The router does not have the capability but sends H-Bit set in its
332      LSAs: In this case, there is a possibility of a routing loop.
333      However this is mitigated by the fact that this router should be
334      avoided anyway.  Moreover, the link metrics cost (MaxLinkMetric)
335      of this router will mitigate this situation.  In any case, a
336      router advertising the H-bit capability without its links cost
337      equal to MaxLinkMetric may be an indicator that this is a rogue
338      router and to be avoided.

[nit] s/sends H-Bit/sends the H-Bit

[minor] s/and to be avoided/and should be avoided

340   o  The router has the capability but sends the H-Bit clear in its
341      LSAs: In this case, the router merely prevents support of other
342      H-bit routers in the area and all the routers to run the modified
343      SPF.  The impact is also mitigated as other H-Bit routers in the
344      area also advertise MaxLinkMetric cost so they will still be
345      avoided unless they are the last resort path.