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

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 <mpls-bounces@ietf.org> On Behalf Of Loa Andersson
Sent: Sunday, March 14, 2021 12:20 AM
To: mpls <mpls@ietf.org>; Kireeti Kompella <kireeti@juniper.net>; Tarek Saad <tsaad.net@gmail.com>
Subject: [mpls] Some thoughts on BoS and ACH. U

[External Email. Be cautious of content]

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
_______________________________________________
mpls mailing list
mpls@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!S50PMFhTRBYlEEeVVXRhp1u0mDJ6Kms7PHwLgTpIorkcCbkp1d07YCKU9_3uuyoH$

Juniper Business Use Only