Subject: [mpls] thought about the ADI name

From: Loa Andersson <[email-masked]>
Date: Mon, 20 Dec 2021 00:31:38 +0800

Working Group,

The MIAD Requirement Specification use the abbreviation ADI, it stands 
for Ancillary Data Indicator. Which is all nice and dandy.

But isn't it he case  that the indicator gives us two things, the action 
to be performed and where to find the data needed, i.e., an Ancillary 
Data and Action indication (ADAI?).

No I'm not suggesting that we change, but we should be aware, and it 
would be nice to have it mentioned somewhere.

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

---

From: John E Drake <[email-masked]>
Date: Sun, 19 Dec 2021 16:41:50 +0000

Loa,

This is an updated version of what I had previously written:

When defining a network action, it is necessary to define whether that action is hop-by-hop, processed by every transit node on the packet's path from ingress  node to egress node, or end-to-end, processed only by the  egress node, whether that action requires ancillary data and if so, what is that ancillary data and is placed in label stack entries (LSE) or after the BoS (BoS data).  If a given network action is directly related to forwarding and requires ancillary data, that data SHOULD be placed in LSEs.

I.e., the definition of a given network action itself and whether that network action is specified in a given packet tells a P router what it needs to know wrt that network action's ancillary data. 

Yours Irrespectively,

John

Juniper Business Use Only

> -----Original Message-----
> From: mpls <[email-masked]> On Behalf Of Loa Andersson
> Sent: Sunday, December 19, 2021 11:32 AM
> To: [email-masked]
> Subject: [mpls] thought about the ADI name
> 
> [External Email. Be cautious of content]
> 
> 
> Working Group,
> 
> The MIAD Requirement Specification use the abbreviation ADI, it stands for
> Ancillary Data Indicator. Which is all nice and dandy.
> 
> But isn't it he case  that the indicator gives us two things, the action to be
> performed and where to find the data needed, i.e., an Ancillary Data and Action
> indication (ADAI?).
> 
> No I'm not suggesting that we change, but we should be aware, and it would be
> nice to have it mentioned somewhere.
> 
> /Loa
> --
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!
> NEt6yMaO-
> gk!SNycbCzI_j0rr9X3QVbA_AAsVuZUQ9wOPPKKJgkJybtC4vHvsybGBlRLFInWoKQ
> $

---

From: Loa Andersson <[email-masked]>
Date: Wed, 22 Dec 2021 13:46:24 +0800

John,

A couple of things

- I think we are at the stage when your proposal would benefit from a draft

- you should also closely follow the terminology we have agreed on, data in that are placed in LSEs are called “In Stack Data (ISD)” and data placed after the stack are called ”Post Stack Data (PSD)”. Plz try to align with what we have in the wiki.
- I agree that both actions that rely on ISD and PSD needs to be carefully specified, as well as all the info needed on the ancillary data 

What I did in my mail was discussing a very little piece of the terminology in the requirement specification, the ADIs indicates both action and data. This is not  obvious from the name. 

/Loa

Sent from my iPhone

> On 20 Dec 2021, at 00:42, John E Drake <jdrake=[email-masked]> wrote:
> 
> Loa,
> 
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Haoyu Song <[email-masked]>
Date: Wed, 22 Dec 2021 19:25:22 +0000

Hi Loa,

In my opinion the ADI should only be used to indicate the presence of AD.  E2E or HBH AD could be differentiated because in some case it can help stop further parsing beyond ADI.  Other information encoded in it won't help but complicate the parsing process. I strongly suggest any such proposal should give a clear presentation on why it's necessary and how it can help from the view of implementors, otherwise, we may end up with an over complicated design without tangible benefits. 

Best regards,
Haoyu

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Loa Andersson
Sent: Sunday, December 19, 2021 8:32 AM
To: [email-masked]
Subject: [mpls] thought about the ADI name

Working Group,

The MIAD Requirement Specification use the abbreviation ADI, it stands for Ancillary Data Indicator. Which is all nice and dandy.

But isn't it he case  that the indicator gives us two things, the action to be performed and where to find the data needed, i.e., an Ancillary Data and Action indication (ADAI?).

No I'm not suggesting that we change, but we should be aware, and it would be nice to have it mentioned somewhere.

/Loa

_______________________________________________
mpls mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C789dd20ea31e42b7112c08d9c30d1842%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637755283309284814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=onmR7mzyy0qzaQH%2F%2BHApC%2FjXuUvMRH12uIF9cVsTytA%3D&amp;reserved=0

---

From: Loa Andersson <[email-masked]>
Date: Thu, 23 Dec 2021 06:53:58 +0800

Haoyu,

OK, I simply don't understand.

If you don't know what action you'll take, what good is it to know where 
to find the data?

It might be that this is not what you say, but that is what if get from 
your text below. Sorry if I'm misunderstanding.

/Loa

---

From: Haoyu Song <[email-masked]>
Date: Thu, 23 Dec 2021 17:58:35 +0000

Hi Loa,

Let me try to explain a bit more. I have examples to back the following claims which I can present in a future meeting. 

So far all the existing header design follows a chain structure. The header are parsed linearly one by one from the start of the packet, until you reach a header that is considered the last one concerned by the forwarding plane. You know the presence of a specific header only when you reach it. In this design, the number of parser states as well as the time for parsing is both linear to the number of headers scanned.

Now people may think using some extra indicators (i.e., a bitmap with each bit indicating the presence of a header later in the packet) may improve the parsing performance. To this we must ask "in what sense"?

We can consider two possible types of improvements. First is the reduction of parsing states which can help to save the parser resource (i.e., fewer nodes in the parser FSM); second is the reduction of parsing cycles which can help to parse a packet faster (we have a fixed cost for parsing each header, no matter the size of it. E.g, each MPLS label is considered a header, the entire IPv6 header, excluding EHs, is also considered a header).  

For the first one, if you start to actually draft the parsing graph, you will find the opposite results. In two different parsing styles, both requires more parser states than a simple header chain.

For the second one, we need to understand that the headers concerned by a forwarding plane need to all be parsed anyway. You can't ignore some headers in the middle because you will need to reconstruct the packet headers at the egress (a process also known as deparsing). So the extra indicator encoding doesn't help to improve the parsing speed either.

There's a reason why so far all the headers are simply organized as a chain. It's the most efficient and straightforward way. My study is based on current switch ASICs and some NPs.  If people don't believe me, then evidence (e.g., pseudo code or parsing graph) needs to be provided. Perhaps there are some different forwarding plane designs which can play magic. We need to learn that before introducing any new mechanism.

A caveat is that, an extra indicator for the presence of HBH headers might be useful in some cases. For example, on an LSP path nodes, if there's no HBH headers later in the packet, the parser can stop further parsing immediately which can save some parsing cycles.  Even in this case, if the forwarding plane still requires to continue parsing, this mechanism doesn’t help. 

In general, we really just need to concern the packet header buffer (aka packet window) size. As long as all the headers concerned by a forwarding plane is within the buffer limit, the parsing cost is a negligible concern for a simple header chain. Other mechanisms are of no help at best and could be harmful at worst. Of course, I'd like to see evidence if people think the other way.   

Happy Holidays!

Best regards,
Haoyu

-----Original Message-----
From: Loa Andersson <[email-masked]> 
Sent: Wednesday, December 22, 2021 2:54 PM
To: Haoyu Song <[email-masked]>; [email-masked]
Subject: Re: [mpls] thought about the ADI name

Haoyu,

If you don't know what action you'll take, what good is it to know where to find the data?

It might be that this is not what you say, but that is what if get from your text below. Sorry if I'm misunderstanding.

/Loa

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 23 Dec 2021 10:24:15 -0800

