Subject: [mpls] What percentage will carry indicator/ancillary data in the future

From: Loa Andersson <[email-masked]>
Date: Sat, 9 Oct 2021 19:42:49 +0200

Design Team,

I have one thing that I been thinking about.

If we consider future mpls encapsulated packet, what percentage will 
carry indicators and ancillary data?

/Loa
-- 

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

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 11 Oct 2021 09:18:31 -0700

Hi Loa,

The term ancillary data is ambiguous: as I understand, it refers to both ISD and PSD.

Two points:
1. High value traffic will frequently use FAI/ISD/PSD.  Best effort traffic probably will probably do so less often.
2. As we find more use cases for FAI, the percentages for both will go up.

For example, mandating CW for L2 PWs (as has been done, and may be reinforced) will mean more post-stack headers.

The way I understand your question is: how often is the PSD looked at (since it potentially creates lots of work for the forwarding engine).  We should consider the answer to be: very often (for high-value traffic), and make sure we handle this case well.  Even if the average number is small (lots of best effort traffic with no PSD), it wouldn’t serve the community well to only drop a few packets, but all of them high-value :)

:k

> On Oct 9, 2021, at 10:43, Loa Andersson <[email-masked]> wrote:
> 
> Design Team,
> 
> If we consider future mpls encapsulated packet, what percentage will carry indicators and ancillary data?
> 
> /Loa
> -- 
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 11 Oct 2021 09:27:12 -0700

Hi Loa,
I have a clarification question. As I understand it, FAI is to signal
ancillary data that is processed in hop-by-hop or end-to-end manner (John
proposed to have a separate indicator for each use case). The impact on
transit nodes is, likely, different. Do you think we need to consider these
cases separately?

Regards,
Greg

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 11 Oct 2021 10:48:41 -0700

Hi Greg,

There were separate indicators for h-by-h and e2e.  The e2e was removed following discussion in the DT; it will return in the next revision.

Of course, the PSD carried and the processing needed will be different in the two cases as they carry different types of data.  Processing h-by-h will also have to deal with traversing a potentially large label stack (and occurs on many nodes), whereas processing e2e PSD will deal with a small label stack and just one node (the egress).

:k

> On Oct 11, 2021, at 09:27, Greg Mirsky <[email-masked]> wrote:
> 
> Hi Loa,
> I have a clarification question. As I understand it, FAI is to signal ancillary data that is processed in hop-by-hop or end-to-end manner (John proposed to have a separate indicator for each use case). The impact on transit nodes is, likely, different. Do you think we need to consider these cases separately?
> 
> Regards,
> Greg
> 
> On Sat, Oct 9, 2021 at 10:43 AM Loa Andersson <[email-masked] <mailto:[email-masked]>> wrote:
> Design Team,
> 
> 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 <https://www.ietf.org/mailman/listinfo/mpls>

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 11 Oct 2021 11:22:45 -0700

Here’s what I’m thinking for the next iteration of the draft.  We’ll burn two bits for hbh and e2e.  I propose the following encoding:
00 — No PSD (go back to sleep)
01 — if you are a transit or end node, you SHOULD look at the PSD
10 — if you are a transit or end node, you MUST look at the PSD (use with care)
11 — if you are a transit node, nothing interesting for you in the PSD; if you are an end node, look at the PSD.  (i.e., no hbh, only e2e PSD).

Note that in the naive approach:
00 — no PSD
01 — only hbh PSD
10 — only e2e PSD
11 — both hbh & e2e PSD

The action for 01 and 10 is pretty much the same.

Thoughts?

Kireeti.

> On Oct 11, 2021, at 10:48, Kireeti Kompella <[email-masked]> wrote:
> 
> Hi Greg,
> 
>> On Oct 11, 2021, at 09:27, Greg Mirsky <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Loa,

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 11 Oct 2021 11:49:12 -0700

Hi Kireeti,
thank you for the heads up on the coming updates to the draft. Comparing
the detailed and brief description of flags it seems to me that
short descriptions of 0b01 should be replaced by slightly reworded 0b11,
and 0b10 and 0b11 ought to be swapped (or the detailed). It might look like:
00 — no PSD
01 — both hbh & e2e SHOULD PSD
10 — both hbh & e2e MUST PSD
11 — only e2e PSD

What do you think?

Regards,
Greg

On Mon, Oct 11, 2021 at 11:22 AM Kireeti Kompella <[email-masked]>
wrote:

> Here’s what I’m thinking for the next iteration of the draft.  We’ll burn
> two bits for hbh and e2e.  I propose the following encoding:
> 11 — if you are a transit node, nothing interesting for you in the PSD; if
> you are an end node, look at the PSD.  (i.e., no hbh, only e2e PSD).
>
> There were separate indicators for h-by-h and e2e.  The e2e was removed
> following discussion in the DT; it will return in the next revision.
>
> Of course, the PSD carried and the processing needed will be different in
> the two cases as they carry different types of data.  Processing h-by-h
> will also have to deal with traversing a potentially large label stack (and
> occurs on many nodes), whereas processing e2e PSD will deal with a small
> label stack and just one node (the egress).
>
> :k
>

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 11 Oct 2021 12:49:53 -0700

Hi Greg,

I was not clear: see inline for clarification.

> On Oct 11, 2021, at 11:49, Greg Mirsky <[email-masked]> wrote:
> 
> Hi Kireeti,
> thank you for the heads up on the coming updates to the draft. Comparing the detailed and brief description of flags it seems to me that short descriptions of 0b01 should be replaced by slightly reworded 0b11, and 0b10 and 0b11 ought to be swapped (or the detailed). It might look like:
> 00 — no PSD

We’re saying the same thing :)

> What do you think?
> 
> Regards,
> Greg
> 
> On Mon, Oct 11, 2021 at 11:22 AM Kireeti Kompella <[email-masked] <mailto:[email-masked]>> wrote:

The above is the new proposal for the -02 draft.  It focuses on node actions.

What follows below is the naive approach that was in the -00 version.  It focused on the type of PSD (hbh or e2e or both).

> The action for 01 and 10 is pretty much the same.

The node actions for 01 and 10 are the same, so the distinction conveys no useful information.  Thus, I propose to use the extra code point for urgency of action.

Does that help?

:k

> Thoughts?
> 
> Kireeti.
> 
>> On Oct 11, 2021, at 10:48, Kireeti Kompella <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Greg,
>>

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 11 Oct 2021 23:07:41 +0200

Fully agreed with the simple "high-value" traffic characteriziation.

IMHO it is interesting to ask what more headers might be asked for for all traffic.

I did talk to one large SP architect who told me that the overhead of potentially
100 bytes for an SRv6 steering header would be well acceptable for the
capacity optimization benefit it brings. Of course, this is one extreme and
we know a lot of work in SPRING to shorten those headers as well.

But i think what this points to, is that additional header elements for
BE traffic will be accepted when they ultimately help the network - and
not just the traffic.

I don't think we know all those headers, which is why we should make sure
we can easily be extensible.

Some ideas:

In recent research, we looked into carrying latency experienced by packets
in the packet header (varies forms possible). Latency variations on egres-PE
measured on a per-ingres PE could be a good next-level TE input to identify
much better path peak-loads than current mechanisms.

This can be extended to much more path diagnostics on egres, especially
when continuous telemetry from P hops is operationally less desirable:
record-route, record-hop-raising-ECN, etc. pp

If it comes for free (no throughput performance drop, just header overhead)
i am sure SPs would also like to mesure drops end-to-end by per-path
sequence number headers. Of course, these PREOF sub-functions will first
come in for the high-value traffic / detnet, but i don't see them
being succssful when they require expensive add-on linecards, and as soon
as they would happen in general purpose edge-linecards, i think there
is motivation to use them just for network diagnostics for all traffic
(if for free). 

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Haoyu Song <[email-masked]>
Date: Mon, 11 Oct 2021 22:53:43 +0000

Hi Kireeti,

Could you explain what's the difference between the following 01"SHOULD" and 10"MUST" and why you need to make the difference?
In a previous discussion, I suggested the following:

00: No PSD
01: illegal code
10: Has PSD, but only end-to-end type, so a transit node could ignore it.
11: Has PSD, and has Hop-by-hop type

Here the first bit is the PSD indicator and the second bid provides some useful further clarification. Is there any issue about it? Thanks!

Best regards,
Haoyu

From: mpls <[email-masked]> On Behalf Of Kireeti Kompella
Sent: Monday, October 11, 2021 11:23 AM
To: Greg Mirsky <[email-masked]>
Cc: [email-masked]
Subject: Re: [mpls] What percentage will carry indicator/ancillary data in the future

Here's what I'm thinking for the next iteration of the draft.  We'll burn two bits for hbh and e2e.  I propose the following encoding:
00 - No PSD (go back to sleep)
01 - if you are a transit or end node, you SHOULD look at the PSD
10 - if you are a transit or end node, you MUST look at the PSD (use with care)
11 - if you are a transit node, nothing interesting for you in the PSD; if you are an end node, look at the PSD.  (i.e., no hbh, only e2e PSD).

00 - no PSD
01 - only hbh PSD
10 - only e2e PSD
11 - both hbh & e2e PSD

Thoughts?

Kireeti.

On Oct 11, 2021, at 10:48, Kireeti Kompella <[email-masked]<mailto:[email-masked]>> wrote:

Hi Greg,

:k

On Oct 11, 2021, at 09:27, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Loa,

Regards,
Greg

On Sat, Oct 9, 2021 at 10:43 AM Loa Andersson <[email-masked]<mailto:[email-masked]>> wrote:
Design Team,

/Loa
--

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%7Cfda9bc7aa8624c3fae2208d98ce42d82%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637695733931053274%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=iSijKO4YdXTX3sCHeEBaVTYmKFmSrsl8II74JJohs1k%3D&reserved=0>
_______________________________________________
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%7Cfda9bc7aa8624c3fae2208d98ce42d82%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637695733931063228%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=S%2BBt3iyooVPd4g7lsSbopXhza92yfxkoLARsJsMw3lo%3D&reserved=0>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 12 Oct 2021 08:27:21 +0200

Kireeti,

I had an off-line very short chat with Stewart on this, and what I took 
away from that discussion is that we probably need to drive the on what 
percentage of MPLS packet that carry indicators + ancillary data based 
on use cases.

I don't think the term ancillary is ambiguous, we have been over it 
several time in the DT and we have agreed every time.

Ancillary data are data data that helps the node take the correct 
forwarding decision. There are three types of ancillary data (if you 
look at how they are positioned in the packet:
- post stack data (PSD)
- in stack data (ISD)
- No data (NoD)

Counting NoD with ISD and PSD as ancillary data, is a bit of a tweak, 
but I think it is good from a descriptive point of view, and also there 
is some implicit data folded in with the indicator.

> 1. High value traffic will frequently use FAI/ISD/PSD.  Best effort traffic probably will probably do so less often.

   - I tned to agree, but it is kind of unproven and would require real
     measurements to prove

> 2. As we find more use cases for FAI, the percentages for both will go up.

   - this is likely
> For example, mandating CW for L2 PWs (as has been done, and may be reinforced) will mean more post-stack headers.

   - agreed
> 
> The way I understand your question is: how often is the PSD looked at 

Well, yes and no, looking at PSD is part of it and might cost more 
processing than other ancillary data.
(since it potentially creates lots of work for the forwarding engine).

Yes. And that was where I started to think about this.

We should consider the answer to be: very often (for high-value 
traffic), and make sure we handle this case well.  Even if the average 
number is small (lots of best effort traffic with no PSD), it wouldn’t 
serve the community well to only drop a few packets, but all of them 
high-value :)

Yes, I thnk that is a good strategy.

/Loa

--

---

From: Loa Andersson <[email-masked]>
Date: Tue, 12 Oct 2021 08:33:31 +0200

Greg,

On 11/10/2021 18:27, Greg Mirsky wrote:
> ancillary data that is processed in hop-by-hop or end-to-end manner 

I'm not really comfortable calling this a signaling mechanism, but I can 
understand what you mean

> (John proposed to have a separate indicator for each use case). 

We will discuss John's proposal this week.

The
> impact on transit nodes is, likely, different. Do you think we need to 
> consider these cases separately?

I'm a bit lost, do you say that hop-by-hop and end-to-end (the way we 
used the words here) are being treated different by the transit nodes. 
That is the point isn't it.
I think it is a good starting point considering them separately, and 
then we see where that will take us.

/Loa
>     <https://www.ietf.org/mailman/listinfo/mpls>
> 

--

---

From: Loa Andersson <[email-masked]>
Date: Tue, 12 Oct 2021 08:38:18 +0200

Kireeti,

On 11/10/2021 20:22, Kireeti Kompella wrote:
> Here’s what I’m thinking for the next iteration of the draft.  We’ll 
> burn two bits for hbh and e2e.  I propose the following encoding:
> 11 — if you are a transit node, nothing interesting for you in the PSD; 
> if you are an end node, look at the PSD.  (i.e., no hbh, only e2e PSD).
> 

I like the first better than than the second, isn't it true that hbh is 
always treated with LER's as if they were transit nodes?

/Loa
>> There were separate indicators for h-by-h and e2e.  The e2e was 
>> removed following discussion in the DT; it will return in the next 
>> revision.
>>
>> Of course, the PSD carried and the processing needed will be different 
>> in the two cases as they carry different types of data.  Processing 
>> h-by-h will also have to deal with traversing a potentially large 
>> label stack (and occurs on many nodes), whereas processing e2e PSD 
>> will deal with a small label stack and just one node (the egress).
>>
>> :k
>>
>>> (John proposed to have a separate indicator for each use case). The 
>>> impact on transit nodes is, likely, different. Do you think we need 
>>> to consider these cases separately?
>>>
>>> Regards,
>>> Greg
>>>
>>>     <mailto:[email-masked]>

--