Subject: Re: [mpls] To be posted draft draft-andersson-mpls-miad-fwk (Loa / Stewart)

From: Loa Andersson <[email-masked]>
Date: Tue, 22 Feb 2022 11:01:09 +0800

Tarek,

Seems to be a reasonable idea. What is posted below is the state of the 
thinking on the structure one spin after the the DT meeting 2033-07-17.

None of this is set in stone.

Since Matthew is on vacation this week, and Stewart and me are busy, I 
like anyone that can contribute text to do so. I will start up a ID and 
populate with what I get.

It is still my intention to post a draft for the IETF113
.

/Loa

On 2022-02-19 01:21, Tarek Saad wrote:
> Hi Loa and Stewart,
> 
>>> to be posted draft draft-andersson-mpls-miad-fwk (Loa / Stewart).
> 
> In the last Open MPLS DT meeting, you’ve shared a tentative table of 
> content for the work you intend to cover in the above draft. Is it 
> possible to share this TOC on the WG mailing list, so we can engage the 
> WG to chime if required (as was pointed out during the meeting).
> 
> Regards,
> 
> Tarek
> 

                      MPLS MIAD Framework structure thoughts

Abstract

    This document specifies an architectural framework for the
    application of the MPLS Indicator and Ancillary Data (MIAD)
    technologies.  MIAD techmologies are used to indicate actions (I) for
    LSPs and/or packets and to transfer data needed for these actions
    (AD).

    The document describes a common set of protocol functions and
    information elements - the MPLS Indicartor and Ancillary Data -
    supporting additional operational models and capabilities of MPLS
    netwroks that support these functions.  Some of these functions are
    defined in existing MPLS specifications, while others require
    extensions to existing specifications to meet the requirements in the
    MIAD requirement specification.

    This document is the the result of work started in MPLS Open Desgign
    Team, with participation by the MPLS, PALS and DETNET working groups.

1.  Introduction

    This document discusses how flag fields ancillary data and IANA
    registries for the data coul be desinged.

    Maybe expand the abstract a bit and give some of the developement we
    seen in the MPLS forwarding model, e.g. original model, first nible,
    Pseudowire ACH, GACH and MIAD.

1.1.  Requirement Language

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
    "OPTIONAL" in this document are to be interpreted as described in
    BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
    capitals, as shown here.

    This document is intended to become an Informational RFC, it is not
    clear that we will need Section 1.1 "Requirement Language".  We will
    leave it in for the time being and take the
    decision to remove or not closer to the Publication Request.

2.  Normative Definitions

    text to be added, prime candidates to be discussed are AD and ADI,
    not least explaining the differences.

3.  Terminology

3.1.  Abbreviations

    +--------------+------------+---------------------------+-----------+
    | Abbreviation | Meaning    | Reference                 | Note      |
    +--------------+------------+---------------------------+-----------+
    | AD           | Ancillary  | draft-bocci-mpls-miad-    | place     |
    |              | Data       | adi-requirements          | holder    |
    |              |            |                           |           |
    | ADI          | Ancillary  | draft-bocci-mpls-miad-    |           |
    |              | Data       | adi-requirements          |           |
    |              | Indicator  |                           |           |
    |              |            |                           |           |
    | E2E          | End to end | In the MIAD context this  |           |
    |              |            | document.                 |           |
    |              |            |                           |           |
    | HBH          | Hop by hop | In the MIAD context this  |           |
    |              |            | document.                 |           |
    |              |            |                           |           |
    | ISD          | In stack   | draft-bocci-mpls-miad-    |           |
    |              | data       | adi-requirements          |           |
    |              |            |                           |           |
    | LSE          | Label      | RFC 3032 [RFC3032]        |           |
    |              | Stack      |                           |           |
    |              | Entry      |                           |           |
    |              |            |                           |           |
    | MIAD         | MPLS       | MPLS Open DT wiki and     | MIAD is   |
    |              | Indicators | this documnent            | the name  |
    |              | and        |                           | of both   |
    |              | Ancillary  |                           | this tech |
    |              | Data       |                           | nology    |
    |              |            |                           | technlogy |
    |              |            |                           | and the   |
    |              |            |                           | project d |
    |              |            |                           | eveloping |
    |              |            |                           | this part |
    |              |            |                           | of the    |
    |              |            |                           | MPLS arch |
    |              |            |                           | itecture  |
    |              |            |                           |           |
    | PSD          | Post stack | draft-bocci-mpls-miad-    |           |
    |              | data       | adi-requirements          |           |
    +--------------+------------+---------------------------+-----------+

                           Table 1: Abbreviations

3.2.  Concepts used in this Framework

    +------------+--------------------------------+--------------+------+
    | Concept    | Meaning                        | Reference    | Note |
    +------------+--------------------------------+--------------+------+
    | E2E        | E2E im MIAD context is defined | this         | -    |
    | concept    | in...                          | document     |      |
    |            |                                |              |      |
    | concept    | free text                      | this         | -    |
    |            |                                | document     |      |
    +------------+--------------------------------+--------------+------+

                              Table 2: Concepts

4.  Methods to carry Ancillary Data Indicators

    Several possibilities to carry ADI's has been discussed in MIAD
    drafts and in the MPLS Open DT.

4.1.  existing base-SPL

4.2.  new base SPL

4.3.  new extend SPL

5.  Meth0d chosen by the working group

    o  documenting the wg decision

6.  Tpes of AD

6.1.  In Stack Data (ISD)

    a bit of explnatory text

6.2.  Post Stack Data (PSD)

    a bit of explanatory text

6.3.  Implicit DataNote that we are chang the earlier "No Data" (NoD),
       implicit

    without creating an abbreviation.  ID would be to close o ISD.

7.  ADI details

7.1. Hop by Hop (HBH)

7.2.  End to End (E2E)

7.3.  Initiate action at a specific single node

    We are looking to see if this is needed.

8.  Flag Field
We have a general idea. What sshould be thought about is to leave the 
TC-filed, the S-bit and TTL unchanged, and use the 32bits  (really 30 
since the x bit and s bit are taken) of a new LSE as flag filed.

9.  ADI specification rules

    Guidance what to include in an IANA section

10.  Ancillary Data

    Structure, encoding, allocation of identifiers.  Matters of sequence
    / priority.  Instances of a single type of AD

11.  Packet Structure

12.  Security Considerations

13.  Managment Considerations

14.  MPLS Forwarding model

    This section here to basically to have a place holder where to
    discuss the development of the MPLS forwrding model.  It might be
    removed.

14.1.  Orginal Model

     +-----------------------------------------------------------------+
     |                                                                 |
     |  +---------------------+                                        |
     |  | +------------+      |                                        |
     |  | | MPLS Label |  LSE |                                        |
     |  | +---|--------+      |                                        |
     |  +-----|---------------+                                        |
     |        |                                                        |
     |        |  +----------------------+                              |
     |        |  |                  FIB |                              |
     |        |  |                      |                              |
     |        |  |     +------------+   |     +----------------------+ |
     |        +------->|FIB Entry   |-----+-->|Forwarding Code       | |
     |           |     +------------+   | |   +----------------------+ |
     |           +----------------------| |                            |
     |                                  | |   +----------------------+ |
     |                                    +-->|Forwarding Parameters | |
     |                                        +----------------------+ |
     |                                                                 |
     |                                                                 |
     | LSE = Label Stack Entry (what many people call a label)         |
     | FIB = Forwarding Information (date)Base                         |
     +-----------------------------------------------------------------+

                  Figure 1: MPLS Original Forwarding Model

15.  IANA Considerations

    This document does not make any allocations of code points from IANA
    registries.

    As long as the "does not make any allocvations ... from IANA is true,
    this pragraphe shoukd be removed by the RFC-Editor.  If it turns out
    that we will need to fp IANA allocation, a propser IANA section will
    be added.

-- 
Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Feb 2022 22:42:20 -0500

Thank you for posting this.

May I make a small suggestion?  Pleaes, use some other term than 
End-to-End (E2E).  Edge-to-Edge (Ed2Ed or some other similar 
abbreviation) would work. E2E is already abused in too many contexts. 
Can we please not make it worse.

Thank you,
Joel

On 2/21/2022 10:01 PM, Loa Andersson wrote:
>> possible to share this TOC on the WG mailing list, so we can engage 
>> the WG to chime if required (as was pointed out during the meeting).
>>
>> Regards,
>>
>> Tarek
>>
> 
>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 22 Feb 2022 13:08:36 +0800

Joel,

I’m don’t mind changing, but is a bit lost on what to do. Do you have a proposal? Would “Ingress to Egress” (I2E) work?

/Loa 

Sent from my iPhone

> On 22 Feb 2022, at 11:42, Joel M. Halpern <[email-masked]> wrote:
> 
> May I make a small suggestion?  Pleaes, use some other term than End-to-End (E2E).  Edge-to-Edge (Ed2Ed or some other similar abbreviation) would work. E2E is already abused in too many contexts. Can we please not make it worse.
> 
> Thank you,
> Joel
> 
>> Seems to be a reasonable idea. What is posted below is the state of the thinking on the structure one spin after the the DT meeting 2033-07-17.
>> Since Matthew is on vacation this week, and Stewart and me are busy, I like anyone that can contribute text to do so. I will start up a ID and populate with what I get.
>>> In the last Open MPLS DT meeting, you’ve shared a tentative table of content for the work you intend to cover in the above draft. Is it possible to share this TOC on the WG mailing list, so we can engage the WG to chime if required (as was pointed out during the meeting).
>>> 
>>> Regards,
>>> 
>>> Tarek
>>> 
>> We have a general idea. What sshould be thought about is to leave the TC-filed, the S-bit and TTL unchanged, and use the 32bits  (really 30 since the x bit and s bit are taken) of a new LSE as flag filed.
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "jmh.direct" <[email-masked]>
Date: Tue, 22 Feb 2022 01:28:00 -0500