Hi Haoyu, et al,
I might be missing something important in the discussion of the processing
ADI/ADAI. My impression is that e2e is always at the BoS. Is that correct?
Now, what do we do for HbH? As I understand it, you're considering
ELI-style when ADAI is present in the stack and the node needs to locate it
first. Do I understand the scenario you're talking about correctly? But
wouldn't processing be simpler if we mandate that a HbH ADAI is at the top
of the stack? Also, to optimize the length of the stack, a transit node may
be allowed to place the acted-upon HbH ADAI below the transport label.
What do you think? Is that completely off the rails?

Happy Holidays to All!

Regards,
Greg

On Thu, Dec 23, 2021 at 9:58 AM Haoyu Song <[email-masked]> wrote:

> Hi Loa,
>
> Let me try to explain a bit more. I have examples to back the following
> claims which I can present in a future meeting.
>
> So far all the existing header design follows a chain structure. The
> header are parsed linearly one by one from the start of the packet, until
> you reach a header that is considered the last one concerned by the
> forwarding plane. You know the presence of a specific header only when you
> reach it. In this design, the number of parser states as well as the time
> for parsing is both linear to the number of headers scanned.
>
> Now people may think using some extra indicators (i.e., a bitmap with each
> bit indicating the presence of a header later in the packet) may improve
> the parsing performance. To this we must ask "in what sense"?
>
> We can consider two possible types of improvements. First is the reduction
> of parsing states which can help to save the parser resource (i.e., fewer
> nodes in the parser FSM); second is the reduction of parsing cycles which
> can help to parse a packet faster (we have a fixed cost for parsing each
> header, no matter the size of it. E.g, each MPLS label is considered a
> header, the entire IPv6 header, excluding EHs, is also considered a
> header).
>
> For the first one, if you start to actually draft the parsing graph, you
> will find the opposite results. In two different parsing styles, both
> requires more parser states than a simple header chain.
>
> For the second one, we need to understand that the headers concerned by a
> forwarding plane need to all be parsed anyway. You can't ignore some
> headers in the middle because you will need to reconstruct the packet
> headers at the egress (a process also known as deparsing). So the extra
> indicator encoding doesn't help to improve the parsing speed either.
>
> There's a reason why so far all the headers are simply organized as a
> chain. It's the most efficient and straightforward way. My study is based
> on current switch ASICs and some NPs.  If people don't believe me, then
> evidence (e.g., pseudo code or parsing graph) needs to be provided. Perhaps
> there are some different forwarding plane designs which can play magic. We
> need to learn that before introducing any new mechanism.
>
> A caveat is that, an extra indicator for the presence of HBH headers might
> be useful in some cases. For example, on an LSP path nodes, if there's no
> HBH headers later in the packet, the parser can stop further parsing
> immediately which can save some parsing cycles.  Even in this case, if the
> forwarding plane still requires to continue parsing, this mechanism doesn’t
> help.
>
> In general, we really just need to concern the packet header buffer (aka
> packet window) size. As long as all the headers concerned by a forwarding
> plane is within the buffer limit, the parsing cost is a negligible concern
> for a simple header chain. Other mechanisms are of no help at best and
> could be harmful at worst. Of course, I'd like to see evidence if people
> think the other way.
>
> Happy Holidays!
>
> Best regards,
> Haoyu
>
> > In my opinion the ADI should only be used to indicate the presence of
> AD.  E2E or HBH AD could be differentiated because in some case it can help
> stop further parsing beyond ADI.  Other information encoded in it won't
> help but complicate the parsing process. I strongly suggest any such
> proposal should give a clear presentation on why it's necessary and how it
> can help from the view of implementors, otherwise, we may end up with an
> over complicated design without tangible benefits.
> >
> > Best regards,
> > Haoyu
> >
> to be performed and where to find the data needed, i.e., an Ancillary Data
> and Action indication (ADAI?).
> >

---

From: Haoyu Song <[email-masked]>
Date: Thu, 23 Dec 2021 18:53:33 +0000

Hi Greg,

I think the myth is that people tend to believe that if we know what we have in the packet up front, it can help to improve the performance. However, even you know what you have up front, in most cases you still need to scan through the header chain until you reach the last one you are concerned.

I don't imply the indicator must be at ToS. My point is that even it's at ToS, if you have PSD, you still need to scan through the label stack one label by one. If the label stack depth is in the reasonable range, it doesn't make difference where the indicator is. You can simply scan the entire label stack for every packet. As I said, comparing to the actual head processing cost, the parsing cost is negligible. Any overdesign without tangible benefits should not be encouraged.

Best regards,
Haoyu

From: Greg Mirsky <[email-masked]>
Sent: Thursday, December 23, 2021 10:24 AM
To: Haoyu Song <[email-masked]>
Cc: Loa Andersson <[email-masked]>; [email-masked]
Subject: Re: [mpls] thought about the ADI name

Hi Haoyu, et al,
I might be missing something important in the discussion of the processing ADI/ADAI. My impression is that e2e is always at the BoS. Is that correct? Now, what do we do for HbH? As I understand it, you're considering ELI-style when ADAI is present in the stack and the node needs to locate it first. Do I understand the scenario you're talking about correctly? But wouldn't processing be simpler if we mandate that a HbH ADAI is at the top of the stack? Also, to optimize the length of the stack, a transit node may be allowed to place the acted-upon HbH ADAI below the transport label.
What do you think? Is that completely off the rails?

Happy Holidays to All!

Regards,
Greg

On Thu, Dec 23, 2021 at 9:58 AM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Hi Loa,

A caveat is that, an extra indicator for the presence of HBH headers might be useful in some cases. For example, on an LSP path nodes, if there's no HBH headers later in the packet, the parser can stop further parsing immediately which can save some parsing cycles.  Even in this case, if the forwarding plane still requires to continue parsing, this mechanism doesn't help.

Happy Holidays!

Best regards,
Haoyu

-----Original Message-----
From: Loa Andersson <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, December 22, 2021 2:54 PM
To: Haoyu Song <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] thought about the ADI name

Haoyu,

/Loa

On 23/12/2021 03:25, Haoyu Song wrote:
> From: mpls <[email-masked]<mailto:[email-masked]>> On Behalf Of Loa Andersson
> To: [email-masked]<mailto:[email-masked]>

--
Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
Bronze Dragon Consulting             phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%40futurewei.com%7C38f49782cb62408b620508d9c64174a0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637758806714138188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ou37HQ4OAZyu5D3wsSMUAYjzeYBNUKvloEFa9XumEHY%3D&reserved=0>

---

From: Loa Andersson <[email-masked]>
Date: Sat, 25 Dec 2021 01:32:58 +0800

Greg,

Questions for clarification:

- the abbreviation ADAI is that Ancillary Data and Action Indicator?

- when you say "e2e is always at the BoS" do you intend to say that
   this is PSD?

Open DT,

We have a lot of terms/abbreviations that has more or less the same thing.

Should we start an Abbreviation/Terminology page for normative 
information on this?

/Loa

