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

Stewart Bryant <stewart.bryant@gmail.com> Mon, 23 December 2019 10:29 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFF912008A for <rtgwg@ietfa.amsl.com>; Mon, 23 Dec 2019 02:29:13 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 rbohG4w-5d6C for <rtgwg@ietfa.amsl.com>; Mon, 23 Dec 2019 02:29:11 -0800 (PST)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 7C7E412001E for <rtgwg@ietf.org>; Mon, 23 Dec 2019 02:29:11 -0800 (PST)
Received: by mail-wm1-x32b.google.com with SMTP id f129so15695370wmf.2 for <rtgwg@ietf.org>; Mon, 23 Dec 2019 02:29:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=yUUqWIGOKvHDVEbuEDJaq1wUSFHACa/AfNlftHkB/bg=; b=qQG63+Lfx3t0nG+W+SS0HUrCK9YAFR/IYCtM4TLxC+SeMNDC1/uWrwVPRR6CCZ6HgA zvEKRWbErSU6FnE5Os31mRVjGvU/fHkrplX1pC4QCVHAtYVHKCAaYShos78JuVPKf3tM goH8j6uZkeqOMq5J7/qzEgwjEw4fPB/megppuqCcUS0LO9vI8r02FyNmXMhn10w/PKhg At43GAo5wau9tl6zhBtNuw1QxqBibYzR3KoJP1up27ybLkTkIrEZ1mKw38ybUa+SmQ8g uMxchIgABvioPY+Sqh/A1KXVOZNgJOJjMi6g2wiP1hokyHY1TxU4eHAQhnUp2O0P0HLG IDSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=yUUqWIGOKvHDVEbuEDJaq1wUSFHACa/AfNlftHkB/bg=; b=RCxQMBytn5Ri4V49T3gH6Sk2VMptFmNKo0UihKBMGAqnn2p5y89K6jIb0ymHibeK1p qXWQNVourbAenalreXZ+pQGiHDfkkQVp80Ytt8M45jUUPgdU2TgxPGwEUFz0RcMUq7zZ NzUpl/eET33ep/QKjjtd0JUF/A9tmeH+lugq3n/0vGewPiJzltr8Ye9TxIg8mSKiaoPZ ktW5hWymABj6Fum3QvJtsC+3tMjV0XfvkB0ZUybiCP+BRuAyyw56htJ5R0i6pqpTem1y 7e27lOXntyAd3JV7mNhCgDITPdf0kV2fyPnOE2UFhzy2PTdJq4VSPd3B567qPF3Nmy+y NM2w==
X-Gm-Message-State: APjAAAW45xbM0ETgGJDCbG6ylESmmX8fprmqqnNMkuIhrWQ+bkp3k/g5 R0Wap5IBbYxk52LKAoTSoGX2kaJWGL0=
X-Google-Smtp-Source: APXvYqyGaS81joJbdTGLYBaJfr5DuWtXFo2euNGW961RH4BTv7vic0/B2ejXITb3q8mZcD/Gf+u5vw==
X-Received: by 2002:a05:600c:cd:: with SMTP id u13mr30565798wmm.24.1577096949698; Mon, 23 Dec 2019 02:29:09 -0800 (PST)
Received: from broadband.bt.com ([2a00:23a8:4140:0:7094:de33:6846:7740]) by smtp.gmail.com with ESMTPSA id p5sm19872067wrt.79.2019.12.23.02.29.08 for <rtgwg@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Dec 2019 02:29:08 -0800 (PST)
From: Stewart Bryant <stewart.bryant@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6BF0A8CF-C73F-4044-8273-0474EFD5E4C2"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Subject: Fwd: What if? [was Re: Extension Header Insertion]
Message-Id: <60815754-63F6-4DB5-88C6-8145EC3DC41D@gmail.com>
References: <8A548DB7-8A3C-4855-BBB6-E368F98F6CD3@gmail.com>
To: RTGWG <rtgwg@ietf.org>
Date: Mon, 23 Dec 2019 10:29:07 +0000
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/NJU9XweFjZW3qVB-e4LUPFiDBA8>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Dec 2019 10:29:14 -0000

From a discussion on the 6man list.

Forwarding as requested by the chair as RTGWG owns the TI-LFA design.

Stewart
> 
> 
>> On Dec 11, 2019, at 03:50, Stewart Bryant <stewart.bryant@gmail.com> 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 <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
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------