Re: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02

Alia Atlas <> Tue, 22 September 2015 22:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D12E61A907D; Tue, 22 Sep 2015 15:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Status: No, score=-101.999 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, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8eikTtIX1n0e; Tue, 22 Sep 2015 15:10:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF6E01A906D; Tue, 22 Sep 2015 15:10:58 -0700 (PDT)
Received: by oiev17 with SMTP id v17so14016700oie.1; Tue, 22 Sep 2015 15:10:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4rf7PgqhYUQCe2NnJbRO9I2wobwJxpBkiIr7E5frGV0=; b=AfhgLqQAFv38D3xTLieDTHI+38I7YtB6eTLUJGnSyshxhA8ErDIXZqVMoQ8e68lSiL mSD9+dQVHrVLOEj9MlDxW3E4rI4jYV4wpHWx0YoYpksWtM7h8OK17aFpwcIWTKoBaVKZ eXMeqvgM/efW71yh+19fHuWwDh4o4N7X5AYAofQLT0oRHZGrO2oTTz9/RNNUOtlM/GIK +liT8HxeUk5biLQ3vKN/jkZDRlxoph4BalkLEP+ohpwWZOl7Dh3IF3UBa6QuPXRwcGpr wrS37/8QWCbPQfDQska2l1HD7oKD/bsi6UzNGFq4WOtWD/cb0liJima9Lod4ItOMAES3 wZGA==
MIME-Version: 1.0
X-Received: by with SMTP id w133mr16273202oif.72.1442959858384; Tue, 22 Sep 2015 15:10:58 -0700 (PDT)
Received: by with HTTP; Tue, 22 Sep 2015 15:10:58 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 22 Sep 2015 18:10:58 -0400
Message-ID: <>
From: Alia Atlas <>
To: OSPF List <>,
Content-Type: multipart/alternative; boundary=001a1134fbd6c8c6c505205d450e
Archived-At: <>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Sep 2015 22:11:02 -0000

Minor correction:

On Tue, Sep 22, 2015 at 6:00 PM, Alia Atlas <> wrote:

> As is customary, I have done my AD review
> of draft-ietf-ospf-rfc4970bis-02.  First, let me thank Acee for his work on
> this draft.
> I have two major concerns before asking for an IETF Last Call.  I would
> like to have them
> resolved by this Thursday so that the draft can make the Oct 15 IESG
> telechat.
> First, from a process concern, I do not see any active discussion on the
> OSPF mailing list - even to simply say "yes - go forward".  I don't see
> anything about this draft or discussion in minutes for IETF 92 or IETF 93.
>   I'd prefer some indication besides silence and lack of opposition.  I do
> realize that there are some process or protocol-tidying drafts where there
> isn't
> much interest.  However, I am particularly concerned because this is
> changing RFC4970 is a way that should be backwards compatible but might
> trigger issues.   I would encourage WG participants to PLEASE RESPOND!

In IETF 91 minutes, I see a presentation and question from Shraddha about
making it MT capable.  There was no
answer except take it to the list and no follow-up discussion.

Am I missing anything?


> Second, I can see the intent that by creating an Opaque ID and creating a
> special meaning for 0, the draft is making efforts to preserve backwards
> compatibility.  Please add a paragraph or subsection that articulates how
> and why backwards compatibility isn't an issue.  For extra credit, what
> happens if the same TLV information is advertised in multiple RI LSAs (as
> part of moving it from one RI LSA to another)?
> Are there any implementations of this draft?  Has backwards compatibility
> been verified at all?
> My minor issue is around the IANA considerations; I have detailed comments
> below.
> Here are additional comments.
> 1) In Sec 2: "The first Opaque ID, i.e., 0, should always contain the
> Router
>    Informational Capabilities TLV and, if advertised, the Router
>    Functional Capabilities TLV."  and Sec 2.2 "The first instance ID,
> i.e., 0,
>    should always contain the Router Informational Capabilities TLV and,
>    if advertised, the Router Functional Capabilities TLV."
>    Since I assume this is important for backwards compatibility, should
> those
>    be SHOULD instead of should?
> 2) In Sec 2.3: "The first defined TLV in the body of an RI LSA is the
> Router
>    Informational Capabilities TLV."
>    Surely that is only for the first Opaque ID=0?  Does each subsequent RI
>    also need to contain a Router Informational Capabilities TLV??
> 3) In Sec 4 IANA Considerations:  This section is defining the different
> IANA policies;
> when RFC4970 was written, RFC5226 didn't exist.  But since you're doing a
> bis,
> perhaps you can align to the policies in RFC5226 and remove the
> unnecessary text??
> 4) In Sec 4 IANA Considerations:  The registry for OSPFv3 LSA Function
> Codes can
> be found at
> and what is in the draft doesn't match up.  I'd settle for defining the
> ranges, and value 12 - but it's up to you and IANA on the preferences.
> Would it make sense to change the policy from Standards Action to IETF
> Review here also?
> Same thing applies to the OSPF RI TLVS (
> )   Also here, I think there
> was agreement among the 4 of us who commented on the WG mailing list to
> change this
> from Standards Action to IETF Review.
> 5) In Sec 4 IANA Considerations: "All Router Functional Capability TLV
>        additions are to be assigned through standards action."   Given the
> discussion
> about IETF Review vs. Standards Action for other registries, are you sure
> you want
> Standards Action?
> I'm sure that we'll get this moving along quickly.
> Thanks again!
> Alia