Re: [homenet] Egress Routing Discussion

David Lamparter <equinox@diac24.net> Sat, 23 February 2013 09:19 UTC

Return-Path: <equinox@diac24.net>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C1F21F8F41 for <homenet@ietfa.amsl.com>; Sat, 23 Feb 2013 01:19:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.508
X-Spam-Level:
X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWVMSB-iAvAp for <homenet@ietfa.amsl.com>; Sat, 23 Feb 2013 01:19:39 -0800 (PST)
Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B70B21F8F42 for <homenet@ietf.org>; Sat, 23 Feb 2013 01:19:36 -0800 (PST)
Received: from jupiter.n2.diac24.net ([2001:8d8:81:5c2::]) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from <equinox@diac24.net>) id 1U9BGV-0006fL-36; Sat, 23 Feb 2013 10:19:31 +0100
Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from <equinox@diac24.net>) id 1U9BGE-00EgQm-A3; Sat, 23 Feb 2013 10:19:20 +0100
Date: Sat, 23 Feb 2013 10:19:14 +0100
From: David Lamparter <equinox@diac24.net>
To: "Fred Baker (fred)" <fred@cisco.com>
Message-ID: <20130223091914.GF3183407@jupiter.n2.diac24.net>
References: <8C48B86A895913448548E6D15DA7553B79DAEF@xmb-rcd-x09.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8C48B86A895913448548E6D15DA7553B79DAEF@xmb-rcd-x09.cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "homenet@ietf.org Group" <homenet@ietf.org>, "isis-chairs@tools.ietf.org" <isis-chairs@tools.ietf.org>, "ospf-chairs@tools.ietf.org" <ospf-chairs@tools.ietf.org>
Subject: Re: [homenet] Egress Routing Discussion
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Feb 2013 09:19:42 -0000

On Thu, Feb 21, 2013 at 05:22:22PM +0000, Fred Baker (fred) wrote:
[...snip...]
> I have documented my approach, which provides the generalized concept, is built into the routing protocols IS-IS and OSPF, and also addresses at least one other "tagged routing" option, which is to look at flow labels.
> 
> http://tools.ietf.org/html/draft-baker-ipv6-isis-automatic-prefix
>   "Automated prefix allocation in IS-IS", Fred Baker, 18-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-flowlabel-routing
>   "Using IS-IS with Role-Based Access Control", Fred Baker, 17-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing
>   "IPv6 Source/Destination Routing using IS-IS", Fred Baker, 17-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-flowlabel-routing
>   "Using OSPFv3 with Role-Based Access Control", Fred Baker, 17-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing
>   "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 17-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-ospf-extensible
>   "Extensible OSPF LSAs", Fred Baker, 17-Feb-13

While I did not exactly review or even thoroughly read the
-ospf-extensible draft, I did just try to work with it in adding the
null route idea to -ospf-dst-src-routing.  I made these observations:

- the two drafts share the "FIB Design" appendix.  That shouldn't be in
  -extensible I presume?

- the -extensible draft says absolutely nothing about how to handle
  unknown TLVs.  I would suggest adding a bit to indicate mandatory /
  optional status, as done for example with BGP attributes.  I'm not
  sure whether cutting down on possible TLV or length values is viable,
  so maybe a third TLV header byte needs to be added for this.

- the -extensible draft references the source-prefix TLV.  This seems OK
  in general, however in 3.1.1 IPv6 Destination Prefix TLV, "The IPv6
  Destination Prefix TLV MAY be used with the IPv6 Source Prefix TLV,
  [...]" I believe it is somewhat weird to refer to a TLV that is not
  defined in that draft.

Cheers,

-David