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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

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 <[e-mail]>
Sent: Monday, March 15, 2021 1:42 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>
Cc: Loa Andersson <[e-mail]>; mpls <[e-mail]>; Kireeti Kompella <[e-mail]>; Tarek Saad <[e-mail]>
Subject: Re: [mpls] Some thoughts on BoS and ACH. U

[External Email. Be cautious of content]

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=[e-mail]<mailto:[e-mail]>> 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.

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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Loa Andersson
Sent: Sunday, March 14, 2021 12:20 AM
To: mpls <[e-mail]<mailto:[e-mail]>>; Kireeti Kompella <[e-mail]<mailto:[e-mail]>>; Tarek Saad <[e-mail]<mailto:[e-mail]>>
Subject: [mpls] Some thoughts on BoS and ACH. U

[External Email. Be cautious of content]


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

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
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!XTiSqM-jx0-BLYQ5G7mjgCOviyQQ8DHGMcslSg2V4oyNmd4Lh-BFBgnxw0T6TaRp$>


Juniper Business Use Only