[prev in list] [next in list] [prev in thread] [next in thread]
List: mpls
Subject: Re: [mpls] To be posted draft draft-andersson-mpls-miad-fwk (Loa / Stewart)
From: tom petch <ietfc () btconnect ! com>
Date: 2022-02-23 9:25:55
Message-ID: AM7PR07MB6248B62915653026C58CB584A03C9 () AM7PR07MB6248 ! eurprd07 ! prod ! outlook ! com
[Download RAW message or body]
From: mpls <mpls-bounces@ietf.org> on behalf of jmh.direct \
<jmh.direct@joelhalpern.com>
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 <loa.pi.nu@gmail.com>
Date: 2/22/22 12:08 AM (GMT-05:00)
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Loa Andersson <loa@pi.nu>, Stewart Bryant <stewart.bryant@gmail.com>, \
mpls@ietf.org
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 <jmh@joelhalpern.com> 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
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic