Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt

Robert Raszuk <robert@raszuk.net> Sat, 02 December 2017 19:31 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA263126D85; Sat, 2 Dec 2017 11:31:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 CszJ4bCnWSnL; Sat, 2 Dec 2017 11:31:58 -0800 (PST)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 56E0A128B51; Sat, 2 Dec 2017 11:31:57 -0800 (PST)
Received: by mail-wr0-x22f.google.com with SMTP id v105so13254097wrc.3; Sat, 02 Dec 2017 11:31:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=LUD4T93dieoqw2h034BDmh2nAJCfjHJr4wpAIRrubbc=; b=JEBNznQXJ51aUtBEx2wA4mPUjlkOUlMYyKJKJAG5Xau5h/BR5YxUttw3WbBxvvuPkk ixFADG9c6vqnyQxk7iU6IQmh08dxczNswC/16Ov36OhMAjuRoOOPGQgBA2kyxHuRwLAJ L0Pg2I8ogXt70U5pE7DAcwRTGIsnFgt8t+XbRO1kdKD6G6brwB4A34kE9h9L/vFeMNqD QLl9Tz61+bl6txJ8ycWpuAuiQ70/Aptf6JvUdvTK0ysDjkQiIWDCePk17A/gwz1tsJPH AM4mR+gFfqqZDZQmQZp3cNmigUu3Iu04XhEwoZrdn18yPNhSA1zPZAkMV4fSM6wZNRzv Ok/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=LUD4T93dieoqw2h034BDmh2nAJCfjHJr4wpAIRrubbc=; b=Gvkne4pdF9wILzHYSb6HvAlKZPJdKAdD7XJB+mIF+y8OXJeuaxYu7Wi7aQ4kIadrwo +/89TVauQWoY+tzzn23f9xNRTB4P+1TuoOChDdGGD9CJC3hzPDuBNN6BGq7NpSEcB98A o7nP0BPegYdkRSWtkU0hHNXQwvlEhl1unuT5aKEy/v/S3yH5kqoarMycXnRn/R9JW0MZ exXjWxpWtobSQbo4jrgG6oeFX01fmz40+9s/kstlxaLSOlZ6a46UThYUDVVym+67JDBS CQz8dAgfJoLMPmuD/+3i36gmvuQS32djOvQgzxDPt2BXCUvftIVZdG+CvqPXYWsmgn9J O2Hw==
X-Gm-Message-State: AJaThX5Rrxz0ebzdII0nnwVDa39Dz1snHLIL+RGMHCqtIyI5Ps13Msnk cM3pyWXeYw2EslpSha39o20sZ+MXds8kt8/k8WM=
X-Google-Smtp-Source: AGs4zMYBbA6JbAoiiVd6VmtKMe6jIP/LQIMEc+AEMm+xmHPSiAOIthvF5qCNc7RRrbsnxyjUqN3GowjxkT1iN++ZR9c=
X-Received: by 10.223.193.141 with SMTP id x13mr8409878wre.239.1512243115645; Sat, 02 Dec 2017 11:31:55 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.28.54.217 with HTTP; Sat, 2 Dec 2017 11:31:54 -0800 (PST)
In-Reply-To: <CALx6S34fSBycO+1pU8x3konO+6=s9sYWQQaFp36kcHi4HdyxFQ@mail.gmail.com>
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> <f4425076-2f76-5713-2819-9d26671d56bb@si6networks.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <bc9d7f57-8687-7f85-8ac3-49751683232b@si6networks.com> <CA+b+ERnKbRXgFycgKd7EXMVvS1Mu_RTC5tfPbNE781TDZ49rYA@mail.gmail.com> <CAO42Z2wWSucKNouo0RxNf7pmyPErNk1bVny43qTLY6E333mpcQ@mail.gmail.com> <e41ee3ae-05ef-0a1a-505e-968323b07625@gmail.com> <CAO42Z2x2-WFyxYKpcwtm_z4WiFFf1M5oiW2=j6fXnqgUG1F8DQ@mail.gmail.com> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> <CALx6S35e0krDCLUhUQFws_gSJhtv0m_E_KQkyRQQWO=zL_=vnQ@mail.gmail.com> <CA+b+ERki3bfmt0FarOdNGbVbdU1U99Sucu3NhEZ9q1BnNxUQrw@mail.gmail.com> <CALx6S34fSBycO+1pU8x3konO+6=s9sYWQQaFp36kcHi4HdyxFQ@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 02 Dec 2017 20:31:54 +0100
X-Google-Sender-Auth: 2tMvQl4rZEhn-selYqwoghNKfDM
Message-ID: <CA+b+ERmF2rj4n9mfvG+ANdNjpBXgpMJb63SqSNVQif4cvwaTPQ@mail.gmail.com>
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Tom Herbert <tom@herbertland.com>
Cc: Stefano Salsano <stefano.salsano@uniroma2.it>, Mark Smith <markzzzsmith@gmail.com>, draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="089e08235958b8df99055f608909"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mhPdXsg5VlMWG_gxWOwhQBTslQg>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Dec 2017 19:32:00 -0000

Hi Tom,

> ​​
Thanks for the detail Robert. Has there been any thought into using
> the flow label to switch the packet over alternate paths? That might
> be a zero overhead solution :-)

The issue is not at the node doing the actual repair switching ... the
issue is at the other nodes which must forward the packet to achieve loop
free native forwarding.

So if we use flow label for forwarding now each IPv6 router needs to do
three lookups ... flow label + SRH + dst address or even 4 if you include
src-dst forwarding.

In many cases of IP networks there is actually no need to apply anything to
the packet. That's how LFA works. Here we are just talking about some
topologies where you must augment given topology with directed forwarding
to avoid loops. That is what TI-LFA delivers.

Cheers,
R.


On Sat, Dec 2, 2017 at 8:23 PM, Tom Herbert <tom@herbertland.com> wrote:

> On Sat, Dec 2, 2017 at 11:01 AM, Robert Raszuk <robert@raszuk.net> wrote:
> > Tom,
> >
> >>
> >> However, in that case why not do the
> >> segment routing at the ingress node of the domain in conjuction with
> >> the encapsulation and avoid the complexities needed to make EH
> >> insertion work correctly?
> >
> >
> > Because in this particular case what is being done is a *local repair*.
> > Local means that packets are redirected at the node which first notices
> the
> > failure (usually adjacent to the link or node failure) which is maximum
> > order of 10s of ms. Yes FIBs/data plane of those nodes are programmed
> ahead
> > of failures with backup rewrites too.
> >
> > There is no time to propagate such information in the control plane to
> > ingress such that new/adjusted SRH is imposed to achieve comparable
> repair
> > results. That is happening in parallel to packets already being under
> local
> > protection, but takes 100s of ms or even seconds for all control plane to
> > converge.
> >
> > That is what we call fast connectivity restoration vs protocol
> convergence.
> > Completely different things.
> >
> > So yes there are networks which only use control plane convergence
> OSPF/ISIS
> > or even BGP and do nothing to protect packets locally when failure occurs
> > but those are very bad examples of network design or choice of vendors
> which
> > can not perform local repairs.
> >
> ​​
> Thanks for the detail Robert. Has there been any thought into using
> the flow label to switch the packet over alternate paths? That might
> be a zero overhead solution :-)
>
> Tom
>