Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements
Adrian Farrel <adrian@olddog.co.uk> Thu, 28 April 2022 19:28 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884E1C159A32; Thu, 28 Apr 2022 12:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.894
X-Spam-Level:
X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4xutAdMFHVa; Thu, 28 Apr 2022 12:28:24 -0700 (PDT)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 91ED2C157B43; Thu, 28 Apr 2022 12:28:21 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta5.iomartmail.com (8.14.7/8.14.7) with ESMTP id 23SJSIol023036; Thu, 28 Apr 2022 20:28:18 +0100
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6E5544604B; Thu, 28 Apr 2022 20:28:18 +0100 (BST)
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 56D0046048; Thu, 28 Apr 2022 20:28:18 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS; Thu, 28 Apr 2022 20:28:18 +0100 (BST)
Received: from LAPTOPK7AS653V (229.197.bbplus.pte-ag1.dyn.plus.net [81.174.197.229] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.7/8.14.7) with ESMTP id 23SJSEJP010438 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 Apr 2022 20:28:16 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Loa Andersson' <loa@pi.nu>, mpls@ietf.org, draft-bocci-mpls-miad-adi-requirements@ietf.org
Cc: pals-chairs@ietf.org, mpls-chairs@ietf.org, 'DetNet Chairs' <detnet-chairs@ietf.org>
References: <402e03c9-9c20-685e-937a-13b5a3ebca59@pi.nu>
In-Reply-To: <402e03c9-9c20-685e-937a-13b5a3ebca59@pi.nu>
Date: Thu, 28 Apr 2022 20:28:14 +0100
Organization: Old Dog Consulting
Message-ID: <07d201d85b36$1d30d210$57927630$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGk/vB1M8iCoQf/LnrgV17u9Q1eVK1qt6Pg
Content-Language: en-gb
X-Originating-IP: 81.174.197.229
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-26862.002
X-TM-AS-Result: No--14.532-10.0-31-10
X-imss-scan-details: No--14.532-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-26862.002
X-TMASE-Result: 10--14.532000-10.000000
X-TMASE-MatchedRID: jFqw+1pFnMzxIbpQ8BhdbN5x7RpGJf1asBSA1tuZVSZQKAQSutQYXH4b +EgKGbJqWTTOHRboyY4VPEime2+RVR63VPG+eA2DL7p//vLv4bNBHuVYxc8DW89MhHp9AQ+0F6O OkTiGnXt7nHGWdZqBL6ldHs0DobMic33gkrfTLYjl2CNM+DA49O7vDgdsiz84wHVtPyT+7lrTvN pVkSD4M4u4hNdqgEVRUHKwBt1L3xNBOCN7lVO5na5i3jK3KDOoBgA+oehWZhFJBncGyDjWQMQGm OjBWFRHumrocKW8orz+6fCb9w0onQjvZ5lKqVOEF+qQpCWTUjk3kwkGG5XLt6MVwpOQMj2MwtUW ziB5M+7lkd2q4DAqgV4oa9JzOqAUfXwFf1+egQUXfBDRy7VtMyH2Y0Xxk8nYmG9h0TAHW4uqY6L E/Ty1waKcIuKz/w3EbE7ErMdbche9/Owsp5GiPF/ZJ0h1vLl1Q/2UjISFQXCjc9iwjSbbBP+4ZH mr4Mk/iCqY0GwZTbuO7tGf7tMEr2w6gN4deqbtx7+NomOZVWVzwrLSuuC0kkS0FpbI+14Tr8Axv v/SiGPn8XHQWddtBJJ28HhYr7Ljqf8Hy2aCI2nEOJqSsn5KmaIazKtJxIUHN2zK9lb+labU1Xog wQ8ZWm9EqJIKFjbxT5SEEfSopVLZZREXUuleLgrcxrzwsv5u5bMmdOYs/G/ntrWw+boJIQGysK9 /BYgOkD7dBt4dE2kJMY3Z+ARFrA3/BHoVlrMzhMGTNuQTHbPWN3XQ/7wsT5ujV1Lo6krNvqAJrx 96r10f3OLeRP8iXgnCAwcXoYWJ+O6DsIN3+OeeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47g54tgWF 1SNbnQdJ7XfU86e4kYXbobxJbLyU/oX+tpNmPoLEnltozQn3jm0Co0WS/oMoYsUBF7mYwMEmntW +97BgeiPEH0x1iUJK2MK45H+GA==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/y-7wzvt0P85TnNOAa-4LvrbGgnY>
Subject: Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2022 19:28:28 -0000
Hi Loa, All, There's a really long thread about this adoption poll. Rather than sift it (the chairs can do that), I'm reviewing and responding to the poll from a clean start. I have read the -04 revision of this draft. Tl;dr. I think that there is merit in the MPLS working group examining this topic, and that examination should include discussion of the requirements. In that case, I think this document is a fair enough starting point for that work so could be adopted. That said, there is some "stuff" that might need to be debated before we get too excited about all of this... 1. I think the proposal here falls in the scope of "Semantic Routing". That is, adding information to packets so that the forwarding decisions may be enhanced to act not just on the destination address or next hop label, but also on the additional information. The precise forwarding action may be known by the forwarders by definition (such as a protocol specification), installed by a routing engine according to a routing algorithm acting on information exchanged by routing protocols, or programmed into the forwarder from a management or orchestration system. We wrote an introduction to the idea of Semantic Routing (https://datatracker.ietf.org/doc/draft-farrel-irtf-introduction-to-semantic -routing/) which you can look at if you want some context. We also set out to examine the challenges and concerns introduced by Semantic Routing in https://datatracker.ietf.org/doc/draft-king-irtf-challenges-in-routing/ and I think it would be good if this work was calibrated against those challenges. 2. I would think that a more detailed an understanding of the use cases is needed before moving ahead with the requirements. I wouldn't go as far as saying that the use cases need to be referenced normatively, but I do think they need a little more attention from the WG to motivate actually adopting this work. That is, this document shows what we might need to do, but without the use cases, we would be doing it "because we can" and "because it might be useful one day." Those are not, I think really good reasons to make fairly substantial changes to deployed forwarding paradigms. This is not to say that I dispute that there may be some valuable use cases, but that the WG needs to agree which ones are important in order to be sure that the requirements are on target. 3. I'm puzzled that some of the text in this document appears to limit itself to cases that require ancillary data, while other parts also consider the requirements for network functions that don't require ancillary data, but do still need to be encoded in the label stack in some way. I suspect this is just editorial, but while the document title is "Requirements for MPLS Network Action Indicators and MPLS Ancillary Data" the Abstract says "This draft specifies requirements for indicators in the MPLS label stack to support ancillary data in the packet and high level requirements on that ancillary data," and the Introduction seems entirely focused on the ancillary data case. It would be good to be clear, at the point of adoption, which way we are jumping on this question. https://datatracker.ietf.org/doc/draft-andersson-mpls-mna-fwk/ seems to be fully behind network actions some of which may also require ancillary data. Perhaps this document should reference that one for additional information? The rest of my comments (below) are small fry. I'm not really reviewing the technical details of the individual requirements because the WG would work on all of them if it chooses to adopt. Best, Adrian === I hope, if adopted, the filename can be adjusted to use MRN not MIAD-ADI. --- Abstract This work is the product of the IETF MPLS Open Design Team. Before posting as a Working Group draft, this sentence needs to be removed. It's OK to say something in the Acknowledgements. --- Abstract The term "application data" may be (is) confusing. While you probably mean it to imply an application of MPLS, it may be confused with the type of application that runs end-to-end (i.e., on a host). Although, reading some of the text, it does feel like some of the time you *are* intending to imply that the application software may somehow be able to provide the ancillary data that is ultimately carried by MPLS. I think, in the Abstract, you could say... based on ancillary data that may be carried in or below the bottom of the label stack. ...but you should probably look through the rest of the text and consider the use of the word "application." Maybe one approach would be to specifically call out the term near the top of the document in order to correctly set the context. --- 1. is then processed using mechanisms implemented by intermediate and/or egress LSRs that comply with the MPLS base architecture and potentially its extensions, including (but not limited to) [RFC3031], [RFC3032], [RFC6790]. This sounds like the mechanisms to process the ancillary data are already specified in those RFCs, but (of course) that's not the case. You are probably making a point about the nodes being "MPLS" and also saying something about backward compatibility of the mechanism. But it should be clear that only nodes that contain new functionality will be able to recognise and process ancillary data. --- 1. This draft specifies Say 'document' so that you are future-proofed for publication as an RFC. --- 1.1 s/an Label/a Label/ s/perfomed/performed/ --- 1.1 o Network Action: An operation to be performed on a packet. A network action may affect router state, packet forwarding, or it may affect the packet in some other way. If the operation affects router state, is it really performed on the packet? --- 1.1 o Network Action Indication (NAI): An indication in the packet that a certain network action is to be perfomed. There may be associated ancillary data in the packet. o Network Action Sub-Stack (NAS): A set of related, contiguous Label Stack Entries (LSEs). The first LSE contains the NAI. The TC and TTL values in the sub- stack may be redefined. The first bullet simply says that the NAI is "in the packet", but the second bullet goes on to define where/how it is carried. I would say that it is totally irrelevant to the *requirements* how the NAI is encoded/carried (although there may be some requirements that limit the options). But I note that there is no further mention of the NAS or of a "sub-stack". I suggest removing this second bullet. --- 1.1 o In-Stack Data: Any data within the MPLS label stack including the outer LSE and the bottom of stack (the LSE with the S-bit set). o Post-Stack Data: Any data beyond the LSE with the S-Bit set, but before the first octet of the user payload. This document does not prescribe whether post-stack data precedes or follows any other protocol structure such as a control word or associated channel header (ACH). Does "any data" mean "any ancillary data"? --- 1.2 s/number of new proposals/number of proposals/ --- 1.2 for example In-situ OAM and Service Function Chaining (SFC) Might benefit from references for iOAM and SFC. --- 1.2 [I-D.song-mpls-extension-header] summarises some of the issues with existing solutions to address these new applications (note that this document draws on the requirements and issues without endorsing a specific solution from [I-D.song-mpls-extension-header]): This gives more emphasis to the referenced draft than I think you intend. If you intend that people read that draft to see the issues, it is a normative reference. But if you are just mentioning it and have pulled the information into this document, then you need to reduce the emphasis. How about... [I-D.song-mpls-extension-header] sets out some of the issues in how existing solutions address these new applications. This document draws on the requirements and issues noted in that document without endorsing any specific solution. --- Section 2 While I understand the desire to express the requirements in definitive language, BCP14 is not about requirements. Rather it is intended to describe implementation behaviours. A way around this that is often used is to include a subsequent paragraph such as... Although this document is not a protocol specification, this convention is adopted for clarity of description of requirements. See, for example, RFC 4139, RFC 4687, or RFC 5862. --- 3.2 s/and indicator/an indicator/ --- 3.2 2. An MPLS Network Action MUST specify whether ancillary data is required in the label stack and/or post-stack data. Do you mean this, or do you mean that this must be specified in the documentation of the NA? --- 3.2 3. Any solution MUST respect the principle that Special Purpose Labels are the mechanism of last resort and therefore must minimise the number of new SPLs that are allocated. Presumably a minimum here would be zero? --- 3.2 bullet 5 s/in the way in a way/in a way/ --- 3.2 Bullet 10 is a wholly contained subset of bullet 5. Actually, bullet 10 is a wholly contained subset of bullet 6. Makes me think that bullets 5 and 6 possibly say the same thing as each other. --- 3.2 11. NAIs SHOULD be supported for both P2P and P2MP paths, but any specific NAI may only be supported for one or the other. Really? You can't have an NAI that is equally applicable for both P2P and P2MP? Seems an odd restriction to impose. --- 3.2 15. NAIs can only be inserted at LERs, but MAY be processed at LSRs and LERs. If it is required to insert an NAI at a transit LSR on an LSP, then a new label stack MUST be pushed. What does it mean to push a new label stack? If you mean that we should support "MPLS in MPLS" encapsulation so that the packet has two bottom of stack bits set, I should point out that this was previously discussed and abandoned because the presence of an LSE immediately after a set bottom of stack bit was considered unacceptable because of the assumptions made by existing hardware about what follows the bottom of stack. --- 3.2 19. Any specification of a solution that inserts or modifies the NAI MUST discuss the possible ECMP consequences. This seems to at least partially contradict 3.2/15 It is also not clear what it means "to modify an indication in the packet that a certain network action is to be performed." I guess it means to remove the NAI? --- 3.3/1 is surely already covered by 3.3/4 --- 3.3/3 seems to be unnecessary given 3.3/1 -----Original Message----- From: mpls <mpls-bounces@ietf.org> On Behalf Of Loa Andersson Sent: 13 April 2022 10:29 To: mpls@ietf.org; draft-bocci-mpls-miad-adi-requirements@ietf.org Cc: pals-chairs@ietf.org; mpls-chairs@ietf.org; DetNet Chairs <detnet-chairs@ietf.org> Subject: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements Working Group, This is to start a two week poll on adopting poll on draft-bocci-mpls-miad-adi-requirements as a MPLS working group document. THough we normally do two weeks pretty stric, in this case I have allowed a couple of extra days due to holliday season. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. There is no IPRs disclosure against this document. The both authors have stated on the MPLS wg mailing list that they are unaware of any IPRs that relates to this document. The working group adoption poll ends May 2, 2022. /Loa -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls
- [mpls] working group adoption poll on draft-bocci… Loa Andersson
- Re: [mpls] working group adoption poll on draft-b… Andrew G. Malis
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Greg Mirsky
- Re: [mpls] working group adoption poll on draft-b… Tony Li
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… xiao.min2
- Re: [mpls] working group adoption poll on draft-b… Yingzhen Qu
- Re: [mpls] working group adoption poll on draft-b… Jeff Tantsura
- Re: [mpls] working group adoption poll on draft-b… Gyan Mishra
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… Gyan Mishra
- Re: [mpls] working group adoption poll on draft-b… Gyan Mishra
- Re: [mpls] working group adoption poll on draft-b… Tony Li
- Re: [mpls] working group adoption poll on draft-b… Greg Mirsky
- Re: [mpls] working group adoption poll on draft-b… Robert Raszuk
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Robert Raszuk
- Re: [mpls] working group adoption poll on draft-b… Greg Mirsky
- Re: [mpls] working group adoption poll on draft-b… Robert Raszuk
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… Tony Li
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… Tony Li
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… Tony Li
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Stewart Bryant
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Stewart Bryant
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… Greg Mirsky
- Re: [mpls] working group adoption poll on draft-b… Robert Raszuk
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… Robert Raszuk
- Re: [mpls] working group adoption poll on draft-b… Greg Mirsky
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Tony Li
- Re: [mpls] working group adoption poll on draft-b… Greg Mirsky
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Tony Li
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Adrian Farrel
- Re: [mpls] working group adoption poll on draft-b… Luay Jalil
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- [mpls] Closed, : working group adoption poll on d… Loa Andersson