Re: [Isis-wg] Requesting WG adoption of draft-baker-ipv6-isis-dst-src-routing-06
Tony Przygienda <tonysietf@gmail.com> Fri, 09 December 2016 17:13 UTC
Return-Path: <tonysietf@gmail.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F172129512 for <isis-wg@ietfa.amsl.com>; Fri, 9 Dec 2016 09:13:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 FYlAFDiadx9b for <isis-wg@ietfa.amsl.com>; Fri, 9 Dec 2016 09:12:59 -0800 (PST)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE098129417 for <isis-wg@ietf.org>; Fri, 9 Dec 2016 09:12:58 -0800 (PST)
Received: by mail-wm0-x233.google.com with SMTP id c184so14631192wmd.0 for <isis-wg@ietf.org>; Fri, 09 Dec 2016 09:12:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oFwr57Z1u2nrB64zn1eQNbRceGTpgN5SiBlhH4RfrVI=; b=pRNeH8q8/NdCluqSMUh6MfLkdWZ+1GXIlrRrJhWiR4XZ0u3OVJ1JJgzGeB/53P3rya eR+qj0b329F7L3wVqcfWHQ8fJfNT6Rm9RPzjqrzjUYKcVoKds/f0fANe3BPzVx90qUJV U1Gft0WREUJ9a3xje41vdvbb5EazgXBZw0y2VzNI9vabAh1iGR6Fy8r8ex2vBSz42BmB Z5mpSB6+BY3DhQQk8pVczs+2JUBMsmKTCGlQLMD0mS/Kq7MvEID/ldMvu3/j3iNnED+M mRW89p/q10DWRl+hhDwfAagRW8+FF3a6yuFUYxE+efqWX837imqmq8UxG3wuHFbzdEbx ZNfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oFwr57Z1u2nrB64zn1eQNbRceGTpgN5SiBlhH4RfrVI=; b=dlOmOEQPSyBTj4Xj7vdhdveIfLafB0A30/q90Y1NsDibjZbhGx1uitrfk16iL2OgCh EvSCCKfAdTqrakX8QcAEKaQM3yiCvM6TfNfB/y0XEsM0hISUE1w0mQ3lmBUPdRnTMRML y9AM/Oy+6HzBApJKIbCuNR17dhbTuMoac4VdZnM7hINko8PtI1+7Kt3jiuqk9seCw6vF 9S7BHbpuqzUaQg5p6wPL/qHnMHRGr/u8ivBxHWGWnthvSiBrBjLBkKF3KsXE5DYpeppv ePNHVzqzb+bav45SSGcg2zb7xiglyzffh0I7jq/E/p8+FZPEaEKZvP6ISXNHoGsAi988 nhvg==
X-Gm-Message-State: AKaTC01pg5zWRISYMjckxWf5Wh0isfnSaDE/y6CQ1HS8fs7TH4LQ2AU+xv7oYNVAxAX5tOH3t/DjbhlXnCEV9g==
X-Received: by 10.28.225.11 with SMTP id y11mr7519152wmg.93.1481303577349; Fri, 09 Dec 2016 09:12:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.149.150 with HTTP; Fri, 9 Dec 2016 09:12:16 -0800 (PST)
In-Reply-To: <20161209114441.GI91403@eidolon>
References: <20161018213247.GQ639535@eidolon> <MWHPR05MB28295C2BB382A538C34C7106A9AA0@MWHPR05MB2829.namprd05.prod.outlook.com> <20161027141223.GG639535@eidolon> <CA+wi2hO_UmBLS=7Ka5i_fiDCTNPb+rnWUCTud5=sqO1rSxp8sQ@mail.gmail.com> <20161209114441.GI91403@eidolon>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Fri, 09 Dec 2016 09:12:16 -0800
Message-ID: <CA+wi2hPs40QewOhdsgKL_j8RnfLZs4kO7sO0n+MGa5D4X9k0NA@mail.gmail.com>
To: David Lamparter <equinox@diac24.net>
Content-Type: multipart/alternative; boundary="001a114b071288661205433cdda2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/QOfOi5cgjmA5PIhxtCOATsvjkSs>
Cc: "isis-wg@ietf.org list (isis-wg@ietf.org)" <isis-wg@ietf.org>, "FredBaker.IETF@gmail.com" <FredBaker.IETF@gmail.com>
Subject: Re: [Isis-wg] Requesting WG adoption of draft-baker-ipv6-isis-dst-src-routing-06
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 09 Dec 2016 17:13:01 -0000
Either publish or pls drop me the private version with all the corrections. I'll parse it then with your message. I see right now too many "ooh, yeah, it works but I didn't write it down yet so you're missing an assumption". I need all axioms on the table to pick through it again ;-) Again, I support adoption, correctness is orthogonal (and can be achieved with the track the draft is on right now) -- tony On Fri, Dec 9, 2016 at 3:44 AM, David Lamparter <equinox@diac24.net> wrote: > Hi Tony, > > > sorry - this got slightly lost in the IETF Seoul haze at my end :( - > more inline. > > On Thu, Oct 27, 2016 at 07:02:43PM -0700, Tony Przygienda wrote: > > My first comment a good while ago on the mike when you were showing > > your first proposals was that you'll on a slippery slope to redo MT in > > topology #0 ;-) Stupid is too strong a word, it's simply one of those > > problems that looks like a "small addition" needed initially until it > > sucks you treacherously underwater. > > Yep, let's call that a fun excursion, but now we're on the serious track > ;) > > > I favor adoption as well as an elegant application of MT with the > > following necessary fixes ;-) > > > a) you prescribe 2 different things in the draft ;-) > > > > a.1 you want to forklift all the routers in section 2.3. In fact, > > MT-ISIS has been proposed to prevent such fork-lifting need. > > Forklifting is sufficient but not necessary as you observe > > later in the "correctness considerations". > > That's not my intention to express, as you say MT's purpose is to avoid > a need to forklift. I'm not sure where I worded this as forklifting, do > you mean "Therefore, all routers participating in D/S routing MUST > implement M-ISIS and participate in the appropriate D/S topology [...]"? > > If so, I need to reword that to make more clear that you *can* mix D/S > and non-D/S routers, but all D/S routers need to consistently implement > MT. (That's what I tried to say with "participating", I guess that's a > poor choice of words...) > > > a.2 in "correctness considerations" you allow to mix the routers > which > > is correct but the logical chain doesn't hold completely. > > First "axiom" is clear (i.e. forwarding lookup). The second > > "pilar" is confused by > > Oh - I'm missing a step there. > > So, the unwritten assumption that I need to write out there is: there > are continuous "subdomains" of D/S routing. Normally, I would hope > there is only a single such subdomain of D/S routers, and ideally this > is your entire IS-IS domain if every router supports dst-src. > > If you lose connectivity and this subdomain splits into two, the case > described there can occur - D/S reachabilities for which no path inside > the MT topology can be found, even though there is non-D/S connectivity. > > *However* this is a transitive property. If a router A can't find a > path for a D/S reachability, neither can its direct neighbors. To be > completely correct and account for max-metric too, "neither can its > direct neighbors who are farther away". > > What the proof really relies on is: "if your SPF calculation found a > path for D/S reachability (D,S) via IS-IS adjacency N, then N will also > find a path for (D,S) [with a lower path metric]". > > > *"If, for case (b1), the system knows of the existence of a more* > > * specific D/S route, but cannot calculate a valid path, it may* > > * either apply non-D/S routing (i.e. not install any route) or* > > * discard the packet (i.e. install a discard route). The next hop* > > * will either be a non-D/S system, or a D/S system with the same* > > * link-state information (and thus again unable to calculate a valid* > > * path -- or, more specifically, won't calculate a path that* > > * includes the previous router)."* > > > > That seems to contradict *"**Packets will transit into D/S > > routing but not out of it"* > > It shouldn't; see below. If the packet is forwarded on D-only, it > hasn't entered D/S routing yet, even if a D/S router forwarded it. > > Once a D/S router forwards it using D/S information, it's safe to assume > (and neccessary for correctness) that the next router will be a D/S > router that also successfully applies D/S forwarding. > > > In short, with your axiom (prefer routes with source match over > > 0/0 source entry) you have two choices for the 2nd axiom (both > > lead to correct routing but exclude each other). The reason is > > that you either "enter semantically richer topology and never > > leave" _OR_ "exit semantically richer semantics and never enter > > it again". Less formally that translates into > > > > Either > > > > a) a packet may enter from non D/S into D/S and any D/S MUST NOT > > forward it to a non D/S next-hop, i.e. you can't install > > default topology entries into FIB as "union". This holds EVEN > > when you received the packet from a D/S neighbor since the > > packet MUST NOT jump out into the non-D/S topo again (it may > > have came from here upstream). Otherwise you'll find looping > > scenarios > > (Let me add: > "If you are able to calculate a D/S path, you MUST install and use it.") > > > or > > > > b) a packet may exit from D/S into non-D/S, i.e. no source-specific > > FIB match is found and you match on 0/0 source (topology #0). > > Once it's out in the non-DS world, it MUST stay there, i.e. > > you must not as D/S router advertise topology #0 information > > since a non-DS router may use that to jump into the D/S again > > not understanding it's doing it. > > NB: the edits I have pending for Chris' comments also clarify that the > D/S topology is NOT intended to contain duplicates of topology #0 > information; in fact it should not contain any reachability with S=0/0 > (meaning both implicit [no Sub-TLV] or explicit [Sub-TLV with S=0/0]). > > > Again, in short you either enter D/S once and only once and > > never leave D/S or you exit D/S once and only once and never > > enter D/S again. > > This still holds true: once a system is forwarding a packet based on a > successful SPF calculation in the D/S topology, it can be assumed that > the next router can also make that successful SPF calculation in the D/S > topology. > > In reverse, if a D/S system is unable to calculate a path in the D/S > topology, it can assume that the system it received the packet from > wasn't able to do so either. It may have been a non-D/S router or a D/S > router with no SPF result, but either way the packet has /not/ entered a > D/S forwarding path yet. > > (The exception on this, of course, are microloops while information is > being flooded, but that's a generic problem, not dst-src...) > > > b) section 3.1: I would explain what is the multiplicity of this TLV and > I > > expect it to be 1 and only 1. Omitting it will collide with MTID#0 > > and having two has no semantics (unless specified). > > Right -- this is an open "existence" question where my assumption was > that it'd always be "exactly 1" but I'd left it to wait and see if > someone sees a use for it that I don't :) > > (It could be "more than 1" which could signal more than one D/S route > with same D but different S in a single TLV, but I think that's a > counterproductive micro-optimisation that has significant negative > complexity impact.) > > I've received no other input and will change it to "MUST ==1". > > > --Thanks for your extensive input! > > > -David > > > P.S.: meta-question - this is still running in WG adoption call; should > I push a new draft anyway or wait? I also have some edits queued to > adress Chris' comments... though I wouldn't say any of these edits are > "substantial" changes to the idea. > -- *We’ve heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.* —Robert Wilensky
- [Isis-wg] Requesting WG adoption of draft-baker-i… David Lamparter
- Re: [Isis-wg] Requesting WG adoption of draft-bak… Fred Baker
- Re: [Isis-wg] Requesting WG adoption of draft-bak… Chris Bowers
- Re: [Isis-wg] Requesting WG adoption of draft-bak… David Lamparter
- Re: [Isis-wg] Requesting WG adoption of draft-bak… Les Ginsberg (ginsberg)
- Re: [Isis-wg] Requesting WG adoption of draft-bak… Tony Przygienda
- Re: [Isis-wg] Requesting WG adoption of draft-bak… David Lamparter
- Re: [Isis-wg] Requesting WG adoption of draft-bak… Tony Przygienda