On 24/12/2021 02:24, Greg Mirsky wrote:
> Hi Haoyu, et al,
> I might be missing something important in the discussion of the 
> processing ADI/ADAI. My impression is that e2e is always at the BoS. Is 
> that correct? Now, what do we do for HbH? As I understand it, you're 
> considering ELI-style when ADAI is present in the stack and the node 
> needs to locate it first. Do I understand the scenario you're talking 
> about correctly? But wouldn't processing be simpler if we mandate that a 
> HbH ADAI is at the top of the stack? Also, to optimize the length of the 
> stack, a transit node may be allowed to place the acted-upon HbH ADAI 
> below the transport label.
> On Thu, Dec 23, 2021 at 9:58 AM Haoyu Song <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Loa,
> 
>     Let me try to explain a bit more. I have examples to back the
>     following claims which I can present in a future meeting.
> 
>     header are parsed linearly one by one from the start of the packet,
>     until you reach a header that is considered the last one concerned
>     by the forwarding plane. You know the presence of a specific header
>     only when you reach it. In this design, the number of parser states
>     as well as the time for parsing is both linear to the number of
>     headers scanned.
> 
>     Now people may think using some extra indicators (i.e., a bitmap
>     with each bit indicating the presence of a header later in the
>     packet) may improve the parsing performance. To this we must ask "in
>     what sense"?
> 
>     We can consider two possible types of improvements. First is the
>     reduction of parsing states which can help to save the parser
>     resource (i.e., fewer nodes in the parser FSM); second is the
>     reduction of parsing cycles which can help to parse a packet faster
>     (we have a fixed cost for parsing each header, no matter the size of
>     it. E.g, each MPLS label is considered a header, the entire IPv6
>     header, excluding EHs, is also considered a header).
> 
>     For the first one, if you start to actually draft the parsing graph,
>     you will find the opposite results. In two different parsing styles,
>     both requires more parser states than a simple header chain.
> 
>     For the second one, we need to understand that the headers concerned
>     by a forwarding plane need to all be parsed anyway. You can't ignore
>     some headers in the middle because you will need to reconstruct the
>     packet headers at the egress (a process also known as deparsing). So
>     the extra indicator encoding doesn't help to improve the parsing
>     speed either.
> 
>     There's a reason why so far all the headers are simply organized as
>     a chain. It's the most efficient and straightforward way. My study
>     is based on current switch ASICs and some NPs.  If people don't
>     believe me, then evidence (e.g., pseudo code or parsing graph) needs
>     to be provided. Perhaps there are some different forwarding plane
>     designs which can play magic. We need to learn that before
>     introducing any new mechanism.
> 
>     A caveat is that, an extra indicator for the presence of HBH headers
>     might be useful in some cases. For example, on an LSP path nodes, if
>     there's no HBH headers later in the packet, the parser can stop
>     further parsing immediately which can save some parsing cycles. 
>     Even in this case, if the forwarding plane still requires to
>     continue parsing, this mechanism doesn’t help.
> 
>     In general, we really just need to concern the packet header buffer
>     (aka packet window) size. As long as all the headers concerned by a
>     forwarding plane is within the buffer limit, the parsing cost is a
>     negligible concern for a simple header chain. Other mechanisms are
>     of no help at best and could be harmful at worst. Of course, I'd
>     like to see evidence if people think the other way.
> 
>     Happy Holidays!
> 
>     Best regards,
>     Haoyu
> 
>     From: Loa Andersson <[email-masked] <mailto:[email-masked]>>
>     To: Haoyu Song <[email-masked]
>     <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>     It might be that this is not what you say, but that is what if get
>     from your text below. Sorry if I'm misunderstanding.
> 
>     /Loa
> 
>      > In my opinion the ADI should only be used to indicate the
>     presence of AD.  E2E or HBH AD could be differentiated because in
>     some case it can help stop further parsing beyond ADI.  Other
>     information encoded in it won't help but complicate the parsing
>     process. I strongly suggest any such proposal should give a clear
>     presentation on why it's necessary and how it can help from the view
>     of implementors, otherwise, we may end up with an over complicated
>     design without tangible benefits.
>      >
>      > Best regards,
>      > Haoyu
>      >
>      > From: mpls <[email-masked] <mailto:[email-masked]>>
>     On Behalf Of Loa Andersson
>      > To: [email-masked] <mailto:[email-masked]>
>      > The MIAD Requirement Specification use the abbreviation ADI, it
>     stands for Ancillary Data Indicator. Which is all nice and dandy.
>      >
>      > But isn't it he case  that the indicator gives us two things, the
>     action to be performed and where to find the data needed, i.e., an
>     Ancillary Data and Action indication (ADAI?).
>      >
>      > No I'm not suggesting that we change, but we should be aware, and
>     it would be nice to have it mentioned somewhere.
>      >
>      > /Loa
> 
>     -- 
>     Loa Andersson                        email: [email-masked] <mailto:[email-masked]>
>     Senior MPLS Expert [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/mpls>
>

---

From: Loa Andersson <[email-masked]>
Date: Sat, 25 Dec 2021 18:40:44 +0800

> Let me try to explain a bit more. I have examples to back the following claims which I can present in a future meeting.

If you want to present, you should be specific and ask for a slot at a 
meeting.
> 
> So far all the existing header design follows a chain structure. 

hmmm -  do you consider a number of TLVs to be a "chain structure"?

The header are parsed linearly one by one from the start of the packet,

or upiu stop when you find what you are looking for, which may not be 
the last but the first, the last, or anything in between.

until you reach a header that is considered the last one concerned by 
the forwarding plane.

You know the presence of a specific header only when you reach it.

No. not true - if you have the flag field (FAI/NAI or ADI. or whatever 
you want to call them. The flags will tell you, you'll know what you are 
looking for.

In this design, the number of parser states as well as the time for 
parsing is both linear to the number of headers scanned.

Can't argue about this, doesn't the fact that you are looking for 
something specific help?
> For the second one, we need to understand that the headers concerned by a forwarding plane need to all be parsed anyway. You can't ignore some headers in the middle because you will need to reconst…

So, I conclude. If we have the flag field and know that there is only 
one or two action flags set, I will be worse off than if I have a PSD 
structure that I have no knowledge about?

Now I'm too far off road, and stop here.

> A caveat is that, an extra indicator for the presence of HBH headers might be useful in some cases. For example, on an LSP path nodes, if there's no HBH headers later in the packet, the parser can…
I a FAI/NAI/ADI that indicates HBH wrse than one that indicate E2E?

/Loa

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 25 Dec 2021 11:50:22 -0800

Hi Loa,
Happy Holidays to All!
Please find my answers in-line below under the GIM>> tag.

Regards,
Greg

> - the abbreviation ADAI is that Ancillary Data and Action Indicator?
GIM>> Yes, that was my intention.

> - when you say "e2e is always at the BoS" do you intend to say that
GIM>> Thank you for the question. I don't have a case for e2e using ISD.
Thus, I think that e2e is only PSD (but I am open to the discussion).

> Should we start an Abbreviation/Terminology page for normative
GIM>> Wholeheartedly agree. Let's record all acronyms and abbreviations,
establish equivalency groups and try to converge on a single term for each
construct.

---

From: Loa Andersson <[email-masked]>
Date: Sun, 26 Dec 2021 15:46:34 +0800

Greg, et.al.,

Happy Holidays!

Online please!

On 26/12/2021 03:50, Greg Mirsky wrote:
> On Fri, Dec 24, 2021 at 9:33 AM Loa Andersson <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Greg,
> 

OK - we'll give Matthew and Stewart a chance to think about this.
> Thus, I think that e2e is only PSD (but I am open to the discussion).

hmmm - I have feeling that we are in a kind of agreement, but also that 
we get kind of circular.

For the sake of the argument let us say that e-2-e is always using PSD.
What would the value be to say it is at the BoS? In my world "at" could 
be interpreted as "either side of" and thus be incorrect. If we say that 
data that e-2-e relies on are "after" the BoS, that would be correct, 
but just repeting the definitin of PSD.
> establish equivalency groups and try to converge on a single term for 
> each construct.

I came up with this as a starting point:

https://trac.ietf.org/trac/mpls/wiki/abbreviations

It is not linked to the Open DT wiki pafa, but I can do that.

/Loa

>      > On Thu, Dec 23, 2021 at 9:58 AM Haoyu Song
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >     Hi Loa,
>      >
>      >     From: Loa Andersson <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>; [email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>      >     If you don't know what action you'll take, what good is it to
>     know
>      >     where to find the data?
>      >
>      >      > Hi Loa,
>      >      >
>      >      > In my opinion the ADI should only be used to indicate the
>      >      >
>      >      > Best regards,
>      >      > Haoyu
>      >      >
>      >      > -----Original Message-----
>      >      > From: mpls <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >      > Sent: Sunday, December 19, 2021 8:32 AM
>      >      > To: [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > Subject: [mpls] thought about the ADI name
>      >      >
>      >      > Working Group,
>      >      >
>      >      > The MIAD Requirement Specification use the abbreviation
>     ADI, it
>      >      >
>      >      > But isn't it he case  that the indicator gives us two
>     things, the
>      >      >
>      >      > No I'm not suggesting that we change, but we should be
>     aware, and
>      >      >
>      >      > /Loa
>     <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >     <https://www.ietf.org/mailman/listinfo/mpls
>     <https://www.ietf.org/mailman/listinfo/mpls>>
>      >
> 
>     --

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 26 Dec 2021 11:12:14 -0800

Hi Loa,
top-posting and more notes under the GIM2>> tag.

For the sake of the argument let us say that e-2-e is always using PSD.
What would the value be to say it is at the BoS? In my world "at" could
be interpreted as "either side of" and thus be incorrect. If we say that
data that e-2-e relies on are "after" the BoS, that would be correct,
but just repeting the definitin of PSD.
GIM2>> I think that we are and just need a bit of clarification. When I
think of e2e being BoS I mean the indication of PSD, the e2e ADAI (in that
case it is ADI, no-action). The PSD, in my imagination, would be ADAD -
Ancillary Data and Action Descriptors). Does that make sense?

Regards,
Greg

On Sat, Dec 25, 2021 at 11:46 PM Loa Andersson <[email-masked]> wrote:

> >      >      > From: mpls <[email-masked]

---

From: Haoyu Song <[email-masked]>
Date: Mon, 27 Dec 2021 17:39:55 +0000

Hi Loa,

Please see my response inline with [HS].

Haoyu

-----Original Message-----
From: Loa Andersson <[email-masked]> 
Sent: Saturday, December 25, 2021 2:41 AM
To: Haoyu Song <[email-masked]>; [email-masked]
Subject: Re: [mpls] thought about the ADI name

> Let me try to explain a bit more. I have examples to back the following claims which I can present in a future meeting.

If you want to present, you should be specific and ask for a slot at a meeting.

[HS] Yes. Basically.  However, if a "T" is needed to identify a "TLV" structure, this structure has to be treated as 2 "headers" (i.e., using two parser states instead of one). Therefore, TLV is usually used as an inner structure of a header. It's not recommended for the outer header design. 

or upiu stop when you find what you are looking for, which may not be the last but the first, the last, or anything in between.
[HS] Could you please give an example? 

until you reach a header that is considered the last one concerned by the forwarding plane.

No. not true - if you have the flag field (FAI/NAI or ADI. or whatever you want to call them. The flags will tell you, you'll know what you are looking for.
[HS] What I mean is that we just need a single indicator to tell the presence of AD. Beyond that, it's not helpful and even harmful. I have given the reasons. Perhaps you should try to write the pseudo code to verify that.

In this design, the number of parser states as well as the time for parsing is both linear to the number of headers scanned.

Can't argue about this, doesn't the fact that you are looking for something specific help?
> For the second one, we need to understand that the headers concerned by a forwarding plane need to all be parsed anyway. You can't ignore some headers in the middle because you will need to reconst…

So, I conclude. If we have the flag field and know that there is only one or two action flags set, I will be worse off than if I have a PSD structure that I have no knowledge about?

[HS] You may just know there is PSD. That's enough. Other information doesn't help on either parser size or parsing speed. On the contrary, the bitmap or catalog forces the AD order and limits the AD extensibility. 

[HS] Since LSP end nodes need to parse all the AD anyway, so an overall indicator for AD is sufficient for that purpose. Beyond that, an HBH indicator can allow the LSP path nodes to avoid continuing parsing when the indicator was found which can shorten the parsing process.

/Loa