Re: What if? [was Re: Extension Header Insertion]

Stewart Bryant <stewart.bryant@gmail.com> Thu, 12 December 2019 12:40 UTC

Return-Path: <stewart.bryant@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 1AB3A12003F for <ipv6@ietfa.amsl.com>; Thu, 12 Dec 2019 04:40:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 1LdEKPs2NU-w for <ipv6@ietfa.amsl.com>; Thu, 12 Dec 2019 04:40:08 -0800 (PST)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 0B4F412003E for <6man@ietf.org>; Thu, 12 Dec 2019 04:40:08 -0800 (PST)
Received: by mail-wr1-x42b.google.com with SMTP id y17so2577553wrh.5 for <6man@ietf.org>; Thu, 12 Dec 2019 04:40:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=egkvV2bdZg6R3kQNWOg5IvgjeAc5vSJ1Ne75GkJS+v0=; b=T/174PQdsTY9oIUEocsyPoD/vZDk2HfmxPWI1KFFaIVTNJz4RcgR41zNsntYOphBNI u6SYtJPW3+p1XTqcW+lA3sMiNEyiRyQJTaZ2lFpiYrn74AtFSUvz96r0424INjoJF8Ha 7vDrD8Xe/dGhjNrD3pdV8Gmi9W8mNrxsN4OG1jSzkFHYXLyD+O5aNAqDWFnMIDSVvWwq GB/PfiGPhQlvV0MqvouJURtCIekmRcMd/ppmAaFaIw+3MS6dK7OxR9pQRSwgbmUDiNYV /BIYfdGFFwXzpxjvk+NZvgNVO7ygJjdDzIXBMWUeM5YgmTXklRvEYvnW9uqZrp1D8MZL Jg4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=egkvV2bdZg6R3kQNWOg5IvgjeAc5vSJ1Ne75GkJS+v0=; b=BCCJKAq7E/77mcyRxwIuXFVSe+RcMoSi/FjDSk1cL/TBc//9C6p+D0yvL/CxphFcV5 Ly4GTERTYbFq786ThmgrjkQtvsQWqtuFHD2xs3lecn3ERj2TdWRClqSUNPkoBeKpDDWO YJtiYSUUSwbtxidgJDsZ3or8Jfa6UgotsWzBoO6e1Q606vAGCj3Oorwq7y86PgNo7skI 46Lc/vTiY+/pgRZWTdsmabob8Lp4iorgSpsh4iSxqSb0qdkXYShkrHLw6JeJ8Iy81+Pi G3mBb2lefCLDc3AgRln7JG6bBhd0J6P+7FB9yhANnj67uNJN8xMLTzZ4VnrOEUctQdYk v5Bg==
X-Gm-Message-State: APjAAAVcX58vQ1Rl5qWGH2ahL+RlYPd5oZuDRZNFlU18a6tc3JNCtL/O 629QPJ0llulgHguUxXZ+n7HaMZ90
X-Google-Smtp-Source: APXvYqx5wbCwSBwOZDF39+pp9tpWJdgkDEmBsLbsRujouh9iloF8+WhT5W46q4JfcK11vO9JlA4zlw==
X-Received: by 2002:adf:f2d0:: with SMTP id d16mr5940845wrp.110.1576154406285; Thu, 12 Dec 2019 04:40:06 -0800 (PST)
Received: from broadband.bt.com ([2a00:23a8:4140:0:6d9b:f7f0:9136:c16a]) by smtp.gmail.com with ESMTPSA id d10sm5898134wrw.64.2019.12.12.04.40.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Dec 2019 04:40:05 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Subject: Re: What if? [was Re: Extension Header Insertion]
From: Stewart Bryant <stewart.bryant@gmail.com>
In-Reply-To: <15debe4c-8959-e083-324a-cba9136ca4ef@gmail.com>
Date: Thu, 12 Dec 2019 12:40:03 +0000
Cc: Gyan Mishra <hayabusagsm@gmail.com>, 6man <6man@ietf.org>, Fernando Gont <fernando@gont.com.ar>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A0363F15-34A7-4846-A114-AA6D65D24DB5@gmail.com>
References: <BN7PR05MB5699D9BA988F96E2F41CD390AE580@BN7PR05MB5699.namprd05.prod.outlook.com> <00dc01d5ae73$c361b450$4a251cf0$@olddog.co.uk> <dbcdeb1a-0091-da2b-20df-d991e6c06091@gmail.com> <9bc47200-4fea-37ce-0ede-cbf6a5f70ea9@gmail.com> <99e4bdd0-711d-7406-d3bf-786b0238c1e7@gont.com.ar> <44e6225f-97bc-37ba-c13e-b7bafa446fcc@gmail.com> <A5439DC7-5B11-40E9-BC32-6E675E2EDC20@cisco.com> <7a0b4be6-9149-29d8-c253-19127bfcef14@gmail.com> <CAHw9_iKDn-LLOPpyEJk8=5-8K5q0pvNeLXn58-JPTihAxE5fEw@mail.gmail.com> <4ee7b283-b2c6-13ae-0c93-6a90a030a395@gont.com.ar> <CABNhwV0SpzjPhv0FktMbFHqEPe28AYKOeBiwqfiV7KvE8vkCKg@mail.gmail.com> <BF05E487-4BE3-45C8-864C-3002C45A55E9@gmail.com> <15debe4c-8959-e083-324a-cba9136ca4ef@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/SMXiV1WtYDhWvfSaDx6oos6trlY>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 12 Dec 2019 12:40:10 -0000


