[OSPF] Some comments on draft-ietf-ospf-transport-instance

"Osborne, Eric" <eric.osborne@level3.com> Thu, 16 October 2014 16:08 UTC

Return-Path: <eric.osborne@level3.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 1DA091A212D for <ospf@ietfa.amsl.com>; Thu, 16 Oct 2014 09:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ps7g60ym1YfX for <ospf@ietfa.amsl.com>; Thu, 16 Oct 2014 09:07:58 -0700 (PDT)
Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com []) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D24C01A1C00 for <ospf@ietf.org>; Thu, 16 Oct 2014 09:07:57 -0700 (PDT)
Received: from [] by server-2.bemta-8.messagelabs.com id 87/9D-03631-C5DEF345; Thu, 16 Oct 2014 16:07:56 +0000
X-Env-Sender: eric.osborne@level3.com
X-Msg-Ref: server-8.tower-95.messagelabs.com!1413475675!31746079!1
X-Originating-IP: []
X-StarScan-Version: 6.12.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28262 invoked from network); 16 Oct 2014 16:07:56 -0000
Received: from bge23000.messagelabs1.prod.broomfield1.level3.net (HELO messagelabs1.level3.com) ( by server-8.tower-95.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Oct 2014 16:07:56 -0000
Received: from USIDCWVEHT02.corp.global.level3.com (usidcwveht02.corp.global.level3.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT02.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs1.level3.com (Postfix) with ESMTPS id 989251DE84; Thu, 16 Oct 2014 16:07:55 +0000 (GMT)
Received: from USIDCWVEMBX08.corp.global.level3.com ([fe80::20f7:9e5b:2efa:2ad8]) by USIDCWVEHT02.corp.global.level3.com ([::1]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 10:07:55 -0600
From: "Osborne, Eric" <eric.osborne@level3.com>
To: "ospf@ietf.org" <ospf@ietf.org>
Thread-Topic: Some comments on draft-ietf-ospf-transport-instance
Thread-Index: Ac/pV6s0HDy+8KJ7TpGDOHvNrh4Vmw==
Date: Thu, 16 Oct 2014 16:07:54 +0000
Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACDF9D34A@USIDCWVEMBX08.corp.global.level3.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_63CB93BC589C1B4BAFDB41A0A19B7ACDF9D34AUSIDCWVEMBX08corp_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/Q7wckkXgTXjb-Tsv5LdkGkMf7AM
Cc: "draft-ietf-ospf-transport-instance@tools.ietf.org" <draft-ietf-ospf-transport-instance@tools.ietf.org>
Subject: [OSPF] Some comments on draft-ietf-ospf-transport-instance
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Oct 2014 16:08:01 -0000

This draft came up in the discussion of the OSPF flowspec stuff, so I figured I'd read it.  Some comments:

Overall it makes sense - I see what it's trying to do and how it does it.  I think there are some areas that need fleshing out, though.

section 2.3 lists two methods, ships in the night or child instance.  Section 2.3.1 covers SIN in more detail, but I was expecting 2.3.2 to talk about child instances.  Is that what "Tighter Coupling with Normal OSPF Instances" is supposed to cover?  At a minimum the subsection title should match up, and whatever section is supposed to cover child instances should talk about it more detail.  Is that ultimately planned for this draft, or does 'future study' mean some other document?

I assume the 'flash precedence' thing is as much tongue-in-cheek as it is anything else.  In reality it needs to be configurable; I might want to put something in a transport instance that's as important as routing, or I might have already used AF3x for something else entirely.  Should probably say "SHOULD default to Flash and REALLY REALLY SHOULD  be configurable" or something.

for sparse topologies, how do I build them?  Having to hardcode a tree is a non-starter.  Is there some existing OSPF mechanism to build these?  Can you steal something from multicast?  If neither of those is Yes then I think you need more content here.

Section 2.5 needs some massaging.
It currently says
"OSPF routers SHOULD NOT advertise any transport instance LSAs containing IP or IPv6 prefixes"

but what if I want to use multi-instance to do some sort of overlay thingy?  I don't necessarily have a service in mind, but I'd hate to lay down a law that says "you CANNOT use transport instances for any IP prefixes at all ever" and then come back later with a doc that backs that out.  What about "transport instances MUST NOT advertise any routing information which would conflict with the base IP routing instance and SHOULD NOT advertise any routing information without a really good reason"?

Also, "this implies that..." is a little wishy-washy.  The implication isn't obvious to me.  Is the goal to only use transport instances to carry things in opaque LSAs and allow just enough topology information for those opaques to be calculated?  If so, that should be spelled out - maybe you only allow 1/2/5/9/10/11?

2.7.1 should probably be 2.8, as remote neighbors are an option in addition to sparse topologies, not a sub-version of them.
Also, why not reuse virtual links here instead of introducing a separate ability to have targeted neighbors?
And 'Other salient features' makes me think there's much more to targeted neighbors than just the three bullets you have listed.  As much as I'd like to believe that you can get away with a bullet that says 'implementer MUST know what they're doing' and another one that says 'implementer MUST NOT screw this up', you probably need to get into a little more detail for the sake of those to whom the subtleties aren't obvious.