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

Stewart Bryant <stewart.bryant@gmail.com> Wed, 11 December 2019 11:50 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 F05A6120227 for <ipv6@ietfa.amsl.com>; Wed, 11 Dec 2019 03:50:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 sLsjyh_vqLZy for <ipv6@ietfa.amsl.com>; Wed, 11 Dec 2019 03:50:20 -0800 (PST)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 4AFA412003F for <6man@ietf.org>; Wed, 11 Dec 2019 03:50:20 -0800 (PST)
Received: by mail-wm1-x32a.google.com with SMTP id a5so977726wmb.0 for <6man@ietf.org>; Wed, 11 Dec 2019 03:50:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mczsfHriZZzimqDQyOq/AkmnGfljsvaqEG/FK/ujBBs=; b=F8CL3lrAqLJsqvLpN1Om0bA5+KJsi4N/L8AYgZzuCtK6Ua2Kc8kEs/w+8TtiJqvHDo nbNMQKSDVGYnyWg3UJVEX5VH3qGX6xJz3BEvF1n3/4W5knT4U2eS3O+8Naq/z2F3YLLY mEeGB5RvnWSWdEmSiFpkURSJ0HO1ALfzXt0R5EZkCsFo5tP/niAyyUy760D4w091Bq2P sZuSSuDb6dOS1rKiKQI5lUfdUJN9bH9a8xkQ3ShDiJBK5P7m05noy0anpXcD25B6hLuu XR1t3YrT7r0II7q4zB/a5snbdJKuKEqZWqzJHSbpRuAdmn6vkMdhYF6MKclxB2h+F1ub ZeQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mczsfHriZZzimqDQyOq/AkmnGfljsvaqEG/FK/ujBBs=; b=AWdrkXpujhu++zEEoeUJ5Bj2aN6NcW+SVRRXDGKjagE374aiL/6dHzy30lTC1Y/PUx HbpFnm+XCDDA1GFc+VYOZjJysNRw2vih6RGmpsuG52Q5Gwl+iJp5m0Pj79RMN29zmwv9 XTy1NGwVPE7fcgQ9vnVg7XnTj2TbxvT6ACQwNXdZWrtxqq+j/P6+Tjdjl4mpltY5/t1u h4JOkuX056oieZf0GlMtK5W+nl3WIOQIFD1Itp3zWz4LfAzGpHZpEsbjTwFxi2HApqpg T064sDBA/7HnsBKHAVGVXAKtIcuectaPffEDMybfm9C+Yx1cFfurlsDMRocGv4Al+glP nWxA==
X-Gm-Message-State: APjAAAXIwDd16tFkeAidCoiiWZaJjC8NowGtXJLeyOFpKyI547Pgu1z1 YvSajqoDUw3z6XA8V39L03s=
X-Google-Smtp-Source: APXvYqyV4s6grpArfXqPkpPG5VGuE4qAx7l+VfVRCYQA0LCkYoMRWThCJLOb902jCwOXTYzL4v3+2A==
X-Received: by 2002:a1c:23d7:: with SMTP id j206mr3070958wmj.39.1576065018737; Wed, 11 Dec 2019 03:50:18 -0800 (PST)
Received: from broadband.bt.com ([2a00:23a8:4140:0:4535:1703:de7c:5c8d]) by smtp.gmail.com with ESMTPSA id i5sm1976066wml.31.2019.12.11.03.50.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Dec 2019 03:50:18 -0800 (PST)
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-Id: <BF05E487-4BE3-45C8-864C-3002C45A55E9@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AC57EBB7-8A45-4F07-9A58-29A03E9E722B"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Subject: Re: What if? [was Re: Extension Header Insertion]
Date: Wed, 11 Dec 2019 11:50:15 +0000
In-Reply-To: <CABNhwV0SpzjPhv0FktMbFHqEPe28AYKOeBiwqfiV7KvE8vkCKg@mail.gmail.com>
Cc: Fernando Gont <fernando@gont.com.ar>, 6man <6man@ietf.org>
To: Gyan Mishra <hayabusagsm@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>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/yLfm12moPglcUZtfTr_HmEDn-mk>
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: Wed, 11 Dec 2019 11:50:23 -0000


> On 11 Dec 2019, at 05:51, Gyan Mishra <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 <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.


> 
> 
> 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