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

"Acee Lindem (acee)" <> Wed, 23 September 2015 09:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 521EB1AC411; Wed, 23 Sep 2015 02:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nOFM6b7luTht; Wed, 23 Sep 2015 02:44:56 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 710191AC3CF; Wed, 23 Sep 2015 02:44:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=46031; q=dns/txt; s=iport; t=1443001495; x=1444211095; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=p0WcLuvimb08a62RqEYtXjm7S1VVtB+ANQSeDrQ+cXc=; b=jxwqwQUQCnYnpE9ZFqHi1iGp2hq0S666yBbVU+EGWUyTBPBy8p9OjZRJ jaTNGGDAkof8IVf/buWubxR1kUyHU7pbeZQjGz+RxXAHXJtGpvzfwhwRU mIw750nLAKXSwuxm0wLpPmpmyVVhN5gJKL0lcePxT/3mQ6hEOCHVZpC0c c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.17,577,1437436800"; d="scan'208,217"; a="31312014"
Received: from ([]) by with ESMTP; 23 Sep 2015 09:44:54 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t8N9isA2015736 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 23 Sep 2015 09:44:54 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 23 Sep 2015 04:44:53 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 23 Sep 2015 04:44:53 -0500
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Wed, 23 Sep 2015 04:44:53 -0500
From: "Acee Lindem (acee)" <>
To: Shraddha Hegde <>, Alia Atlas <>, OSPF List <>, "" <>
Thread-Topic: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02
Thread-Index: AQHQ9YIst/tfqaD4vUilavXsqepMPZ5Jb+sA///CiYCAANUsgP//5yEA
Date: Wed, 23 Sep 2015 09:44:52 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D227EBA931FC7aceeciscocom_"
MIME-Version: 1.0
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: Wed, 23 Sep 2015 09:44:59 -0000

Hi Shraddha,

From: Shraddha Hegde <<>>
Date: Wednesday, September 23, 2015 at 3:13 AM
To: Acee Lindem <<>>, Alia Atlas <<>>, OSPF WG List <<>>, "<>" <<>>
Subject: RE: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02


I agree that the MT –ID granularity is not required for the informational capability TLV as it  “more of” indicates whether router supports the
Feature or not.

Functional capabilities TLV is newly added in 4970bis. My read is that this TLV can be used to indicate whether the router
Currently has enabled the feature or not and take protocol actions based on this information.
It makes sense to add one functional capability TLV per MT-ID in MT deployments.
When the new features need to use the functional capability  TLV to advertise just their capabilities
and do not have additional information, just a functional capability bit should suffice and no new sub TLV definitions would be needed.
This looks more elegant and is compact from protocol message length perspective.

This new TLV is scoped for the entire node and analogous the existing informational capabilities TLV. A new TLV could be added that is scoped by MT-ID for per-MT capabilities.

Having said that, it may be worthwhile to discuss in WG whether we need to consider MT based deployments while
defining the new protocol extensions. In general, there seems to be less interest in deploying multi-topology.

Right - I’m not sure I see a strong requirement for this - especially after WG last call.



From: Acee Lindem (acee) []
Sent: Wednesday, September 23, 2015 4:01 AM
To: Alia Atlas <<>>; OSPF List <<>>;<>; Shraddha Hegde <<>>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02

Hi Alia, Shraddha,

From: OSPF <<>> on behalf of Alia Atlas <<>>
Date: Tuesday, September 22, 2015 at 6:10 PM
To: OSPF WG List <<>>, "<>" <<>>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02

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.

My answer would be that not all capabilities are scoped at an MT level of granularity it is incumbent on the definition of those that are to include the MT ID in the definition.


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 LSA
   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!