Subject: [mpls] Some thoughts on BoS and ACH. U

From: Loa Andersson <[email-masked]>
Date: Sun, 14 Mar 2021 13:19:46 +0800

Kireeti, Tarek, et.al. 

I’m not really done digesting your draft and slides. 

One corner stone in MPLS has been that there is no semantics to the bits in the 20 bit label value. 

I’m not sure I want to change that, but would be prepared to discuss. 

You say that TC field and TTL is not acted upon other than for the top label. Doesn’t RFC 3443 do that?

All,

One other thing that is that I see a number of new solutions, that if they are all progressed will create a very complicated set of interdependencies. 

I would like to see one method to find multiple ACH’s after the BoS. 

My straw man. 

What if?

We create a two new FECs.  

That first FEC says
- use this label for FIB LOOK-up
- this is for end node processing
- be aware that there is a special ACH after the BoS. 

The second FEC says
- use this label for the FIB look-up
- this is for hop by hop processing
- be aware that there is a special ACH after the BoS

The Special ACH would give you the number of ACH’es after the BoS and their length, in the order you’d find them, including the Special ACH itself. 

The old methods to find one ACH after the BoS would work, since they are not using the new FEC. And could gradually fade out. 

/Loa

Sent from my iPhone

---

From: Tarek Saad <[email-masked]>
Date: Mon, 15 Mar 2021 14:46:10 +0000

Hi Loa,

Thanks for reaching out. See some comments from me inline..

On 3/14/21, 12:19 AM, "Loa Andersson" <[email-masked]> wrote:

    Kireeti, Tarek, et.al.

    One corner stone in MPLS has been that there is no semantics to the bits in the 20 bit label value.
[TS]: The idea here is to embed an "identifier" in the MPLS label stack with a proper alert mechanism that enables LSRs to know of the presence of such ID. This is very similar to embedding a per-flow identifier (entropy) in the label stack and using ELI as the alert mechanism.

    All,

    One other thing that is that I see a number of new solutions, that if they are all progressed will create a very complicated set of interdependencies.
[TS]: Indeed, there are multiple requests today from the MPLS WG for such "alert" special purpose labels -- i.e. if SPL1 then action1, if SPL2 then action2, etc.
Kireeti presented a single "alert" SPL that can potentially indicate multiple actions action1, action2, etc... IMO, this superior to bloating the MPLS label stack with multiple (SPL1, action1) , (SPL2, action2), (SPL2, action3), etc. when the multiple actions are needed need for the same packet.

[TS]: I agree any metadata after the BoS need to be carefully considered (as was discussed in the JOINT meeting). Ideally, I see two potential efforts -
- Carrying ID(s) in the label stack with a proper "alert" SPL
- Carrying metadata after BoS

    My straw man.

    What if?

    That first FEC says

    The second FEC says
    - use this label for the FIB look-up
    - this is for hop by hop processing
    - be aware that there is a special ACH after the BoS
[TS]: Embedding context within the FEC is always an option. However, it comes with toll on the amount of control plane and dataplane states. For example, if you there are 1000 nodes in a network with 1000 slices, a node may have to store up to 1000x1000 FECs (1M labels) - in addition to the control plane state. BTW, we described this scale concern in section 2 of I-D. draft-bestbar-spring-scalable-ns.

[TS]: Yes, I think the ACH/metadata discussion after the BoS can contrinuee to progress among its own group (open meeting).

Regards,
Tarek

    /Loa

    Sent from my iPhone

Juniper Business Use Only

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 15 Mar 2021 15:08:15 +0000

Hi Loa,

Allow me to top post about your strawman, which I believe is similar to the proposal in draft-song-mpls-extension-header - specifically the special ACH corresponds to HEH in that draft.

Looking at the following ACH format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Version|   Reserved    |         Channel Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: Associated Channel Header

Compare with the following GDFH format in draft-zzhang:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0| Rsved |  This Header  | Header Length |  Next Header  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~              Variable field per "This header"                 ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I don’t know why I had "This header" and "Next Header" separated in the draft, but in my presentation they're actually together:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0| Rsved | Header Length |  This Header  |  Next Header  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~              Variable field per "This header"                 ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Now we can see that the difference between ACH and GDFH formats are:

- ACH has version number, and 16-bit "channel type" corresponding to GDFH's "this-header + next-header"
- ACH has no header-length that GDFH has.

Going back to Tarek's comment in the session that it is cumbersome to use a single 16-bit channel type field to indicate both this channel type and what follows it, what if we split the channel type to two fields "next-channel + this-channel"? Looks like currently there is only one channel-type taking both octets (0x8902G.8113.1 OAM[RFC6671]), so this may work out.

Encoding the length in the header itself is also a good thing I suppose. If we do both these (splitting channel-type and adding the header length), then we don't need the special ACH anymore (even though it does have the benefit of being able to skip all ACHs to quickly get to what is after the ACHs), and we can actually make it generically applicable to non-MPLS scenarios (which is the intention of GDFH).