Yes, "ingress2egress" (I2E) would work for me.  I am sure there are many workable choices. Yours,JoelSent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone
-------- Original message --------From: Loa Andersson <[email-masked]> Date: 2/22/22  12:08 AM  (GMT-05:00) To: "Joel M. Halpern" <[email-masked]> Cc: Loa Andersson <[email-masked]>, Stewart Bryant <[email-masked]>, [email-masked] Subject: Re: [mpls] To be posted draft draft-andersson-mpls-miad-fwk (Loa / Stewart) Joel,I’m don’t mind changing, but is a bit lost on what to do. Do you have a proposal? Would “Ingress to Egress” (I2E) work?/Loa Sent from my iPhone> On 22 Feb 2022, at 11:42, Joel M. Halpern <[email-masked]> wrote:> > Thank you for posting this.> > May I make a small suggestion?  Pleaes, use some other term than End-to-End (E2E).  Edge-to-Edge (Ed2Ed or some other similar abbreviation) would work. E2E is already abused in too many contexts. Can we please not make it worse.> > Thank you,> Joel> >> On 2/21/2022 10:01 PM, Loa Andersson wrote:>> Tarek,>> Seems to be a reasonable idea. What is posted below is the state of the thinking on the structure one spin after the the DT meeting 2033-07-17.>> None of this is set in stone.>> Since Matthew is on vacation this week, and Stewart and me are busy, I like anyone that can contribute text to do so. I will start up a ID and populate with what I get.>> It is still my intention to post a draft for the IETF113>> .>> /Loa>>> On 2022-02-19 01:21, Tarek Saad wrote:>>> Hi Loa and Stewart,>>> >>>>> to be posted draft draft-andersson-mpls-miad-fwk (Loa / Stewart).>>> >>> In the last Open MPLS DT meeting, you’ve shared a tentative table of content for the work you intend to cover in the above draft. Is it possible to share this TOC on the WG mailing list, so we can engage the WG to chime if required (as was pointed out during the meeting).>>> >>> Regards,>>> >>> Tarek>>> >>                      MPLS MIAD Framework structure thoughts>> Abstract>>    This document specifies an architectural framework for the>>    application of the MPLS Indicator and Ancillary Data (MIAD)>>    technologies.  MIAD techmologies are used to indicate actions (I) for>>    LSPs and/or packets and to transfer data needed for these actions>>    (AD).>>    The document describes a common set of protocol functions and>>    information elements - the MPLS Indicartor and Ancillary Data ->>    supporting additional operational models and capabilities of MPLS>>    netwroks that support these functions.  Some of these functions are>>    defined in existing MPLS specifications, while others require>>    extensions to existing specifications to meet the requirements in the>>    MIAD requirement specification.>>    This document is the the result of work started in MPLS Open Desgign>>    Team, with participation by the MPLS, PALS and DETNET working groups.>> 1.  Introduction>>    This document discusses how flag fields ancillary data and IANA>>    registries for the data coul be desinged.>>    Maybe expand the abstract a bit and give some of the developement we>>    seen in the MPLS forwarding model, e.g. original model, first nible,>>    Pseudowire ACH, GACH and MIAD.>> 1.1.  Requirement Language>>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",>>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and>>    "OPTIONAL" in this document are to be interpreted as described in>>    BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all>>    capitals, as shown here.>>    This document is intended to become an Informational RFC, it is not>>    clear that we will need Section 1.1 "Requirement Language".  We will>>    leave it in for the time being and take the>>    decision to remove or not closer to the Publication Request.>> 2.  Normative Definitions>>    text to be added, prime candidates to be discussed are AD and ADI,>>    not least explaining the differences.>> 3.  Terminology>> 3.1.  Abbreviations>>    +--------------+------------+---------------------------+-----------+>>    | Abbreviation | Meaning    | Reference                 | Note      |>>    +--------------+------------+---------------------------+-----------+>>    | AD           | Ancillary  | draft-bocci-mpls-miad-    | place     |>>    |              | Data       | adi-requirements          | holder    |>>    |              |            |                           |           |>>    | ADI          | Ancillary  | draft-bocci-mpls-miad-    |           |>>    |              | Data       | adi-requirements          |           |>>    |              | Indicator  |                           |           |>>    |              |            |                           |           |>>    | E2E          | End to end | In the MIAD context this  |           |>>    |              |            | document.                 |           |>>    |              |            |                           |           |>>    | HBH          | Hop by hop | In the MIAD context this  |           |>>    |              |            | document.                 |           |>>    |              |            |                           |           |>>    | ISD          | In stack   | draft-bocci-mpls-miad-    |           |>>    |              | data       | adi-requirements          |           |>>    |              |            |                           |           |>>    | LSE          | Label      | RFC 3032 [RFC3032]        |           |>>    |              | Stack      |                           |           |>>    |              | Entry      |                           |           |>>    |              |            |                           |           |>>    | MIAD         | MPLS       | MPLS Open DT wiki and     | MIAD is   |>>    |              | Indicators | this documnent            | the name  |>>    |              | and        |                           | of both   |>>    |              | Ancillary  |                           | this tech |>>    |              | Data       |                           | nology    |>>    |              |            |                           | technlogy |>>    |              |            |                           | and the   |>>    |              |            |                           | project d |>>    |              |            |                           | eveloping |>>    |              |            |                           | this part |>>    |              |            |                           | of the    |>>    |              |            |                           | MPLS arch |>>    |              |            |                           | itecture  |>>    |              |            |                           |           |>>    | PSD          | Post stack | draft-bocci-mpls-miad-    |           |>>    |              | data       | adi-requirements          |           |>>    +--------------+------------+---------------------------+-----------+>>                           Table 1: Abbreviations>> 3.2.  Concepts used in this Framework>>    +------------+--------------------------------+--------------+------+>>    | Concept    | Meaning                        | Reference    | Note |>>    +------------+--------------------------------+--------------+------+>>    | E2E        | E2E im MIAD context is defined | this         | -    |>>    | concept    | in...                          | document     |      |>>    |            |                                |              |      |>>    | concept    | free text                      | this         | -    |>>    |            |                                | document     |      |>>    +------------+--------------------------------+--------------+------+>>                              Table 2: Concepts>> 4.  Methods to carry Ancillary Data Indicators>>    Several possibilities to carry ADI's has been discussed in MIAD>>    drafts and in the MPLS Open DT.>> 4.1.  existing base-SPL>> 4.2.  new base SPL>> 4.3.  new extend SPL>> 5.  Meth0d chosen by the working group>>    o  documenting the wg decision>> 6.  Tpes of AD>> 6.1.  In Stack Data (ISD)>>    a bit of explnatory text>> 6.2.  Post Stack Data (PSD)>>    a bit of explanatory text>> 6.3.  Implicit DataNote that we are chang the earlier "No Data" (NoD),>>       implicit>>    without creating an abbreviation.  ID would be to close o ISD.>> 7.  ADI details>> 7.1. Hop by Hop (HBH)>> 7.2.  End to End (E2E)>> 7.3.  Initiate action at a specific single node>>    We are looking to see if this is needed.>> 8.  Flag Field>> We have a general idea. What sshould be thought about is to leave the TC-filed, the S-bit and TTL unchanged, and use the 32bits  (really 30 since the x bit and s bit are taken) of a new LSE as flag filed.>> 9.  ADI specification rules>>    Guidance what to include in an IANA section>> 10.  Ancillary Data>>    Structure, encoding, allocation of identifiers.  Matters of sequence>>    / priority.  Instances of a single type of AD>> 11.  Packet Structure>> 12.  Security Considerations>> 13.  Managment Considerations>> 14.  MPLS Forwarding model>>    This section here to basically to have a place holder where to>>    discuss the development of the MPLS forwrding model.  It might be>>    removed.>> 14.1.  Orginal Model>>     +-----------------------------------------------------------------+>>     |                                                                 |>>     |  +---------------------+                                        |>>     |  | +------------+      |                                        |>>     |  | | MPLS Label |  LSE |                                        |>>     |  | +---|--------+      |                                        |>>     |  +-----|---------------+                                        |>>     |        |                                                        |>>     |        |  +----------------------+                              |>>     |        |  |                  FIB |                              |>>     |        |  |                      |                              |>>     |        |  |     +------------+   |     +----------------------+ |>>     |        +------->|FIB Entry   |-----+-->|Forwarding Code       | |>>     |           |     +------------+   | |   +----------------------+ |>>     |           +----------------------| |                            |>>     |                                  | |   +----------------------+ |>>     |                                    +-->|Forwarding Parameters | |>>     |                                        +----------------------+ |>>     |                                                                 |>>     |                                                                 |>>     | LSE = Label Stack Entry (what many people call a label)         |>>     | FIB = Forwarding Information (date)Base                         |>>     +-----------------------------------------------------------------+>>                  Figure 1: MPLS Original Forwarding Model>> 15.  IANA Considerations>>    This document does not make any allocations of code points from IANA>>    registries.>>    As long as the "does not make any allocvations ... from IANA is true,>>    this pragraphe shoukd be removed by the RFC-Editor.  If it turns out>>    that we will need to fp IANA allocation, a propser IANA section will>>    be added.> > _______________________________________________> mpls mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/mpls