> On 11 Dec 2019, at 19:29, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 12-Dec-19 00:50, Stewart Bryant wrote:
>> 
>> 
>>> On 11 Dec 2019, at 05:51, Gyan Mishra <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>> wrote:
>>> 
>>> Hi Warren,
>>> 
>>> Just a thought.
>>> 
>>> There have been other game changer technologies that have come up in the past that really require a lot of collaboration between all WG silo’s namely mpls for starters and now SR which has I am guessing millions poured into by vendors across the globe to get on the band wagon which will be the eventual replacement of mpls.
>>> 
>>> Not to derail my thoughts — SR for example just as with MPLS involved many routing and internet area WGs such as rtgwg, lsr, Bess, teas to name a few.  There is a lot of complexity in development and maintaining IETF standards when there are so many very complex inter dependencies between WGs for these types of industry evolution type protocols that pave the way for the future.
>>> 
>>> To that point the topic of TI-LFA which we have talked about in many threads.  This draft is owned by rtgwg. I don’t think the authors of this draft being a dependency WG of the WG owner of the main protocol being developed “spring” had knowledge that they were in violation of RFC 8200.  I think that is part of the root problem with the process flow in development of a very complex protocol that spans almost every IETF WG.
>>> 
>>> TI-LFA draft:
>>> https://tools.ietf.org/pdf/draft-ietf-rtgwg-segment-routing-ti-lfa-01.pdf 
>>> 
>>> Bottom of page 3-
>>> Thanks to SR, TI-LFA does not require the establishment of TLDP sessions with remote nodes in order to take advantage of the applicability of remote LFAs (RLFA) [RFC7490][RFC7916] or remote LFAs with directed forwarding (DLFA)[RFC5714].
>> 
>> The TI-LFA draft is data-plane agnostic.
>> 
>> How the draft maps to the dataplane is up to the dataplane designers.
>> 
>> With an MPLS dataplane it all works and conforms to the MPLS architecture.
>> 
>> It is up to the IP dataplane designers to ensure that it conforms to the IP dataplane architecture.
> 
> Very true. MPLS allows label stacking. IPv6 does not (intentionally) allow
> routing header stacking, but it does allow IPv6-in-IPv6 stacking, a.k.a.
> encapsulation.
> 
>   Brian

.. and  that is an unconditionally safe approach.

EH insertion is an optimisation and as with all optimisations we may not know of fully understand the consequences for a long time.

- Stewart


> 
>> 
>> 
>>> 
>>> 
>>> I mentioned in on of the threads that MPLS ldp RLFA (remote LFA) requires an MPLS label to be added to ldp tunnel to PQ space end node in a  circle topology case where PLR node junction physical bypass LFA  node does not exist.  Since the backup path programmed is a post convergence path with stateless nodes with SRv6, 6in6 encapsulation at the PLR node  is not technically necessary.  
>>> 
>>> If the rtgwg new they were in violation of RFC 8200 they would have gone the same path as ldp RLFA and added in the encapsulation into the draft.  
>> 
>> As far as I can see the document you cite says nothing about IPv6 and thus cannot violate RFC8200, or have I missed something in the text?
>> 
>> You mention the congruence between the repair path and the post convergence path. As far as I can see this is loop mitigation in the down case (it says nothing about loop mitigation in the up case which is also an important problem). Anyway, I stress that I have not yet seen a formal proof that it is unconditional loop avoiding as post convergence the packets may not go via the PLR and hence may not follow the TI-LFA path. I have asked before and have not yet seen such a proof (I apologies if I have missed it) and look forward to reading it.
>> 
>> Best regards
>> 
>> Stewart
>> 
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>> 
>