Jeffrey

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Loa Andersson
Sent: Sunday, March 14, 2021 12:20 AM
To: mpls <[email-masked]>; Kireeti Kompella <[email-masked]>; Tarek Saad <[email-masked]>
Subject: [mpls] Some thoughts on BoS and ACH. U

[External Email. Be cautious of content]

Kireeti, Tarek, et.al.

All,

My straw man.

What if?

That first FEC says

The second FEC says

/Loa

Sent from my iPhone
_______________________________________________
mpls mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!S50PMFhTRBYlEEeVVXRhp1u0mDJ6Kms7PHwLgTpIorkcCbkp1d07YCKU9_3uuyoH$

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 15 Mar 2021 10:41:47 -0700

Hi Jeffrey,
from what I can see in the first nibbles of GDFH, it appears that
it modifies PW Control Word format rather than ACH. Is that the intention?

Regards,
Greg

On Mon, Mar 15, 2021 at 8:08 AM Jeffrey (Zhaohui) Zhang <zzhang=
[email-masked]> wrote:

> Hi Loa,
>
> Allow me to top post about your strawman, which I believe is similar to
> the proposal in draft-song-mpls-extension-header - specifically the special
> ACH corresponds to HEH in that draft.
>
> I don’t know why I had "This header" and "Next Header" separated in the
> draft, but in my presentation they're actually together:
>
> Going back to Tarek's comment in the session that it is cumbersome to use
> a single 16-bit channel type field to indicate both this channel type and
> what follows it, what if we split the channel type to two fields
> "next-channel + this-channel"? Looks like currently there is only one
> channel-type taking both octets (0x8902G.8113.1 OAM[RFC6671]), so this may
> work out.
>
> Encoding the length in the header itself is also a good thing I suppose.
> If we do both these (splitting channel-type and adding the header length),
> then we don't need the special ACH anymore (even though it does have the
> benefit of being able to skip all ACHs to quickly get to what is after the
> ACHs), and we can actually make it generically applicable to non-MPLS
> scenarios (which is the intention of GDFH).
>
> Jeffrey
>
> One other thing that is that I see a number of new solutions, that if they
> are all progressed will create a very complicated set of interdependencies.
>
> The Special ACH would give you the number of ACH’es after the BoS and
> their length, in the order you’d find them, including the Special ACH
> itself.
>
> The old methods to find one ACH after the BoS would work, since they are
> not using the new FEC. And could gradually fade out.
>
> /Loa
>
> Sent from my iPhone
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 15 Mar 2021 22:36:09 +0000

Hi Greg,

GDFH is designed for for both usr/data and control traffic, and the 0000 nibble is only to differentiate from IP packets in the context of ECMP hashing by transit nodes. It’s differentiated from PW data (or any other) traffic via the GDFH label.

I think I am hearing people saying to extend/generalize ACH to data traffic as well. From what I understand, the extended/generalized ACH could very well be aligned to GDFH so that it can be used for beyond MPLS.

Jeffrey

From: Greg Mirsky <[email-masked]>
Sent: Monday, March 15, 2021 1:42 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Loa Andersson <[email-masked]>; mpls <[email-masked]>; Kireeti Kompella <[email-masked]>; Tarek Saad <[email-masked]>
Subject: Re: [mpls] Some thoughts on BoS and ACH. U

Hi Jeffrey,
from what I can see in the first nibbles of GDFH, it appears that it modifies PW Control Word format rather than ACH. Is that the intention?

Regards,
Greg

On Mon, Mar 15, 2021 at 8:08 AM Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]<mailto:[email-masked]>> wrote:
Hi Loa,

    0                   1                   2                   3

Jeffrey

-----Original Message-----
From: mpls <[email-masked]<mailto:[email-masked]>> On Behalf Of Loa Andersson
Sent: Sunday, March 14, 2021 12:20 AM
To: mpls <[email-masked]<mailto:[email-masked]>>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Tarek Saad <[email-masked]<mailto:[email-masked]>>
Subject: [mpls] Some thoughts on BoS and ACH. U

Kireeti, Tarek, et.al<https://urldefense.com/v3/__http:/et.al__;!!NEt6yMaO-gk!XTiSqM-jx0-BLYQ5G7mjgCOviyQQ8DHGMcslSg2V4oyNmd4Lh-BFBgnxwyjSKT9X$>.

All,

My straw man.

What if?

That first FEC says

The second FEC says

/Loa

Sent from my iPhone
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!S50PMFhTRBYlEEeVVXRhp1u0mDJ6Kms7PHwLgTpIorkcCbkp1d07YCKU9_3uuyoH$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!S50PMFhTRBYlEEeVVXRhp1u0mDJ6Kms7PHwLgTpIorkcCbkp1d07YCKU9_3uuyoH$>

Juniper Business Use Only
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!XTiSqM-jx0-BLYQ5G7mjgCOviyQQ8DHGMcslSg2V4oyNmd4Lh-BFBgnxw0T6TaRp$>