Re: [Lsr] Status of draft-ietf-isis-encapsulation-cap

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 15 April 2019 13:46 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA781201B0 for <lsr@ietfa.amsl.com>; Mon, 15 Apr 2019 06:46:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
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 coqTEtr6s-Rh for <lsr@ietfa.amsl.com>; Mon, 15 Apr 2019 06:46:22 -0700 (PDT)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E883F12017E for <lsr@ietf.org>; Mon, 15 Apr 2019 06:46:21 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3FDkCf9004615; Mon, 15 Apr 2019 14:46:12 +0100
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F278D2204A; Mon, 15 Apr 2019 14:46:11 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id DBCFD22044; Mon, 15 Apr 2019 14:46:11 +0100 (BST)
Received: from LAPTOPK7AS653V ([88.128.80.55]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3FDkAH2019092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Apr 2019 14:46:10 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Xiejingrong' <xiejingrong@huawei.com>, bruno.decraene@orange.com
Cc: lsr@ietf.org
References: <07ab01d4f211$d28f75d0$77ae6170$@olddog.co.uk> <20688_1555321601_5CB45301_20688_479_10_53C29892C857584299CBF5D05346208A48A7F702@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <00c801d4f38b$dd1b8900$97529b00$@olddog.co.uk> <16253F7987E4F346823E305D08F9115AAB87DA64@nkgeml514-mbx.china.huawei.com>
In-Reply-To: <16253F7987E4F346823E305D08F9115AAB87DA64@nkgeml514-mbx.china.huawei.com>
Date: Mon, 15 Apr 2019 14:46:10 +0100
Organization: Old Dog Consulting
Message-ID: <00d801d4f391$960674c0$c2135e40$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQD0NtLlSakp+NWuI/HUw8Vhaw/WJAIZYzR6AqkBf3EBonxq+KfLjefQ
Content-Language: en-gb
X-Originating-IP: 88.128.80.55
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24552.006
X-TM-AS-Result: No--30.143-10.0-31-10
X-imss-scan-details: No--30.143-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24552.006
X-TMASE-Result: 10--30.142500-10.000000
X-TMASE-MatchedRID: jFqw+1pFnMzxIbpQ8BhdbJD6BbDN9+jOH181YDtIVaowEhHW5KVAz5yk IGKuKUbZMXEn4M+GcWvPDExIjNkthvnVY0DWsTq3ylAqNTt8FdVQCOsAlaxN723D6f6IpbLIB2p vl8LQRyUfmqo8TBGMnRrDkuJ4pXjhsEBAuoaUqK9c/msUC5wFQUGtrAxy5ENOMQmt6BXma0Ubfm 9/D+tKzVw0YJSZ5iu6PooMqpIGJFm1yIl9DmSDmrmR+C0l9vjVC/ExpXrHizz+k6bllj5vlVPWu s3yxQNWwI+C5sucb2JUFwdbPogKxWlm2w5uC3SGM8ORI7N4NZZq45SsEchYD7bnWJCfJUtj/tR5 54lM1S3rbARY5B8dr/g0zjDfrYUe0g+iOlrNCJPr/EBmiNuXtxkqnRJng/51AVscD1Oo0tAeLmt uLpfaHXGrJR20ZmWcVhe0C5ypfRpF+3SPXMw7TOJOzIOycbNPGEfoClqBl85MSusaE6IwuA29VX bH6XrWkGq/XUjervXn2kBtoLnrklaP+R86SRSSI9sIfEUinBjL0ev0kxsIkzyC5ddG2JcgPCWkg C8RW1Z8RG95DK2B236NNVSqlDnqHre0Rj50ea2puD25aEtgt/HoOMMtqjdO4W5wGTKkLKtNoAwQ UfnUnECJ3aSnZOHwup0JKg5NXJbcWMSpAQ/nrME0HZEwX4582N80QvcF7LhIxvv8SrrEFiEomWj tbfURRKALQU7Ggv9+du6cT3v4uBmc/STmZAwtPkoysAZgcS+Y65eaG0GWH0curAGvdCX+xUskML zDnjGHJjZtN5bEKLz4nfyYESe0fn4iGFMOjcGeAiCmPx4NwFkMvWAuahr85irsTF7QAihrR//aG gC4glOm2gN+nomsxEHRux+uk8irEHfaj14ZyVVoEXK0hBS3
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/TnhbhylJBxdgMDbW3YqZLs0lmvg>
Subject: Re: [Lsr] Status of draft-ietf-isis-encapsulation-cap
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Apr 2019 13:46:24 -0000

Wrong list for this discussion, Jingrong. 
Wrong draft to anchor this discussion to 😊

But anyway, I think you need to read the whole of draft-ietf-mpls-sr-over-ip carefully to see its scope, how it does not compete with SRv6, and how it provides a handy migration strategy.

Thanks,
Adrian

-----Original Message-----
From: Xiejingrong <xiejingrong@huawei.com> 
Sent: 15 April 2019 14:34
To: adrian@olddog.co.uk; bruno.decraene@orange.com
Cc: lsr@ietf.org
Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi Adrian,
Is the intra-AS SR over IP really a key use case for draft-ietf-mpls-sr-over-ip ?
I saw it says for this use case: "Tunneling MPLS into IP provides a technology that enables SR in an IPv4 and/or IPv6 network where the routers do not support SRv6 capabilities ..."
SRv6 may have easier tunneling method, and SR-MPLS may not want to add another 'tunneling' within an IGP network.
Would this draft-ietf-mpls-sr-over-ip be processed better focusing on the clear use case 'Tunnel Between SR-MPLS Sites', but without the dependency of the heavy IGP extension to support the intra-AS deployment of uncertain usecase/cost/tradeoff/.... ?

Thanks
Jingrong

-----Original Message-----
From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Monday, April 15, 2019 9:05 PM
To: bruno.decraene@orange.com
Cc: lsr@ietf.org
Subject: Re: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Nice response, Bruno.
Thanks.
Adrian

-----Original Message-----
From: bruno.decraene@orange.com <bruno.decraene@orange.com>
Sent: 15 April 2019 10:47
To: adrian@olddog.co.uk
Cc: lsr@ietf.org
Subject: RE: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi Adrian,

> On the other hand,
> https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ 
> found its way onto the RFC Editor Queue at around the same date and 
> has
languished
> there ever since.

The OSPF document progressed well. The decision was made to normatively reference the IDR document for some codepoints, mostly because the IDR document was pre-dating.
But then IDR document did not progress that fast and hence the OSPF document is in RFC editor queue waiting for the normative reference (for 538 days i.e. 1,5 years and counting).

> https://datatracker.ietf.org/doc/draft-ietf-isis-encapsulation-cap/ 
> shows
expired in October 2017,

The OSPF document had been significantly updated/rewritten toward the end which required some significant work. Since there were less traction with the IS-IS counterpart, to be honest I did not feel motivated to do the equivalent work for the IS-IS draft.
If there is an interest for the IS-IS draft, we can revive and update it.
OTOH, I'd rather avoid doing the work just to see the WG not progressing it to IESG during last call

I assume (1) that your interest is coming from the IESG review on draft-ietf-mpls-sr-over-ip. draft-ietf-mpls-sr-over-ip is built over the IGP use case and hence relies on IGP advertising the encapsulation capability.
Hence the normative reference, hence the fear the document would stay in the RFC editor queue for some time/ever. I think that this process question is mostly for the IESG. Personally I feel that a pragmatic approach would be to keep OSPF as a normative reference and downgrade IS-IS as informative. That may seem like a strange difference of treatment but the alternative is likely to just "silently" remove the IS-IS reference which would be an even bigger different of treatment.

Regards,

Bruno

(1) Actually, your PS made it clear.

PS:
> Any clues?
Thanks for not asking for the solution. That makes me feel more useful, for the same amount of work ;-)


-----Original Message-----
From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Saturday, April 13, 2019 5:59 PM
To: lsr@ietf.org
Subject: [Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi,

Any clues?

https://datatracker.ietf.org/doc/draft-ietf-isis-encapsulation-cap/ shows expired in October 2017, so I guess that is good and dead.

On the other hand,
https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ found its way onto the RFC Editor Queue at around the same date and has languished there ever since.

Did the ISIS work get replaced by some other draft without the "replaced by"
link being set up?
Was it deemed unnecessary in ISIS?

Thanks,
Adrian (who is trying to get draft-ietf-mpls-sr-over-ip through the IESG and finds a reference to this draft)
--
Fairy tales from North Wales for adults of all ages https://www.feedaread.com/profiles/8604/
Available from your favourite online bookseller.
Or contact me to receive a signed copy by mail.

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

____________________________________________________________________________
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr