Re: [Isis-wg] Who did you have do an IS-IS source/destination routing project?

Hannes Gredler <hannes@juniper.net> Mon, 28 July 2014 16:22 UTC

Return-Path: <hannes@juniper.net>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832051A03A5 for <isis-wg@ietfa.amsl.com>; Mon, 28 Jul 2014 09:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 Q7vXMNuxkEvB for <isis-wg@ietfa.amsl.com>; Mon, 28 Jul 2014 09:22:37 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE0D1A037C for <isis-wg@ietf.org>; Mon, 28 Jul 2014 09:22:35 -0700 (PDT)
Received: from CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) by CO1PR05MB268.namprd05.prod.outlook.com (10.141.71.26) with Microsoft SMTP Server (TLS) id 15.0.995.14; Mon, 28 Jul 2014 16:22:26 +0000
Received: from juniper.net (193.110.55.12) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.0.995.14; Mon, 28 Jul 2014 16:22:23 +0000
Date: Mon, 28 Jul 2014 18:22:07 +0200
From: Hannes Gredler <hannes@juniper.net>
To: David Lamparter <david@opensourcerouting.org>
Message-ID: <20140728162207.GB18387@juniper.net>
References: <94217864-2004-4F82-8602-B9BAB4639BCE@cisco.com> <alpine.DEB.2.02.1407231253240.7929@uplift.swm.pp.se> <20140723114049.GH801478@jupiter.n2.diac24.net> <A7EEA4F6-686B-4B96-89DB-35D923994179@cisco.com> <20140724152101.GU801478@jupiter.n2.diac24.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20140724152101.GU801478@jupiter.n2.diac24.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Originating-IP: [193.110.55.12]
X-ClientProxiedBy: AM3PR06CA060.eurprd06.prod.outlook.com (10.141.192.178) To CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140)
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:
X-Forefront-PRVS: 0286D7B531
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(51704005)(24454002)(199002)(189002)(377454003)(69234005)(377424004)(4396001)(76482001)(47776003)(66066001)(80022001)(46102001)(77982001)(23676002)(36756003)(50466002)(19580405001)(575784001)(83322001)(20776003)(31966008)(86362001)(74502001)(42186005)(81342001)(19580395003)(83072002)(81542001)(74662001)(21056001)(85852003)(93886003)(99396002)(92726001)(92566001)(101416001)(69596002)(87976001)(83506001)(15975445006)(102836001)(105586002)(77096002)(64706001)(54356999)(81156004)(106356001)(95666004)(79102001)(76176999)(107046002)(110136001)(33656002)(50986999)(85306003)(579124003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB444; H:juniper.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/Cz2nqqwHglnTEv7iLAwGPMBG4Iw
Cc: isis-wg@ietf.org
Subject: Re: [Isis-wg] Who did you have do an IS-IS source/destination routing project?
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Jul 2014 16:22:41 -0000

hi david,

i'd be in favour of a CAP registry for IIH (long-term
we need that anyway) - do not care much wether we open-up 242
to IIHs or use a new top-level code-point.

@les - opinions ?

/hannes