---

From: tom petch <[email-masked]>
Date: Wed, 23 Feb 2022 09:25:55 +0000

From: mpls <[email-masked]> on behalf of jmh.direct <[email-masked]>
Sent: 22 February 2022 06:28

Yes, "ingress2egress" (I2E) would work for me.  I am sure there are many workable choices.

<tp>

On my MUA, and in other contexts too, I read it as '(twelve)E'.  Capital 'I'  and 'O' I try to avoid when possible. Beginning To End?  or something based on Path, Entire Path, All Path, Whole Path or ...

Tom Petch

Yours,
Joel

Sent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone

-------- Original message --------
From: Loa Andersson <[email-masked]>
Date: 2/22/22 12:08 AM (GMT-05:00)
To: "Joel M. Halpern" <[email-masked]>
Cc: Loa Andersson <[email-masked]>, Stewart Bryant <[email-masked]>, [email-masked]
Subject: Re: [mpls] To be posted draft draft-andersson-mpls-miad-fwk (Loa / Stewart)

Joel,

/Loa

Sent from my iPhone

---

From: Tony Li <[email-masked]>
Date: Thu, 24 Feb 2022 08:43:31 -0800

> On Feb 21, 2022, at 7:42 PM, Joel M. Halpern <[email-masked]> wrote:
> 

I concur. Redefining a well-known term and giving it new semantics, even explicitly, is going to create confusion. It would be much clearer to pick a new term (and abbreviation) so as to not invoke prior semantics.

Some options:

- Ingress-to-Egress (I2E) [possibly confusing in some fonts]
- Egress (because the Ingress has already done its thing)
- Ultimate Hop
- Destination
- Start-to-End
- Last-LSR

Regards,
Tony

---

From: John E Drake <[email-masked]>
Date: Thu, 24 Feb 2022 17:04:59 +0000

I think Egress is precise

Sent from my iPhone

> On Feb 24, 2022, at 11:43 AM, Tony Li <[email-masked]> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!TMpFFCIaEWxBJXPAakgSVCKYvtd2rSAUAwZGYPRbU0eLPugc8QMCitI_H2RVxdQ$