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