On Thu, Jul 24, 2014 at 05:21:01PM +0200, David Lamparter wrote:
| (IS-IS parts in this mail, match behaviour in separate mail)
| 
| Fred, WG Chairs:
| 
| Regarding the IS-IS part, we didn't find major issues while implementing
| draft-baker-ipv6-isis-dst-src-routing-01, though there is one issue that
| needs broader concern.  We need to signal a router's capability to do
| dst-src routing, in order to prevent loops when a reachability with
| source prefix is behind a router that does not have this capability.
| (The latter router may send the packets back by matching another,
| shorter non-specific route for the same destination prefix, since it
| doesn't consider the source match more specific.  Loop example included
| below.)
| 
| Now there is a small issue with this capability indication - there is no
| generic IS-IS capability TLV, only the TE-targeted RFC4971 (TLV 242)
| which uses a quad-octet Router ID.  We have no such router ID and would
| prefer to not elect/autoconfigure one.  This leaves us with these
| possibilities:
| - create a "dst-src capable" TLV, wasting a top codepoint
| - create a "generic" capability TLV without router ID (maybe including
|   NET instead, for inter-level flooding)
| - adjust the 242 capability TLV to permit router-id 0.0.0.0 (or some
|   other reserved value), while forbidding cross-level flooding when this
|   value is used. (S=0)
| 
| I don't have useful arguments in this regard and would appreciate input
| (can resend this to WG mailing list if you believe that to be more
| appropriate)
| 
| David
| 
| P.S.: I'll step up and say Hi in the isis session today.
| 
| 
| Loop example: (all costs/metrics equal)
| 
| R1 -- R2 -- R3 -- R4
| 
| - R1 and R4 each have reachable ::/0, with source prefix P1 != P4
| - R2 does not support dst-src routing
| -> R2 will install a ::/0 route pointing to R1 and ignore the
|    reachability from R4 since it has higher cost.
| - R1 will install a ::/0 route with source prefix P4 pointing via R2
| => packets with source P4 loop between R1 and R2
| 
| Discussion regarding the loop situation occured on homenet and ospf
| mailing lists on 2013-02-22 and 2013-02-23.
| 
| 
| On Wed, Jul 23, 2014 at 01:33:12PM +0000, Fred Baker (fred) wrote:
| > Chairs:
| > 
| > FYI, Mikael (Deutsche Telekom AG) is interested in IS-IS
| > source/destination routing, and asked David to do a prototype in
| > Quagga based on my draft of a while back. The question is how to
| > document and standardize the result. We will need to discuss that with
| > you, and with the working group.
| > 
| > On Jul 23, 2014, at 7:40 AM, David Lamparter <david@opensourcerouting.org> wrote:
| > > Fred, Mikael,
| > > 
| > > On Wed, Jul 23, 2014 at 12:57:31PM +0200, Mikael Abrahamsson wrote:
| > >> On Wed, 23 Jul 2014, Fred Baker (fred) wrote:
| > >>> He asked to collaborate with me, and I asked me to send me an email,
| > >>> and I would send him a bunch of material. If you can give me his
| > >>> email address, I’d like to send him an email.
| > > 
| > > Indeed that was me, apologies, I didn't assume immediate activity on
| > > this.
| > > 
| > > I've yet to go look at the history/previous comments from when the
| > > isis-srcdest draft was originally posted.  I'm aware of the large
| > > appendix on ospf-dst-src-routing-02, which as far as I remember is the
| > > piece to be moved around, but need to check back on details.
| > > 
| > > So - what are the next steps on this?
| > 
| > David:
| > 
| > From my perspective, you have implemented the technology and will have things you learned in the process. Part of that is “this text was difficult to understand”, and either you have text to suggest or hope I do. Part of that is things I left out, which again you may have suggestions or need to ask me. Part of it is the comment from the rtgwg meeting in which I presented draft-baker-rtgwg-src-dst-routing-use-cases, asking for further discussion of the FIB. Maybe you have other use cases, or Mikael does. Maybe some of the use cases aren’t well stated or are superfluous. There is text in section 2.2 of draft-baker-ipv6-isis-dst-src-routing that was requested in the rtgwg, and I spent some time in appendix B of draft-baker-ipv6-isis-dst-src-routing-00 on lookup mechanisms. 
| > 
| > One of the issues, which I have stated a number of times but not apparently stated well in a draft, is in the attached email message - people would really like to look up the destination and source addresses in that order, or source and destination in that order, and make the right thing happen. I’m of the opinion that each sequential approach has a set of cases it doesn’t cover, and one has to look up the source and destination as a single object to cover them all.
| > 
| > From my perspective, the next step is, as you said in a different message (which I have now read), the thing to do is capture your implementation experience in the draft. I believe that we need the IS-IS Working Group consensus to change the TLA as suggested, which will mean further discussion on isis@ietf.org and probably mean a presentation in Honolulu. However, I’d like to believe that we can get a fair bit of work done on the mailing list.
| > 
| 
| > Content-Type: multipart/signed;
| >  boundary="Apple-Mail=_6BEFDE79-1C07-4570-9617-F402FD580A92";
| >  protocol="application/pgp-signature"; micalg=pgp-sha1
| > Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
| > Subject: Once again, on ambiguity and the FIB.
| > X-Universally-Unique-Identifier: a86f74de-0cf3-421e-8750-ebe7cfdb3ec4
| > From: Fred Baker <fred@cisco.com>
| > In-Reply-To: <B563CE78-3783-4A23-AE19-5C9D41BE43B3@cisco.com>
| > Date: Thu, 20 Feb 2014 23:48:13 +1300
| > Cc: Mingwei Xu <xmw@cernet.edu.cn>
| > Message-Id: <AFEACB7E-E892-470F-867C-FBC301D64FBD@cisco.com>
| > X-Smtp-Server: https://fred@mail.cisco.com/ews/exchange.asmx
| > References: <CAL6OX+1XwamCSUBY8m8tkGmZAb_8=9csmtM3nLNCufkPJc_niw@mail.gmail.com>
| >  <66D9F1A5-5BFA-4089-8E6D-3D7616312753@cisco.com>
| >  <CAL6OX+1cs5SHqpMT8zFRTtbQT8qg2vnzOnk4suPk8iKaLNjaEQ@mail.gmail.com>
| >  <CAL6OX+0h57v0xdvHfwYOqCCpw+AYJHXwAm1m-05V=1BRaRyDsg@mail.gmail.com>
| >  <D248624E-A4D0-4721-8F45-7973E3BB8443@cisco.com>
| >  <CAL6OX+1EP3uCgEyWa2RSMEknDR9g=SmHk1SZNNyr5fNiDcUpLA@mail.gmail.com>
| >  <CAL6OX+2=uLt6BssgKRHmu844RX11GRTHvdBgZ8sAGupbTpx96w@mail.gmail.com>
| >  <D3289844-1C43-46BF-AB3C-FA4013750AA2@cisco.com>
| >  <CAL6OX+3vd1ns7Nj1=Czq3feCJRqZCRE0hEk+Gq3LBsfWifCFXQ@mail.gmail.com>
| >  <06179288-AAFB-43DD-B58D-94226F603493@cisco.com>
| >  <CAL6OX+3W1kOJ2PGqdp=zHph4DS57_jB9L3PGTzyOFRW-G_Z9rg@mail.gmail.com>
| >  <B563CE78-3783-4A23-AE19-5C9D41BE43B3@cisco.com>
| > To: Shu Yang <yangshu1988@gmail.com>
| > 
| > We seem to travel in circles on this. We come to closure, and then it comes up again. I'm getting frustrated. I'm sorry if I was too short with you in Skype last week.
| > 
| > Here's the ambiguous network:
| > 
| >       ------------------+--       --+---------------------
| >        2001:db8:1::/48  |           |   2001:db8:3:3::/64
| >                      +--+--+      +-+---+
| >                      |     +------'Bob  |
| >                      |     |      +-----+
| >                      |Alice|
| >                      |     |      +-----+
| >                      |     +------+Carol|
| >                      +--+--+      +-+---+
| >                         |           |
| >       ------------------+--        -+--------------------
| >        2001:db8::/40                    2001:db8:3::/48
| > 
| > The route advertisements are that
| > 
| >     2001:db8:1::/48 -> 2001:db8:3::/48   via Carol
| >     2001:db8::/40   -> 2001:db8:3:3::/64 via Bob
| > 
| > In Venn Diagrams:
| >                                                     _.--------.
| >          _.------------.           +-----+      ,-''-----------`--.
| >     ,--'2001:db8::/40 ------------>| Bob |----->(2001:db8:3:3::/64)`.
| >   ,'                         `.    +-----+   /   `---------------'   \
| >  /     ,---------------.       \   +-----+  /                         \
| > (     ( 2001:db8:1::/48 )--------->|Carol|-----> 2001:db8:3::/48       )
| >  \     `---------------'       /   +-----+  \                         /
| >   `.                         ,'              \                       /
| >     '---.               _.--'                 `.                   ,'
| >          `------------''                        '--.           _.-'
| >                                                     `--------''
| > 
| > We have an ambiguous routing situation: the set of addresses matching 2001:db8:1::/48 also match 2001:db8::/40, and the set of addresses matching 2001:db8:3:3::/64 also match 2001:db8:3::/48
| > 
| > The simplest solution is to *also* include a route in the FIB more more specific to more specific, which is to say 
| >      2001:db8:1::/48 -> 2001:db8:3:3::/64, 
| > which obviously has to go via Bob, because Bob is the only one that has connectivity.
| > 
| > You argued in berlin that I don't actually need that, and I would agree if we have a lookup mechanism such as a TCAM or a patricia Tree that can do the entire lookup in one operation.
| > 
| > But OK, so now I have a packet from more specific to more specific, but I don't have the additional route in the FIB.
| >              2001:db8:1::1 -> 2001:db8:3:3::1
| > 
| > However, if I have separate or cascaded FIBs and look up the source first, longest match first gets me to the FIB for 2001:db8:1::/48, and 2001:db8:1::/48 can't get me to Bob - only Carol. So I have no route. 
| > 
| > 
| > Now, repeat the question with a destination-first lookup, and modify the network diagram by adding one router and changing a prefix:
| > 
| >     ------------------+--       --+------------------------+----
| >      2001:db8:1::/48  |           |   2001:db8:3:3::/64    |
| >                    +--+--+      +-+---+                    |
| >                    |     +------'Bob  |               +----+---+
| >                    |     |      +-----+               |        |
| >                    |Alice|                            | Dave   |
| >                    |     |      +-----+               |        |
| >                    |     +------+Carol|               +----+---+
| >                    +--+--+      +-+---+                    |
| >                       |           |                        |
| >     ------------------+--        -+------------------------+----
| >      2001:db8:2::/48                   2001:db8:3::/48
| > 
| > with the rules
| >     2001:db8:1::/48 -> 2001:db8:3::/48   via Carol
| >     2001:db8:2::/48 -> 2001:db8:3:3::/64 via Bob
| > 
| > If I do a destination lookup and then treat the source address as an access list, excluding things that don't match, Alice will try to forward a packet 
| >      2001:db8:1::1 ->  2001:db8:3:3::1 
| > via Bob, and will decide not to because both addresses don't match the rule. However, if Alice noted that 2001:db8:3:3::/64 is a subset of 2001:db8:3::/48 and forwarded it to Carol, in the worst case Carol would have no route and drop the packet, and in the given case could actually get it to the destination via Dave.
| > 
| > 
| > So both in the case where one mandates that one look up the source first and in the case where one mandates that one look up the destination first, cases exist in which a packet that *could*, within the rules, get from a source to a destination is dropped because of the order in which one did the lookup.
| > 
| > The statement that I made in draft-baker-rtgwg-src-dst-routing-use-cases was that 
| > 
| >    o  The FIB lookup yields the route with the most specific (e.g.
| >       longest-match) destination prefix that also matches the source
| >       prefix constraint, or no match.
| > 
| > I think that is the right answer. In the second case I note in this email (which I should probably write up in an internet draft, as it seems controversial), the FIB lookup should find and act on the rule 2001:db8:1::/48 -> 2001:db8:3::/48, even though 2001:db8:3:3::/64 is a more specific destination lookup, because it matches both prefixes.
| 
| 
| 
| > 
| 
| 
|