Subject: Re: [Pals] [mpls] draft-zzhang-intarea-generic-delivery-functions

From: Rakesh Gandhi <[email-masked]>
Date: Thu, 18 Feb 2021 18:49:07 -0500

Hi Stewart,
Hi Xiao, Loa,
FYI:
I believe the latest revision (06) addresses this comment. Welcome your
feedback on that.
https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-ioam-sr-06

Thanks for your review.
Regards,
Rakesh

On Tue, Jan 19, 2021 at 3:57 PM Rakesh Gandhi <[email-masked]>
wrote:

> Hi Stewart,
> Thanks for your comments. If we have a mechanism like following, does that
> address the issue?
>
>    1. IOAM header is part of the MPLS encapsulation, any other control
>    word is added after the IOAM header in the data packet.
>    2. The transit nodes can process the IOAM data field(s) after the EOS
>    in data packets as it is proposed.
>    3. The decapsulating node removes the MPLS encapsulation including the
>    IOAM header and then processes the other control word following it.
>
>    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
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    | IOAM Indicator Label                  | TC  |1|  TTL          |
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
>
>    |0 0 0 1|Version| Reserved      | IOAM G-ACh                    |  |
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
>
>    | Reserved      | Block Number  | IOAM-OPT-Type |IOAM HDR Length|  |
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  I
>
>    |                                                               |  O
>
>    |                                                               |  A
>
>    ~                 IOAM Option and Data Space                    ~  M
>
>    |                                                               |  |
>
>    |                                                               |  |
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
>
>    |0 0 0 0| Rsved | This Header   | Header Length | Next Header   |
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    ~              Variable field per “This header”                 ~
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    |                                                               |
>
>    |                                                               |
>
>    ~                 Payload Packet                                ~
>
>    |                                                               |
>
>    |                                                               |
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Thanks,
> Rakesh
>
>
>
> On Tue, Jan 12, 2021 at 10:00 AM Stewart Bryant <[email-masked]>
> wrote:
>
>> Thank you Jeffery
>>
>> Please see the note that I sent about iOAM who also want to sit after BoS
>> … and both of you want the same space that PALS and DetNet is already using.
>>
>> We plan to have a joint session on this hosted by PALS at the next IETF,
>> but I think we also need to include the iOAM people.
>>
>> This has scope to get very messy as we find new candidates for BoS
>> metadata so we really need to take a holistic position to ensure the future
>> health the MPLS protocol.
>>
>> - Stewart
>>
>>
>> > On 12 Jan 2021, at 14:27, Jeffrey (Zhaohui) Zhang <[email-masked]>
>> wrote:
>> >
>> > Hi,
>> >
>> > I just posted
>> https://datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/
>> .
>> >
>> > The initial version was posted to the tsvwg (
>> https://tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00).
>> After discussions/feedback we are re-homing it to intarea wg. This new
>> version also contains quite some changes based on the comments and feedback
>> that we received (special thanks to Stewart).
>> >
>> > Comments and suggestions are appreciated.
>> >
>> > Thanks.
>> > Jeffrey
>> >
>> > Juniper Business Use Only
>>
>> _______________________________________________
>> mpls mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 19 Feb 2021 03:35:06 +0000

Stewart, all,

I apologize for not responding to this in time. I some how accidentally moved a few wg mailing list email folders to a place where I could not see so I missed all the discussions.
Let me catch up all the emails and then reply.

Thanks.
Jeffrey

-----Original Message-----
From: Stewart Bryant <[email-masked]>
Sent: Tuesday, January 12, 2021 9:59 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; [email-masked]; mpls <[email-masked]>; [email-masked]; Kireeti Kompella <[email-masked]>; Ron Bonica <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

[External Email. Be cautious of content]

Thank you Jeffery

Please see the note that I sent about iOAM who also want to sit after BoS … and both of you want the same space that PALS and DetNet is already using.

We plan to have a joint session on this hosted by PALS at the next IETF, but I think we also need to include the iOAM people.

This has scope to get very messy as we find new candidates for BoS metadata so we really need to take a holistic position to ensure the future health the MPLS protocol.

- Stewart

> On 12 Jan 2021, at 14:27, Jeffrey (Zhaohui) Zhang <[email-masked]> wrote:
>
> Hi,
>
> I just posted https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiItOdNuXbu_RIMekK2pkpOj4Mmj7b9MseV-Y$ .
>
> The initial version was posted to the tsvwg (https://urldefense.com/v3/__https://tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiItOdNuXbu_RIMekK2pkpOj4Mmj7b5lS_Jea$ ). After discussions/feedback we are re-homing it to intarea wg. This new version also contains quite some changes based on the comments and feedback that we received (special thanks to Stewart).
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 19 Feb 2021 04:08:54 +0000

Hi Yangfan,

Please see zzh> below.

-----Original Message-----
From: Yangfan (IP Standard) <[email-masked]>
Sent: Monday, January 18, 2021 5:24 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; mpls <[email-masked]>; [email-masked]
Cc: Kireeti Kompella <[email-masked]>; Ron Bonica <[email-masked]>
Subject: 答复: draft-zzhang-intarea-generic-delivery-functions

Hi authors,

The idea of a shim layer to provide the generic delivery function is interesting. I have 3 questions for clarification.

1. The draft request a new number of Internet Protocol Number registry for GDFH, I assume in this case, GDFH is used together with IP header. I wonder what the benefit is to have this generic header other than directly specifying the functionality as the next header?

Zzh> Allocating a number for GDFH from the IP number registry is not for putting a GDFH right after an IP header. The draft says:
      Next Header:  The type of next header.  For functions that IETF is
      concerned with, the "Next Header" values are from the "Internet
      Protocol Numbers" registry.  A next header could be another GDFH,
      so a value is to be assigned for GDFH from the registry.
Zzh> Consider the following situations when reading the above paragraph: 1) a GDFH is followed by a header that can currently follow an IP header 2) GDFH is followed by another GDFH. For 1), we want the "next header" field of the GDFH to be able to take existing IP protocol numbers (though some of them may not make sense with GDFH). For 2), we want the "next header" field of the first GDFH to be a value indicating that the next header is GDFH. When you combine 1) and 2), you can see that the value (identifying that next header is GBFH) needs to be from the IP protocol number registry.
Zzh> Additionally, imagine that a new delivery function is developed, and it can be done on top of IP and other layers. In that case, we do want to use a GDFH for that new function, and we do want to allow it after an IP header.

2. If the GDFH is used with MPLS, what is the difference compared to G-ACh?

Zzh> Let me read about G-ACh and get back.

3. If you suggest to use one uniform encapsulation in Figure 2 for IP/MPLS/BIER, starting with 0000 would make sense when it is encapsulated in MPLS, but seems unnecessary in IP. Because in IP, usually 5-tuple is used for hashing algorithm. First 4 zeroes don't help to avoid the hashing problem.

Zzh> Indeed starting with 0000 is for mpls case; but because GDFH is for "generic" purposes, that 0000 is always present.
Zzh> 0000 being different from 4 or 6, a router doing 5-tuple hashing should not mistake it as an IP packet (hence it would not do 5-tuple hashing).
Zzh> Thanks.
Zzh> Jeffrey

Best regards,
Fan

-----邮件原件-----
发件人: mpls [mailto:[email-masked]] 代表 Jeffrey (Zhaohui) Zhang
发送时间: 2021年1月12日 22:27
收件人: [email-masked]; mpls <[email-masked]>; [email-masked]
抄送: Kireeti Kompella <[email-masked]>; Ron Bonica <[email-masked]>
主题: [mpls] draft-zzhang-intarea-generic-delivery-functions

Hi,

I just posted https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/__;!!NEt6yMaO-gk!QZhMuyy2Qh6dRiDc7sqPMUgVJFMu2oircI9Mi-4xslI9G4QzeqUM-qAkGDyyJMZk$ .

The initial version was posted to the tsvwg (https://urldefense.com/v3/__https://tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00__;!!NEt6yMaO-gk!QZhMuyy2Qh6dRiDc7sqPMUgVJFMu2oircI9Mi-4xslI9G4QzeqUM-qAkGErjaauy$ ). After discussions/feedback we are re-homing it to intarea wg. This new version also contains quite some changes based on the comments and feedback that we received (special thanks to Stewart).

Thanks.
Jeffrey

_______________________________________________
mpls mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!QZhMuyy2Qh6dRiDc7sqPMUgVJFMu2oircI9Mi-4xslI9G4QzeqUM-qAkGGaib2FE$

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 19 Feb 2021 15:42:09 +0000

Hi Stewart,

I still have to read more about DetNet, but I am not sure if there is a real contention with PALS.

My understanding of 0000 nibble in PW control world is that it is only to prevent a transit node from mistaking the payload as IP. Is it supposed to indicate that any payload starting with 0000 is PW payload? I hope not.

Use of 0000 nibble in GDFH is also just to prevent transit nodes from mistaking it as IP. It does indicate it is GDFH. It should be able to co-exist with PW CW.

Thanks.
Jeffrey

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang
Sent: Thursday, February 18, 2021 10:35 PM
To: Stewart Bryant <[email-masked]>
Cc: [email-masked]; mpls <[email-masked]>; [email-masked]; Kireeti Kompella <[email-masked]>; Ron Bonica <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Stewart, all,

Thanks.
Jeffrey

-----Original Message-----
From: Stewart Bryant <[email-masked]>
Sent: Tuesday, January 12, 2021 9:59 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; [email-masked]; mpls <[email-masked]>; [email-masked]; Kireeti Kompella <[email-masked]>; Ron Bonica <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

Thank you Jeffery

- Stewart

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 19 Feb 2021 16:15:12 +0000

Hi Rakesh, Yangfan,

I agree that a GDFH can follow the IOAM header and the two do not contend.

It came to me though, the IOAM header could become a GDFH 😊 It can then be used for all transportations (MPLS, BIER, or even ethernet).

I see that in your -06 version you treat IOAM as  a G-ACH channel. That does not seem to go well with the following in RFC 5586:

   The G-ACh MUST NOT be used to transport user traffic.

However I am not against relaxing the above restriction a bit.
But I don’t understand why you need an “IOAM Indicator Label” – there is already a special label G-ACh Label (GAL).
For GDFH, I had designed to advertise regular labels to indicate that a GDFH follows (I am always a good citizen when it comes to requesting special labels). Seeing that G-Ach uses the GAL, and the following:

   The ACH used by CC Type 1 is depicted in figure below:

    0                   1                   2                   3

   |0 0 0 1|Version|   Reserved    |         Channel Type          |

                    Figure 1: Associated Channel Header

If the user traffic restriction could be lifted, it’s tempting to treat GDFH as a G-Ach channel type. That way we don’t need to advertise GDFH labels.

To answer Yangfan’s question “what is the difference compared to G-AC” in another email: GDFH is for generic delivery function over different transports, and even when it is used over MPLS it is different from the (original intention of) G-ACH. However, as mentioned above, it’s tempting to treat GDFH as a channel type just to be able use the already assigned GAL.

Thanks.
Jeffrey

From: Rakesh Gandhi <[email-masked]>
Sent: Thursday, February 18, 2021 6:49 PM
To: Stewart Bryant <[email-masked]>
Cc: Jeffrey (Zhaohui) Zhang <[email-masked]>; mpls <[email-masked]>; [email-masked]; Kireeti Kompella <[email-masked]>; Ron Bonica <[email-masked]>; <[email-masked]> <[email-masked]>; [email-masked]
Subject: Re: [mpls] draft-zzhang-intarea-generic-delivery-functions

Hi Stewart,
Hi Xiao, Loa,
FYI:
I believe the latest revision (06) addresses this comment. Welcome your feedback on that.
https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-ioam-sr-06<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-gandhi-mpls-ioam-sr-06__;!!NEt6yMaO-gk!VXglGy7lcO2Pe-wXQDgZaYzzz0Ckq57ZSdkkJ0Sz5yTrNvCrxSb9ClooNfsG5fW-$>

Thanks for your review.
Regards,
Rakesh

On Tue, Jan 19, 2021 at 3:57 PM Rakesh Gandhi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Stewart,
Thanks for your comments. If we have a mechanism like following, does that address the issue?

  1.  IOAM header is part of the MPLS encapsulation, any other control word is added after the IOAM header in the data packet.
  2.  The transit nodes can process the IOAM data field(s) after the EOS in data packets as it is proposed.
  3.  The decapsulating node removes the MPLS encapsulation including the IOAM header and then processes the other control word following it.

   0                   1                   2                   3

   |                                                               |  O

   |                                                               |  A

   |                                                               |  |

   |                                                               |  |

   |                                                               |

   |                                                               |

   ~                 Payload Packet                                ~

   |                                                               |

   |                                                               |

Thanks,
Rakesh

On Tue, Jan 12, 2021 at 10:00 AM Stewart Bryant <[email-masked]<mailto:[email-masked]>> wrote:
Thank you Jeffery

- Stewart

> On 12 Jan 2021, at 14:27, Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi,
>
> I just posted https://datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/__;!!NEt6yMaO-gk!VXglGy7lcO2Pe-wXQDgZaYzzz0Ckq57ZSdkkJ0Sz5yTrNvCrxSb9ClooNQ3VcEYN$>.
>
> The initial version was posted to the tsvwg (https://tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00__;!!NEt6yMaO-gk!VXglGy7lcO2Pe-wXQDgZaYzzz0Ckq57ZSdkkJ0Sz5yTrNvCrxSb9ClooNdw0REUd$>). After discussions/feedback we are re-homing it to intarea wg. This new version also contains quite some changes based on the comments and feedback that we received (special thanks to Stewart).
>

_______________________________________________
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!VXglGy7lcO2Pe-wXQDgZaYzzz0Ckq57ZSdkkJ0Sz5yTrNvCrxSb9ClooNd2pzrpq$>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 22 Feb 2021 10:14:57 +0000

The DetNet CW is described in RFC8964 and is 

      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 0|                Sequence Number                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 5: DetNet Control Word

In all defined control words

The 0000 is simply ECMP defeat and has no other purpose.

0001 means ACH 

An ACH is currently defined not to carry service/user data - it is a control/OAM channel.

You cannot assume anything about a payload starting 0000.

In MPLS the bottom label (alone) defines how you process the payload. So you know that you have a CW from the bottom label and by no other means.

In other words the the FEC of the bottom label and its associated parameters are the way that signalling protocol knows what instructions to give the forwarder, and the way that the forwarder knows what to do with the packet is from the instructions associated with the BoS label. This is the universal model for MPLS including for IP packets.

Stewart

> On 19 Feb 2021, at 15:42, Jeffrey (Zhaohui) Zhang <[email-masked]> wrote:
> 
> Hi Stewart,
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 22 Feb 2021 10:38:59 +0000

The way that a forwarder processing a PW  knows that a CW follows is because it is a parameter of the FEC of the PW label that is BoS.

The CW then described whether the payload is a PW user payload of an ACH using the 0001

IF you want to run OAM on an MPLS LSP as we do in MPLS-TP you have no CW so you need another method of indicating the presence of the ACH and the way that is done is with a GAL.

The cleanest way to put fragmentation information at the BoS is to create a new type MPLS payload construct the “fragwire” if you like push the metadata, push a label advertised by the recipient that says that this is what is being done, then just the delivery label.

You have to know that the target can do this, so the target can advertise or otherwise provide a label saying what it needs as an indicator.

Job done and it is a private matter between sender and receiver.

This is just reusing what is already in place today.

Indeed if you make this a PW type, you only need a very short draft and it is all done.

- Stewart

> On 19 Feb 2021, at 16:15, Jeffrey (Zhaohui) Zhang <[email-masked]> wrote:
> 
> Hi Rakesh, Yangfan,
>  
> From: Rakesh Gandhi <[email-masked] <mailto:[email-masked]>> 
> To: Stewart Bryant <[email-masked] <mailto:[email-masked]>>
> Cc: Jeffrey (Zhaohui) Zhang <[email-masked] <mailto:[email-masked]>>; mpls <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Kireeti Kompella <[email-masked] <mailto:[email-masked]>>; Ron Bonica <[email-masked] <mailto:[email-masked]>>; <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-ioam-sr-06 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-gandhi-mpls-ioam-sr-06__;!!NEt6yMaO-gk!VXglGy7lcO2Pe-wXQDgZaYzzz0Ckq57ZSdkkJ0Sz5yTrNvCrxSb9ClooNfsG5fW-$>
>  
> Thanks for your review. 
> Regards,
> Rakesh
>  
> On Tue, Jan 19, 2021 at 3:57 PM Rakesh Gandhi <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Stewart,
> IOAM header is part of the MPLS encapsulation, any other control word is added after the IOAM header in the data packet.
> The transit nodes can process the IOAM data field(s) after the EOS in data packets as it is proposed.
> The decapsulating node removes the MPLS encapsulation including the IOAM header and then processes the other control word following it.
>    0                   1                   2                   3
> On Tue, Jan 12, 2021 at 10:00 AM Stewart Bryant <[email-masked] <mailto:[email-masked]>> wrote:
> Thank you Jeffery
> 
> > On 12 Jan 2021, at 14:27, Jeffrey (Zhaohui) Zhang <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > Hi,
> > 
> > I just posted https://datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/__;!!NEt6yMaO-gk!VXglGy7lcO2Pe-wXQDgZaYzzz0Ckq57ZSdkkJ0Sz5yTrNvCrxSb9ClooNQ3VcEYN$>.
> > 
> > The initial version was posted to the tsvwg (https://tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00 <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00__;!!NEt6yMaO-gk!VXglGy7lcO2Pe-wXQDgZaYzzz0Ckq57ZSdkkJ0Sz5yTrNvCrxSb9ClooNdw0REUd$>). After discussions/feedback we are re-homing it to intarea wg. This new version also contains quite some changes based on the comments and feedback that we received (special thanks to Stewart).
> > 
> [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!VXglGy7lcO2Pe-wXQDgZaYzzz0Ckq57ZSdkkJ0Sz5yTrNvCrxSb9ClooNd2pzrpq$>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 22 Feb 2021 22:44:29 +0000

Hi Stewart,

GDF is for any transportations, MPLS being of the transportations.
Here the question is, in case of MPLS, how do we do it.

I did design it to advertise a GDF label so that we know that a GDFH is at BoS; and I make the GDFH start with 0000b so that it won’t be mistaken as an IP header.

I don’t see why using 0000b in GDFH is contending with IOAM (even if it uses 0000b) and PW CW?

I was incorrectly thinking that IOAM was using GAL, so I was thinking, if IOAM (which I think it is user traffic with OAM info embedded) could use GAL, then perhaps GAL’s restriction for user-traffic could be lifted, and in that case GDF go with G-ACH using GAL.

Now I realize that I can’t really use GAL. In that case, I think it’s better to be independent of PW and G-ACH – this is not only the fragmentation function.

Thanks.
Jeffrey

From: Stewart Bryant <[email-masked]>
Sent: Monday, February 22, 2021 5:39 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; Rakesh Gandhi <[email-masked]>; Yangfan (IP Standard <[email-masked]>; Greg Mirsky <[email-masked]>; mpls <[email-masked]>; [email-masked]; Kireeti Kompella <[email-masked]>; Ron Bonica <[email-masked]>; <[email-masked]> <[email-masked]>; [email-masked]
Subject: Re: [mpls] draft-zzhang-intarea-generic-delivery-functions

- Stewart

On 19 Feb 2021, at 16:15, Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:

Hi Rakesh, Yangfan,

    0                   1                   2                   3

Thanks.
Jeffrey

From: Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, February 18, 2021 6:49 PM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] draft-zzhang-intarea-generic-delivery-functions

Hi Stewart,
Hi Xiao, Loa,
FYI:

Thanks for your review.
Regards,
Rakesh

Thanks,
Rakesh

- Stewart

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 22 Feb 2021 22:49:17 +0000

Hi Stewart,

This thread started with your comment “Please see the note that I sent about iOAM who also want to sit after BoS … and both of you want the same space that PALS and DetNet is already using”, but now it seems that we’re on the same page – GDFH starting with 0000b is fine and is not competing with IOAM or PW/DETNET CW?

Thanks.
Jeffrey

Sent: Monday, February 22, 2021 5:15 AM

      0                   1                   2                   3

0001 means ACH

Stewart

On 19 Feb 2021, at 15:42, Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:

Hi Stewart,

Thanks.
Jeffrey

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang
Sent: Thursday, February 18, 2021 10:35 PM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Stewart, all,

Thanks.
Jeffrey

-----Original Message-----
From: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 12, 2021 9:59 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

Thank you Jeffery

- Stewart

Hi,

I just posted https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiItOdNuXbu_RIMekK2pkpOj4Mmj7b9MseV-Y$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiItOdNuXbu_RIMekK2pkpOj4Mmj7b9MseV-Y$> .

The initial version was posted to the tsvwg (https://urldefense.com/v3/__https://tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiItOdNuXbu_RIMekK2pkpOj4Mmj7b5lS_Jea$<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiItOdNuXbu_RIMekK2pkpOj4Mmj7b5lS_Jea$> ). After discussions/feedback we are re-homing it to intarea wg. This new version also contains quite some changes based on the comments and feedback that we received (special thanks to Stewart).

Thanks.
Jeffrey

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 23 Feb 2021 00:29:44 +0000

What happens if an operator wants to run both iOAM and GDFH at the same time and the packet is a PW packet?

What does the packet look like and how does the forwarder know what to do?

- Stewart

> On 22 Feb 2021, at 22:49, Jeffrey (Zhaohui) Zhang <[email-masked]> wrote:
> 
> Hi Stewart,
>  
> From: Stewart Bryant <[email-masked] <mailto:[email-masked]>> 
> To: Jeffrey (Zhaohui) Zhang <[email-masked] <mailto:[email-masked]>>
> Cc: Stewart Bryant <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; mpls <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Kireeti Kompella <[email-masked] <mailto:[email-masked]>>; Ron Bonica <[email-masked] <mailto:[email-masked]>>; <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>
> On 19 Feb 2021, at 15:42, Jeffrey (Zhaohui) Zhang <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Stewart,
> 
> Cc: [email-masked] <mailto:[email-masked]>; mpls <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Kireeti Kompella <[email-masked] <mailto:[email-masked]>>; Ron Bonica <[email-masked] <mailto:[email-masked]>>; <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>
> From: Stewart Bryant <[email-masked] <mailto:[email-masked]>>
> To: Jeffrey (Zhaohui) Zhang <[email-masked] <mailto:[email-masked]>>
> Cc: Stewart Bryant <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; mpls <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Kireeti Kompella <[email-masked] <mailto:[email-masked]>>; Ron Bonica <[email-masked] <mailto:[email-masked]>>; <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>
> I just posted https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiItOdNuXbu_RIMekK2pkpOj4Mmj7b9MseV-Y$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiItOdNuXbu_RIMekK2pkpOj4Mmj7b9MseV-Y$> .
> 
> The initial version was posted to the tsvwg (https://urldefense.com/v3/__https://tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiItOdNuXbu_RIMekK2pkpOj4Mmj7b5lS_Jea$ <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiItOdNuXbu_RIMekK2pkpOj4Mmj7b5lS_Jea$> ). After discussions/feedback we are re-homing it to intarea wg. This new version also contains quite some changes based on the comments and feedback that we received (special thanks to Stewart).
>

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Feb 2021 01:30:16 +0100

Hi Jeff, *.

I am very supportive of i think what could be the spirit of this draft (and similar
drafts that Stewart mentioned exist), but i am quite worried about some of the
current fundamentals:

This looks a lot like

"i have a point problem (MPLS fragmentation), but to sell it better, i will give it a more
inclusive name, but i don't really care that much about the other 99% opportunity/challenges".
(not that i am blaming you for trying, just wanting to point this out ;-)

Aka: before this type of draft can earn its ambitious name i think it needs to support
a lot more use cases and include solutions for "generic" problems. 

For example:

- If something claims to be "generic" but does not propose to apply it to what is our
  tier 1 protocol, IPv6, then its more like "generic  for the leftover (non IPv6)", and 
  we will continue to still have to provide (unnecessarily) multiple options to do the
  same thing. Aka: superceeding and replacing existing IPv6 extension options would be
  the most solid and important stake in the ground to claim "generic".

- If we want IEEE to use this, there needs to be a) more work on how to use it with
  ethernet,and b) a way to establish different code-point registries, so IEEE could
  define options for this header by themselves. At least IMHO to maximize the opportunity
  for IEEE to drive this forwrd.

  I am saying this also because in my non-scientific opinion, the likelyhood for better
  QoS extension headers to be built are much better if we leave it up to IEEE and then
  inherit what they have done. Which could be helped by an extension header that IEEE would
  like to use and extend but that would also easily be able to be used with MPLS and IP.
  At least that's my somewhat frustrated opinion about IETFs progress on Qos given
  how we still think after 40 years "8 TOS bits are good enough forever",  L4S trying
  to overload an ECN bit, and only MPLS having been able to partially catch up in DetNet
  with what TSN did in ethernet.

- We ultimately will have layers of header to which such a header could be applied,
  such as ethernet+mpls+ip, and quite frankly i think we need a way to be able to have
  such a header only once instead of replicating it three times, which is what we typically
  would do these days if we needed the processing at all three layers. Aka: push up/down
  the header whenever we push/pop one of the encapsulations. Just as one idea.

- Encoding and forwarding plane support requirements for future extensions. Aka: i don't
  want to see for any future extensions the typical never ending discussions about what
  would be an appropriate way to encode them so that all hardware can support it. I think we 
  should have enough of that problem in the wake of SRH now in Spring. If we want to call
  something generic, it should define mandatory encoding rules to be supported for any
  future extensions. Of course, this doesn't say that any extension function could be
  supported by any hardware, but it gets us one step closer. FOr example by codifying
  a mandatory encoding for variable length / optional parameters.

Without any intent to work on such broader strategy aspects, the use of the word
"generic" is IMHO inappropriate.

Cheers
    Toerless

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 22 Feb 2021 17:00:27 -0800

Hi Jeffrey,
I have read the draft and find it very interesting. I've got a question,
perhaps we can discuss:

   - if I understand it correctly, GDFH shim creates a new network layer.
   How you envision OAM at that layer can be identified? BIER uses protocol
   type. MPLS - GAL. IP - ICMP and, in UDP transport, well-known port numbers
   as the destination. Could it be assigned value from This Header registry?
   (Note, that This Header and Header Length appear swapped in Fig.2 compared
   to Fig.3 and Fig.4)

Regards,
Greg

On Mon, Feb 22, 2021 at 2:44 PM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> I did design it to advertise a GDF label so that we know that a GDFH is at
> BoS; and I make the GDFH start with 0000b so that it won’t be mistaken as
> an IP header.
>
>
>
> I was incorrectly thinking that IOAM was using GAL, so I was thinking, if
> IOAM (which I think it is user traffic with OAM info embedded) could use
> GAL, then perhaps GAL’s restriction for user-traffic could be lifted, and
> in that case GDF go with G-ACH using GAL.
>
>
>
> Now I realize that I can’t really use GAL. In that case, I think it’s
> better to be independent of PW and G-ACH – this is not only the
> fragmentation function.
>
>
>
> Thanks.
> Jeffrey
>
>
>
> *From:* Stewart Bryant <[email-masked]>
> *Sent:* Monday, February 22, 2021 5:39 AM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> *Cc:* Stewart Bryant <[email-masked]>; Rakesh Gandhi <
> [email-masked]>; Yangfan (IP Standard <[email-masked]>;
> Greg Mirsky <[email-masked]>; mpls <[email-masked]>;
> [email-masked]; Kireeti Kompella <[email-masked]>; Ron Bonica <
> [email-masked]>; <[email-masked]> <[email-masked]>; [email-masked]
> *Subject:* Re: [mpls] draft-zzhang-intarea-generic-delivery-functions
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> The way that a forwarder processing a PW  knows that a CW follows is
> because it is a parameter of the FEC of the PW label that is BoS.
>
>
>
> IF you want to run OAM on an MPLS LSP as we do in MPLS-TP you have no CW
> so you need another method of indicating the presence of the ACH and the
> way that is done is with a GAL.
>
>
>
> The cleanest way to put fragmentation information at the BoS is to create
> a new type MPLS payload construct the “fragwire” if you like push the
> metadata, push a label advertised by the recipient that says that this is
> what is being done, then just the delivery label.
>
>
>
> You have to know that the target can do this, so the target can advertise
> or otherwise provide a label saying what it needs as an indicator.
>
>
>
> It came to me though, the IOAM header could become a GDFH 😊 It can then
> be used for all transportations (MPLS, BIER, or even ethernet).
>
>
>
> I see that in your -06 version you treat IOAM as  a G-ACH channel. That
> does not seem to go well with the following in RFC 5586:
>
>
>
> But I don’t understand why you need an “IOAM Indicator Label” – there is
> already a special label G-ACh Label (GAL).
>
> For GDFH, I had designed to advertise regular labels to indicate that a
> GDFH follows (I am always a good citizen when it comes to requesting
> special labels). Seeing that G-Ach uses the GAL, and the following:
>
>
>
> If the user traffic restriction could be lifted, it’s tempting to treat
> GDFH as a G-Ach channel type. That way we don’t need to advertise GDFH
> labels.
>
>
>
> To answer Yangfan’s question “what is the difference compared to G-AC” in
> another email: GDFH is for generic delivery function over different
> transports, and even when it is used over MPLS it is different from the
> (original intention of) G-ACH. However, as mentioned above, it’s tempting
> to treat GDFH as a channel type just to be able use the already assigned
> GAL.
>
>
>
> Thanks.
> Jeffrey
>
>
>
> *From:* Rakesh Gandhi <[email-masked]>
> *Sent:* Thursday, February 18, 2021 6:49 PM
> *To:* Stewart Bryant <[email-masked]>
> *Cc:* Jeffrey (Zhaohui) Zhang <[email-masked]>; mpls <[email-masked]>;
> [email-masked]; Kireeti Kompella <[email-masked]>; Ron Bonica <
> [email-masked]>; <[email-masked]> <[email-masked]>; [email-masked]
> *Subject:* Re: [mpls] draft-zzhang-intarea-generic-delivery-functions
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Stewart,
>
> Hi Xiao, Loa,
>
> FYI:
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-gandhi-mpls-ioam-sr-06__;!!NEt6yMaO-gk!VXglGy7lcO2Pe-wXQDgZaYzzz0Ckq57ZSdkkJ0Sz5yTrNvCrxSb9ClooNfsG5fW-$>
>
>
>
> Thanks for your review.
>
> Regards,
>
> Rakesh
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/__;!!NEt6yMaO-gk!VXglGy7lcO2Pe-wXQDgZaYzzz0Ckq57ZSdkkJ0Sz5yTrNvCrxSb9ClooNQ3VcEYN$>
> .
> >
> https://tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00__;!!NEt6yMaO-gk!VXglGy7lcO2Pe-wXQDgZaYzzz0Ckq57ZSdkkJ0Sz5yTrNvCrxSb9ClooNdw0REUd$>).
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!VXglGy7lcO2Pe-wXQDgZaYzzz0Ckq57ZSdkkJ0Sz5yTrNvCrxSb9ClooNd2pzrpq$>
>
>
>

---

From: "Yangfan (IP Standard)" <[email-masked]>
Date: Tue, 23 Feb 2021 08:05:54 +0000

Hi Toerless and Jeffrey,

I have some comments, and also bring another thread to this topic, please see inline.

Regards,

Fan

-----邮件原件-----
发件人: Pals [mailto:[email-masked]] 代表 Toerless Eckert
发送时间: 2021年2月23日 8:30
收件人: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
抄送: Kireeti Kompella <[email-masked]>; mpls <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]; [email-masked]
主题: Re: [Pals] [Int-area] draft-zzhang-intarea-generic-delivery-functions

Hi Jeff, *.

I am very supportive of i think what could be the spirit of this draft (and similar drafts that Stewart mentioned exist), but i am quite worried about some of the current fundamentals:

This looks a lot like

"i have a point problem (MPLS fragmentation), but to sell it better, i will give it a more inclusive name, but i don't really care that much about the other 99% opportunity/challenges".

Aka: before this type of draft can earn its ambitious name i think it needs to support a lot more use cases and include solutions for "generic" problems.

[yf]: agree. The use cases are important to be recognized at first, as it is always the principle of defining protocols in IETF.

For example:

[yf]: I support to make maximum use of existing IPv6 extension options to enhance the capability of IP itself, at least we should get started to explore this direction.

Here I have to interrupt and bring another thread to this topic. My colleagues and I uploaded a new I-D yesterday in rtgwg, called "associated channel over IPv6" (https://tools.ietf.org/html/draft-yang-rtgwg-ipv6-associated-channel-00 ). The IPv6 based associated channel is provided to carry types of control and management messages, aiming to provide functions like path identification, OAM, etc. Sharing similar vision, it gives an attempt to IPv6. We would like to hear your comments and feedbacks.

Without any intent to work on such broader strategy aspects, the use of the word "generic" is IMHO inappropriate.

Cheers

    Toerless

Pals mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/pals

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 23 Feb 2021 14:01:11 +0000

Hi Toerless,

Thank you for your comments.
Please see zzh> below.

-----Original Message-----
From: Toerless Eckert <[email-masked]>
Sent: Monday, February 22, 2021 7:30 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]; mpls <[email-masked]>; [email-masked]; Kireeti Kompella <[email-masked]>; Ron Bonica <[email-masked]>
Subject: Re: [Int-area] draft-zzhang-intarea-generic-delivery-functions

Hi Jeff, *.

This looks a lot like

Zzh> To the contrary, this did not start as an MPLS fragmentation point problem (though almost everything starts with something small and the key is to make the solution generic w/o making it unmanageable). It actually started in BIER - we realize that some functions at IP layer could be abstracted out from IP and apply at BIER layer directly; then we realize that the same can be applied to mpls, and even Ethernet (if IEEE do care about it). That's on the dimension of different lower layers.
Zzh> Now IOAM comes into the picture; while we have not come to consensus yet, but it seems that IOAM could also use the GDF header. That's on the dimension of different functions that can be supported.
Zzh> Yet another example is a *by-product* of this. Believe it or not, we did not do this so to be able to tell the payload type after MPLS, but Stewart pointed it out this may give a backdoor way of indicating MPLS payload type. If MPLS WG concludes that is good, it can certainly be standardized, but it is really not our hidden agenda 😊

Zzh> The above mentioned some examples. More use cases could come up, and more importantly, unless it is proven that this is not generic, then why can't it be called so 😊

For example:

Zzh> For existing IP functions that could be abstracted out to GDF, it certainly does not make sense to switching them to GDF, but it is good to be able to apply them to other layers; for future functions that may be applicable to both IPv6 and other layers, if they are done via GDF, it would be preferred, and more importantly the "next header" in IPv6 could be a GDFH.

Zzh> Agree. It has already been discussed to start talking to IEEE folks; of course, if this can't even take off in IETF, then it probably won't go well in IEEE.

Zzh> This is a very good point for start working with IEEE early; of course the precondition is that IETF itself is open to the proposal.

Zzh> If you need the same *type of* functions done different layers (which likely would be at different nodes), different GDFHs (of the same type) would be put into different places of the headers chain.
Zzh> If you're referring to the *same function* done at different layers, and push up/down the *same header* whenever you push/pop of the encapsulations, I can't think of a concrete example now, but maybe it can be worked out.

Zzh> For all the lessons we've learned, we can evaluate if they can be applied to the GDF. We can start with looking at the current GDFH proposals to see if addresses known problems that we want/need to address.

Zzh> Of course we want to consider all those broader strategy aspects and make it truely as generic as possible. I don't think we should be so hung up on the "generic" name. Can we start with this, and rename it down the road to something more appropriate if we conclude that it does not deserve the noble name?
Zzh> Thanks!
Zzh> Jeffrey

Cheers
    Toerless

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 23 Feb 2021 15:18:38 +0000

Hi Stewart,

GDFH has both a “this header” (for a particular function) and a “next header”. One GDFH can point to another GDFH, who could also point to another header (e.g. MPLS).

IOAM could be integrated into GDF. I understand that this is just a thought and we have not concluded on that yet, but with that thought the headers would be like the following:

   Transport label + GDFH label (BoS) + GDFH (for IOAM) + GDFH (for other functions not already provided by PW itself) + PW label + PW payload or G-Ach

Depending on the situation, the GDFH (for IOAM) and GDFH (for other functions) could be swapped. The PW label is essentially another label stack – the earlier stack stopped at the GDFH label.

Now what if IOAM is not integrated into GDF? I see the following in its -06 revision:
    0                   1                   2                   3
    ~                 Payload + Padding                             ~

     Figure 5: Example MPLS Encapsulation with Another G-ACh with IOAM

I am not sure if that is a good idea:

  *   RFC 5586 says “The G-ACh MUST NOT be used to transport user traffic”. To me IOAM traffic is user traffic with OAM information.
  *   It puts one G-Ach header after another G-Ach header. As far as I understand it, G-Ach does not have a “next header” concept and using 0001b to indicate that another G-Ach header follows is not safe.
  *   In case PW payload, the above will put the PW label before the IOAM label. Having those extra IOAM/G-Ach headers between the PW+IOAM label and PW payload adds complexity to the fast path processing.

Jeffrey

- Stewart

On 22 Feb 2021, at 22:49, Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:

Hi Stewart,

Thanks.
Jeffrey

      0                   1                   2                   3

0001 means ACH

Stewart

Hi Stewart,

Thanks.
Jeffrey

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang
Sent: Thursday, February 18, 2021 10:35 PM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Stewart, all,

Thanks.
Jeffrey

-----Original Message-----
From: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 12, 2021 9:59 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

Thank you Jeffery

- Stewart

Hi,

Thanks.
Jeffrey

---

From: John E Drake <[email-masked]>
Date: Tue, 23 Feb 2021 15:27:46 +0000

Hi,
Why wouldn't we just use GAL/G-ACh for this as it is already a published RFC that was designed for things like this?   I.e., we could use a GAL and define families of G-ACh codepoints which describe exactly what is in the area between the MPLS label stack and the payload.  E.g.,  G-Ach for IOAM:  [value #1 = hop by hop IOAM w/ no subsequent metadata, value #2 = end to end IOAM w/ no subsequent metadata, value #3 = hop by hop IOAM w/ subsequent metadata, value #4 = end to end IOAM w/ subsequent metadata].  The subsequent metadata would then have the same basic structure.
Yours Irrespectively,

John

Juniper Business Use Only
From: mpls <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Tuesday, February 23, 2021 10:19 AM
To: Stewart Bryant <[email-masked]>; Rakesh Gandhi <[email-masked]>
Cc: mpls <[email-masked]>; [email-masked]; Kireeti Kompella <[email-masked]>; Ron Bonica <[email-masked]>; <[email-masked]> <[email-masked]>; [email-masked]
Subject: Re: [mpls] draft-zzhang-intarea-generic-delivery-functions

Hi Stewart,

GDFH has both a "this header" (for a particular function) and a "next header". One GDFH can point to another GDFH, who could also point to another header (e.g. MPLS).

Depending on the situation, the GDFH (for IOAM) and GDFH (for other functions) could be swapped. The PW label is essentially another label stack - the earlier stack stopped at the GDFH label.

  *   RFC 5586 says "The G-ACh MUST NOT be used to transport user traffic". To me IOAM traffic is user traffic with OAM information.
  *   It puts one G-Ach header after another G-Ach header. As far as I understand it, G-Ach does not have a "next header" concept and using 0001b to indicate that another G-Ach header follows is not safe.
  *   In case PW payload, the above will put the PW label before the IOAM label. Having those extra IOAM/G-Ach headers between the PW+IOAM label and PW payload adds complexity to the fast path processing.

Jeffrey

- Stewart

Hi Stewart,

This thread started with your comment "Please see the note that I sent about iOAM who also want to sit after BoS ... and both of you want the same space that PALS and DetNet is already using", but now it seems that we're on the same page - GDFH starting with 0000b is fine and is not competing with IOAM or PW/DETNET CW?

Thanks.
Jeffrey

      0                   1                   2                   3

0001 means ACH

Stewart

Hi Stewart,

Thanks.
Jeffrey

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang
Sent: Thursday, February 18, 2021 10:35 PM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Stewart, all,

Thanks.
Jeffrey

-----Original Message-----
From: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 12, 2021 9:59 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

Thank you Jeffery

Please see the note that I sent about iOAM who also want to sit after BoS ... and both of you want the same space that PALS and DetNet is already using.

- Stewart

Hi,

Thanks.
Jeffrey

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 23 Feb 2021 15:33:47 +0000

> On 23 Feb 2021, at 15:18, Jeffrey (Zhaohui) Zhang <[email-masked]> wrote:
> 
> RFC 5586 says “The G-ACh MUST NOT be used to transport user traffic”. To me IOAM traffic is user traffic with OAM information.

Correct on both counts. Though we could change the 5586 restriction. It would only be a problem for receiving LSRs that needed to do this and not on path LSRs, and if you need to do this function you need to change the forwarder anyway.

> It puts one G-Ach header after another G-Ach header. As far as I understand it, G-Ach does not have a “next header” concept and using 0001b to indicate that another G-Ach header follows is not safe.
Correct. 

The PW label says that what follows is a CW

The CW may preceded PW payload, or precede stuff defined by the ACH type.

An ACH (A1)  followed by an ACH (A2) is only defined if the A1 tells the forwarder to expect another ACH. We could change that definition, but I am concerned we rapidly enter extension header hell which may be OK if it is where we want to go.

> In case PW payload, the above will put the PW label before the IOAM label. Having those extra IOAM/G-Ach headers between the PW+IOAM label and PW payload adds complexity to the fast path processing.

Yes and you forgot any entropy labels that may be hanging about in the stack.

- Stewart

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 23 Feb 2021 15:35:39 +0000

Hi John,

It's not clear that GAL/G-ACH is designed for situations like this. Please see my comments at the end of my reply to Stewart, which I am copying here:

Jeffrey

From: John E Drake <jdrake=[email-masked]>
Sent: Tuesday, February 23, 2021 10:28 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Stewart Bryant <[email-masked]>; Rakesh Gandhi <[email-masked]>
Cc: mpls <[email-masked]>; [email-masked]; Kireeti Kompella <[email-masked]>; Ron Bonica <[email-masked]>; <[email-masked]> <[email-masked]>; [email-masked]
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Hi,

John

Juniper Business Use Only
From: mpls <[email-masked]<mailto:[email-masked]>> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Tuesday, February 23, 2021 10:19 AM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] draft-zzhang-intarea-generic-delivery-functions

Hi Stewart,

Jeffrey

- Stewart

Hi Stewart,

Thanks.
Jeffrey

      0                   1                   2                   3

0001 means ACH

Stewart

Hi Stewart,

Thanks.
Jeffrey

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang
Sent: Thursday, February 18, 2021 10:35 PM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Stewart, all,

Thanks.
Jeffrey

-----Original Message-----
From: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 12, 2021 9:59 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

Thank you Jeffery

- Stewart

Hi,

Thanks.
Jeffrey

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 23 Feb 2021 15:36:24 +0000

Having an ACH channel type per set of structures, or a BoS label value per set of structures would be far more consistent with the MPLS model.

Stewart

> On 23 Feb 2021, at 15:27, John E Drake <[email-masked]> wrote:
> 
> Hi,
> Why wouldn’t we just use GAL/G-ACh for this as it is already a published RFC that was designed for things like this?   I.e., we could use a GAL and define families of G-ACh codepoints which describe exactly what is in the area between the MPLS label stack and the payload.  E.g.,  G-Ach for IOAM:  [value #1 = hop by hop IOAM w/ no subsequent metadata, value #2 = end to end IOAM w/ no subsequent metadata, value #3 = hop by hop IOAM w/ subsequent metadata, value #4 = end to end IOAM w/ subsequent metadata].  The subsequent metadata would then have the same basic structure.
> Yours Irrespectively,
>  
> John
>  
>  
> From: mpls <[email-masked] <mailto:[email-masked]>> On Behalf Of Jeffrey (Zhaohui) Zhang
> To: Stewart Bryant <[email-masked] <mailto:[email-masked]>>; Rakesh Gandhi <[email-masked] <mailto:[email-masked]>>
> Cc: mpls <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Kireeti Kompella <[email-masked] <mailto:[email-masked]>>; Ron Bonica <[email-masked] <mailto:[email-masked]>>; <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On 22 Feb 2021, at 22:49, Jeffrey (Zhaohui) Zhang <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Stewart,
>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 23 Feb 2021 15:41:19 +0000

> 
> It’s not clear that GAL/G-ACH is designed for situations like this.

It definitely was not intended to do this when we designed the CW or when we designed the ACH.

- Stewart

---

From: John E Drake <[email-masked]>
Date: Tue, 23 Feb 2021 15:49:43 +0000

Stewart,

That would be fine too.  The reason I suggested multiple G-ACh structures was to allow each function to evolve independently but it's not a big deal.  Multiple labels, each with the BoS set, was suggested during the MPLS-TP days (Niel Harrison, in particular, was a big proponent) but was shot down because it would apparently break existing hardware implementations.

Yours Irrespectively,

John

Juniper Business Use Only
From: Stewart Bryant <[email-masked]>
Sent: Tuesday, February 23, 2021 10:36 AM
To: John E Drake <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>; Rakesh Gandhi <[email-masked]>; mpls <[email-masked]>; [email-masked]; Kireeti Kompella <[email-masked]>; Ron Bonica <[email-masked]>; <[email-masked]> <[email-masked]>; [email-masked]
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

Stewart

On 23 Feb 2021, at 15:27, John E Drake <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

John

Hi Stewart,

Jeffrey

- Stewart

Hi Stewart,

Thanks.
Jeffrey

      0                   1                   2                   3

0001 means ACH

Stewart

Hi Stewart,

Thanks.
Jeffrey

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang
Sent: Thursday, February 18, 2021 10:35 PM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Stewart, all,

Thanks.
Jeffrey

-----Original Message-----
From: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 12, 2021 9:59 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

Thank you Jeffery

- Stewart

Hi,

Thanks.
Jeffrey

---

From: John E Drake <[email-masked]>
Date: Tue, 23 Feb 2021 16:01:27 +0000

Hi,

Defining a new protocol as opposed to extending an existing protocol unfortunately seems to be too common in the IETF and ends up with a proliferation of protocols that all do more or less the same things and each of which has a multiplicity of issues.

Yours Irrespectively,

John

Juniper Business Use Only
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: Tuesday, February 23, 2021 10:36 AM
To: John E Drake <[email-masked]>; Stewart Bryant <[email-masked]>; Rakesh Gandhi <[email-masked]>
Cc: mpls <[email-masked]>; [email-masked]; Kireeti Kompella <[email-masked]>; Ron Bonica <[email-masked]>; <[email-masked]> <[email-masked]>; [email-masked]
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Hi John,

Jeffrey

From: John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>
Sent: Tuesday, February 23, 2021 10:28 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Stewart Bryant <[email-masked]<mailto:[email-masked]>>; Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Hi,

John

Hi Stewart,

Jeffrey

- Stewart

Hi Stewart,

Thanks.
Jeffrey

      0                   1                   2                   3

0001 means ACH

Stewart

Hi Stewart,

Thanks.
Jeffrey

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang
Sent: Thursday, February 18, 2021 10:35 PM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Stewart, all,

Thanks.
Jeffrey

-----Original Message-----
From: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 12, 2021 9:59 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

Thank you Jeffery

- Stewart

Hi,

Thanks.
Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 23 Feb 2021 16:06:54 +0000

Hi Stewart,

Could elaborate  “a BoS label value per set of structures” and “the MPLS model” and their differences?

In an earlier email, I did say (something like) the following:

If GAL is allowed for user traffic, it’s tempting to treat the first GDFH as a G-Ach channel (this is just so to be able to use the GAL), but we’d still prefer the GDFH structure proposed in the GDF draft, in particular the “this header” and “next header” concept.

Jeffrey

Cc: Stewart Bryant <[email-masked]>; Jeffrey (Zhaohui) Zhang <[email-masked]>; Rakesh Gandhi <[email-masked]>; mpls <[email-masked]>; [email-masked]; Kireeti Kompella <[email-masked]>; Ron Bonica <[email-masked]>; <[email-masked]> <[email-masked]>; [email-masked]

Stewart

Hi,

John

Hi Stewart,

Jeffrey

- Stewart

Hi Stewart,

Thanks.
Jeffrey

      0                   1                   2                   3

0001 means ACH

Stewart

Hi Stewart,

Thanks.
Jeffrey

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang
Sent: Thursday, February 18, 2021 10:35 PM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Stewart, all,

Thanks.
Jeffrey

-----Original Message-----
From: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 12, 2021 9:59 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

Thank you Jeffery

- Stewart

Hi,

Thanks.
Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 23 Feb 2021 15:32:56 +0000

Hi Greg,

It does not create a new “network layer”. Rather, it provides a function shim/layer (?) between two points at a l2/l2.5/l3/whatever layer.
Yes if some OAM function can be extracted out to be independent of a l2/l2.5/l3/whatever layer, then a GDFH “this header” code point can be registered to indicate it is for OAM purpose and corresponding header format will be determined from the ‘this header’ code point.

As you can see in other emails of this thread, I am thinking that IOAM can be implemented as a GDFH. Of course that’s subject to further discussions.

Thanks for pointing out that I have the “This Header and Header Length” swapped in Figure 2. I’ll fix that.

Thanks.
Jeffrey

From: Greg Mirsky <[email-masked]>
Sent: Monday, February 22, 2021 8:00 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; Rakesh Gandhi <[email-masked]>; Yangfan (IP Standard <[email-masked]>; mpls <[email-masked]>; [email-masked]; Kireeti Kompella <[email-masked]>; Ron Bonica <[email-masked]>; <[email-masked]> <[email-masked]>; [email-masked]
Subject: Re: [mpls] draft-zzhang-intarea-generic-delivery-functions

Hi Jeffrey,
I have read the draft and find it very interesting. I've got a question, perhaps we can discuss:

  *   if I understand it correctly, GDFH shim creates a new network layer. How you envision OAM at that layer can be identified? BIER uses protocol type. MPLS - GAL. IP - ICMP and, in UDP transport, well-known port numbers as the destination. Could it be assigned value from This Header registry? (Note, that This Header and Header Length appear swapped in Fig.2 compared to Fig.3 and Fig.4)
Regards,
Greg

On Mon, Feb 22, 2021 at 2:44 PM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Stewart,

Thanks.
Jeffrey

Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>; Yangfan (IP Standard <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

- Stewart

Hi Rakesh, Yangfan,

    0                   1                   2                   3

Thanks.
Jeffrey

Hi Stewart,
Hi Xiao, Loa,
FYI:

Thanks for your review.
Regards,
Rakesh

Thanks,
Rakesh

- Stewart

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Feb 2021 21:03:06 +0100

Thanks, Jeff, inline.

On Tue, Feb 23, 2021 at 02:01:11PM +0000, Jeffrey (Zhaohui) Zhang wrote:
> Zzh> To the contrary, this did not start as an MPLS fragmentation point problem (though almost everything starts with something small and the key is to make the solution generic w/o making it unmanageable). 

It just reads that way though.

It actually started in BIER - we realize that some functions at IP layer could be abstracted out from IP and apply at BIER layer directly; then we realize that the same can be applied to mpls, and even Ethernet (if IEEE do care about it). That's on the dimension of different lower layers.

Nice.

One of my thoughts on the very same topic is that we should have
just build IPv6 with variable length addresses so thart we could have
added BIER semantics to a subtree of a larger address length space in the
same way as we managed to add IP Multicast semantics to existing IPv4
(and later IPv6) but just luckily because the IP Multicast semantic
allowed to rely on 32 bit long multicast addresses, whereas BIER
isn't even (IMHO) very happy with only 128 bit.

Of course, the benefit if we had BIER inside of IP would be huge because
like IP multicast it would jus be there, leaking through existing APIs
(like IP Multicast did initially), putting a lot more effort on all
communities to make the new, added semantic work - as opposed to
(if i may sound depressed) continue to ignore it like what i think happens
in many dependencies (API etc.) for BIER.

Simply being able to reuse existing forwarding plan functions that
have maybe been defined for IPv6 is just IMHO a second best approach
to actually having a more extensible network layer in the first place.

And IP did survive IP Multicast. IMHO building a superset of IPv6
wih additional address semantics that could also support BIER or
MPLS addresses would not kill IPv6 as it exists today either.

Sorry for the rant...

> Zzh> Now IOAM comes into the picture; while we have not come to consensus yet, but it seems that IOAM could also use the GDF header. That's on the dimension of different functions that can be suppo…

I certainly would like to see a lot of the thoughts around all of this
to be reflected by more of the community coming together and thinking
how to build these things for better long-term benefit. In comparison:
We managed to show enough solid archicture and impleemntation
functionality for BIER to move it from experimental to standard
after how many years ? 4 ? I think for any of the changes we're talking
here, that are meant to span multiple nework protocols, i really would love
to see a long experimental time frame in which research or other
experimental network collect experience and hopfully improve and integrate
the stuff better. 

> Zzh> For existing IP functions that could be abstracted out to GDF, it certainly does not make sense to switching them to GDF, but it is good to be able to apply them to other layers; for future fu…

You're not saying why you don't think existing IPv6 services should move to GDF,
but i would assume you want to avoid unnecessary churn. But there is also unnecessary
churn to keep to parallel solutions for the same thing alive.

Of course there is always a migration isue, but unless we develop stragies
for those better, we're dead in the water evolving the value propositions of this
industry anyhow. A simple one of course is "accept old, generate new" or the like.

> Zzh> Agree. It has already been discussed to start talking to IEEE folks; of course, if this can't even take off in IETF, then it probably won't go well in IEEE.

To me, the big elephant in he room is that IETF work is loosing relevance in many
markets compared to IEEE, because IP routing is just replaced by ethernet switching,
and it could become as bad as IP routing only happening at any form of administrative
or bolicy border. So it should be in the interest of the IETF to figure out what
it should do about that (if people agree this is happening). I for once think that
decoupling as many forwarding plane functions that IETF can offer from "IP routing"
and making them applicable for any forwarding protocol could be a big part of this.
But i do obviously fear that IEEE might have more to offer for IP routing.

But yeah. Reusing technologies across SDO this way would be very new, and control
has often been a driving force in SDO decisions, and this is unexplored territory
(sharing).

> Zzh> If you're referring to the *same function* done at different layers, and push up/down the *same header* whenever you push/pop of the encapsulations, I can't think of a concrete example now, bu…

Whenever i have a customer packet entering a PE getting encapsulated into th SP transport
(MPLS, SRv6), i would today have to figure out what services header to add to that
encap.  With that services heder reuseable across protocols i could duplicate+filter the
CE header. Thats obvious. But if th services heder becomes larger (think a lot more iOAM
or DetNet stuff), i may not want to duplicate but just use the one existing header. Just
figure out how to build the packet header chain to ensure that on the "decap side" it
ges put back.

Remember how MPLS for steering is also a lot more lightweight than classical encap-tunnels.
Likewise, these approaches could make services other than steering be similarily more
lightweight.

> Zzh> Of course we want to consider all those broader strategy aspects and make it truely as generic as possible. I don't think we should be so hung up on the "generic" name. Can we start with this,…

Not sure if "generic" is noble ;-) Its great if it ambitious. Its not great
if the goals are not as ambitious as the name implies ;-)

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 25 Feb 2021 15:02:33 +0000

Hi Jeffrey,
I do not think we should mix IOAM and GDF. They are completely different use-cases with different requirements. Let’s please not overload definitions of labels and GACH/CW header.

For each label in the received packet, there is a corresponding one-to-one CWGACH header (that contains it’s length) in the packet in the right order.  E.g. for PW Label, IOAM Label or GDF Label. So there is no ambiguity. Good thing is all labels would be together in the label stack before EOS (good for label based hashing). And similarly, all CW/GACH header are together right after the EOS in the matching order.

Node supporting IOAM needs to be upgraded anyways, so it can easily process IOAM in GACH for data packets.

IOAM uses different labels for different processing, hence overloading with a single label requires extra (lot more IOAM) processing in fast path.

Thanks,
Rakesh

From: mpls <[email-masked]> on behalf of Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Date: Tuesday, February 23, 2021 at 10:39 AM
To: John E Drake <jdrake=[email-masked]>, Stewart Bryant <[email-masked]>, Rakesh Gandhi <[email-masked]>
Cc: mpls <[email-masked]>, [email-masked] <[email-masked]>, Kireeti Kompella <[email-masked]>, Ron Bonica <[email-masked]>, <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [mpls] draft-zzhang-intarea-generic-delivery-functions

Hi John,

It’s not clear that GAL/G-ACH is designed for situations like this. Please see my comments at the end of my reply to Stewart, which I am copying here:

Jeffrey

Hi,

John

Hi Stewart,

Jeffrey

- Stewart

Hi Stewart,

Thanks.
Jeffrey

      0                   1                   2                   3

0001 means ACH

Stewart

Hi Stewart,

Thanks.
Jeffrey

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang
Sent: Thursday, February 18, 2021 10:35 PM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Stewart, all,

Thanks.
Jeffrey

-----Original Message-----
From: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 12, 2021 9:59 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

Thank you Jeffery

- Stewart

Hi,

Thanks.
Jeffrey

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 25 Feb 2021 21:53:30 -0000

> Multiple labels, each with the BoS set, was suggested during the MPLS-TP
days

> (Niel Harrison, in particular, was a big proponent) but was shot down
because it

> would apparently break existing hardware implementations. 

Yeah, I was a big fan of that. I even thought it was architecturally the
right thing to do for carrying one MPLS service over an MPLS transport. It
would have solved many of the MPLS-TP requirements.

But as John says, lots of hardware then (and probably now) sees bottom of
stack and starts to sniff the next nibble. Thus, contiguous label stacks and
control words were the only viable solution. It took George Swallow a while
to beat this into my head.

Cheers,

Adrian

From: Stewart Bryant <[email-masked]> 
Sent: Tuesday, February 23, 2021 10:36 AM
To: John E Drake <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; Jeffrey (Zhaohui) Zhang
<zzhang=[email-masked]>; Rakesh Gandhi
<[email-masked]>; mpls <[email-masked]>; [email-masked]; Kireeti
Kompella <[email-masked]>; Ron Bonica <[email-masked]>;
<[email-masked]> <[email-masked]>; [email-masked]
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

Having an ACH channel type per set of structures, or a BoS label value per
set of structures would be far more consistent with the MPLS model. 

Stewart

On 23 Feb 2021, at 15:27, John E Drake <[email-masked]
<mailto:[email-masked]> > wrote:

Hi,

Why wouldn't we just use GAL/G-ACh for this as it is already a published RFC
that was designed for things like this?   I.e., we could use a GAL and
define families of G-ACh codepoints which describe exactly what is in the
area between the MPLS label stack and the payload.  E.g.,  G-Ach for IOAM:
[value #1 = hop by hop IOAM w/ no subsequent metadata, value #2 = end to end
IOAM w/ no subsequent metadata, value #3 = hop by hop IOAM w/ subsequent
metadata, value #4 = end to end IOAM w/ subsequent metadata].  The
subsequent metadata would then have the same basic structure.

Yours Irrespectively,

John

From: mpls <[email-masked] <mailto:[email-masked]> > On Behalf
Of Jeffrey (Zhaohui) Zhang
Sent: Tuesday, February 23, 2021 10:19 AM
To: Stewart Bryant <[email-masked]
<mailto:[email-masked]> >; Rakesh Gandhi <[email-masked]
<mailto:[email-masked]> >
Cc: mpls <[email-masked] <mailto:[email-masked]> >; [email-masked]
<mailto:[email-masked]> ; Kireeti Kompella <[email-masked]
<mailto:[email-masked]> >; Ron Bonica <[email-masked]
<mailto:[email-masked]> >; <[email-masked] <mailto:[email-masked]>
> <[email-masked] <mailto:[email-masked]> >; [email-masked]
<mailto:[email-masked]> 

Hi Stewart,

GDFH has both a "this header" (for a particular function) and a "next
header". One GDFH can point to another GDFH, who could also point to another
header (e.g. MPLS).

IOAM could be integrated into GDF. I understand that this is just a thought
and we have not concluded on that yet, but with that thought the headers
would be like the following:

   Transport label + GDFH label (BoS) + GDFH (for IOAM) + GDFH (for other
functions not already provided by PW itself) + PW label + PW payload or
G-Ach

Depending on the situation, the GDFH (for IOAM) and GDFH (for other
functions) could be swapped. The PW label is essentially another label stack
- the earlier stack stopped at the GDFH label.

Now what if IOAM is not integrated into GDF? I see the following in its -06
revision:

    0                   1                   2                   3

    |                                                               |  O

    |                                                               |  A

    |                                                               |  |

    |                                                               |  |

    |                                                               |

    |                                                               |

    ~                 Payload + Padding                             ~

    |                                                               |

    |                                                               |

*	RFC 5586 says "The G-ACh MUST NOT be used to transport user
traffic". To me IOAM traffic is user traffic with OAM information.
*	It puts one G-Ach header after another G-Ach header. As far as I
understand it, G-Ach does not have a "next header" concept and using 0001b
to indicate that another G-Ach header follows is not safe.
*	In case PW payload, the above will put the PW label before the IOAM
label. Having those extra IOAM/G-Ach headers between the PW+IOAM label and
PW payload adds complexity to the fast path processing.

Jeffrey

From: Stewart Bryant <[email-masked]
<mailto:[email-masked]> > 
Sent: Monday, February 22, 2021 7:30 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked] <mailto:[email-masked]>
Cc: Stewart Bryant <[email-masked]
<mailto:[email-masked]> >; [email-masked]
<mailto:[email-masked]> ; mpls <[email-masked] <mailto:[email-masked]> >;
[email-masked] <mailto:[email-masked]> ; Kireeti Kompella <[email-masked]
<mailto:[email-masked]> >; Ron Bonica <[email-masked]>;
<[email-masked] <mailto:[email-masked]> > <[email-masked]
<mailto:[email-masked]> >
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

What happens if an operator wants to run both iOAM and GDFH at the same time
and the packet is a PW packet?

- Stewart

On 22 Feb 2021, at 22:49, Jeffrey (Zhaohui) Zhang <[email-masked]
<mailto:[email-masked]> > wrote:

Hi Stewart,

This thread started with your comment "Please see the note that I sent about
iOAM who also want to sit after BoS . and both of you want the same space
that PALS and DetNet is already using", but now it seems that we're on the
same page - GDFH starting with 0000b is fine and is not competing with IOAM
or PW/DETNET CW?

Thanks.

Jeffrey

From: Stewart Bryant <[email-masked]
<mailto:[email-masked]> > 
Sent: Monday, February 22, 2021 5:15 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked] <mailto:[email-masked]>
Cc: Stewart Bryant <[email-masked]
<mailto:[email-masked]> >; [email-masked]
<mailto:[email-masked]> ; mpls <[email-masked] <mailto:[email-masked]> >;
[email-masked] <mailto:[email-masked]> ; Kireeti Kompella <[email-masked]
<mailto:[email-masked]> >; Ron Bonica <[email-masked]
<mailto:[email-masked]> >; <[email-masked] <mailto:[email-masked]>
> <[email-masked] <mailto:[email-masked]> >

 

      0                   1                   2                   3

 
 
0001 means ACH 
 
An ACH is currently defined not to carry service/user data - it is a
control/OAM channel.

In MPLS the bottom label (alone) defines how you process the payload. So you
know that you have a CW from the bottom label and by no other means.
 
In other words the the FEC of the bottom label and its associated parameters
are the way that signalling protocol knows what instructions to give the
forwarder, and the way that the forwarder knows what to do with the packet
is from the instructions associated with the BoS label. This is the
universal model for MPLS including for IP packets.
 
Stewart

On 19 Feb 2021, at 15:42, Jeffrey (Zhaohui) Zhang <[email-masked]
<mailto:[email-masked]> > wrote:

Hi Stewart,

I still have to read more about DetNet, but I am not sure if there is a real
contention with PALS.

My understanding of 0000 nibble in PW control world is that it is only to
prevent a transit node from mistaking the payload as IP. Is it supposed to
indicate that any payload starting with 0000 is PW payload? I hope not.

Use of 0000 nibble in GDFH is also just to prevent transit nodes from
mistaking it as IP. It does indicate it is GDFH. It should be able to
co-exist with PW CW.

Thanks.
Jeffrey

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang
Sent: Thursday, February 18, 2021 10:35 PM
To: Stewart Bryant <[email-masked]
<mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; mpls <[email-masked]
<mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Kireeti
Kompella <[email-masked] <mailto:[email-masked]> >; Ron Bonica
<[email-masked] <mailto:[email-masked]> >; <[email-masked]
<mailto:[email-masked]> > <[email-masked] <mailto:[email-masked]> >
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Stewart, all,

I apologize for not responding to this in time. I some how accidentally
moved a few wg mailing list email folders to a place where I could not see
so I missed all the discussions.
Let me catch up all the emails and then reply.

Thanks.
Jeffrey

-----Original Message-----
From: Stewart Bryant <[email-masked]
<mailto:[email-masked]> >
Sent: Tuesday, January 12, 2021 9:59 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked] <mailto:[email-masked]>
Cc: Stewart Bryant <[email-masked]
<mailto:[email-masked]> >; [email-masked]
<mailto:[email-masked]> ; mpls <[email-masked] <mailto:[email-masked]> >;
[email-masked] <mailto:[email-masked]> ; Kireeti Kompella <[email-masked]
<mailto:[email-masked]> >; Ron Bonica <[email-masked]
<mailto:[email-masked]> >; <[email-masked] <mailto:[email-masked]>
> <[email-masked] <mailto:[email-masked]> >

Thank you Jeffery

Please see the note that I sent about iOAM who also want to sit after BoS .
and both of you want the same space that PALS and DetNet is already using.

We plan to have a joint session on this hosted by PALS at the next IETF, but
I think we also need to include the iOAM people.

This has scope to get very messy as we find new candidates for BoS metadata
so we really need to take a holistic position to ensure the future health
the MPLS protocol.

- Stewart

On 12 Jan 2021, at 14:27, Jeffrey (Zhaohui) Zhang <[email-masked]
<mailto:[email-masked]> > wrote:

Hi,

I just posted
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-zzhang-in
tarea-generic-delivery-functions/__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kx
FtiItOdNuXbu_RIMekK2pkpOj4Mmj7b9MseV-Y$
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zzhang-in
tarea-generic-delivery-functions/__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kx
FtiItOdNuXbu_RIMekK2pkpOj4Mmj7b9MseV-Y$>  .

The initial version was posted to the tsvwg
(https://urldefense.com/v3/__https://tools.ietf.org/html/draft-zzhang-tsvwg-
generic-transport-functions-00__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFti
ItOdNuXbu_RIMekK2pkpOj4Mmj7b5lS_Jea$
<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-zzhang-tsvwg-g
eneric-transport-functions-00__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiI
tOdNuXbu_RIMekK2pkpOj4Mmj7b5lS_Jea$>  ). After discussions/feedback we are
re-homing it to intarea wg. This new version also contains quite some
changes based on the comments and feedback that we received (special thanks
to Stewart).

Thanks.
Jeffrey

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 25 Feb 2021 23:18:56 +0000

Hi Adrian,

I’m all for multiple label stacks (if meaningful).  I had put that in an early version of the FAI bSPL, with a “real end stack” bit for those woke forwarding engines that needed to know.

The hard lesson I take away from those FEs that look at the nibble following the EoS is to make sure it isn’t 0x4 or 0x6, not so much that a single label stack is the only viable solution.  So, keep this option alive ….

Cheers,
Kireeti.
From: Adrian Farrel <[email-masked]>
Date: Thursday, February 25, 2021 at 13:53
To: 'John E Drake' <jdrake=[email-masked]>, 'Stewart Bryant' <[email-masked]>
Cc: 'mpls' <[email-masked]>, [email-masked] <[email-masked]>, Kireeti Kompella <[email-masked]>, Ron Bonica <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, 'Jeffrey (Zhaohui) Zhang' <zzhang=[email-masked]>
Subject: RE: [mpls] draft-zzhang-intarea-generic-delivery-functions
> Multiple labels, each with the BoS set, was suggested during the MPLS-TP days
> (Niel Harrison, in particular, was a big proponent) but was shot down because it

Yeah, I was a big fan of that. I even thought it was architecturally the right thing to do for carrying one MPLS service over an MPLS transport. It would have solved many of the MPLS-TP requirements.

But as John says, lots of hardware then (and probably now) sees bottom of stack and starts to sniff the next nibble. Thus, contiguous label stacks and control words were the only viable solution. It took George Swallow a while to beat this into my head.

Cheers,
Adrian

Stewart

Hi,

John

Hi Stewart,

Jeffrey

- Stewart

Hi Stewart,

Thanks.
Jeffrey

      0                   1                   2                   3

0001 means ACH

Stewart

Hi Stewart,

Thanks.
Jeffrey

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang
Sent: Thursday, February 18, 2021 10:35 PM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Stewart, all,

Thanks.
Jeffrey

-----Original Message-----
From: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 12, 2021 9:59 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

Thank you Jeffery

- Stewart

Hi,

Thanks.
Jeffrey

---

From: Haoyu Song <[email-masked]>
Date: Fri, 26 Feb 2021 00:14:49 +0000

Hi all,

Just adding a discussion point, we have proposed the concept of extension header to MPLS, so that it can provide a generic way to handle multiple service extension headers.
https://www.ietf.org/archive/id/draft-song-mpls-extension-header-02.txt

Cheers,
Haoyu

From: Int-area <[email-masked]> On Behalf Of Kireeti Kompella
Sent: Thursday, February 25, 2021 3:19 PM
To: [email-masked]; 'John E Drake' <jdrake=[email-masked]>; 'Stewart Bryant' <[email-masked]>
Cc: 'mpls' <[email-masked]>; [email-masked]; [email-masked]; Ron Bonica <[email-masked]>; Kireeti Kompella <[email-masked]>; [email-masked]; 'Jeffrey (Zhaohui) Zhang' <zzhang=[email-masked]>
Subject: Re: [Int-area] [mpls] draft-zzhang-intarea-generic-delivery-functions

Hi Adrian,

I'm all for multiple label stacks (if meaningful).  I had put that in an early version of the FAI bSPL, with a "real end stack" bit for those woke forwarding engines that needed to know.

The hard lesson I take away from those FEs that look at the nibble following the EoS is to make sure it isn't 0x4 or 0x6, not so much that a single label stack is the only viable solution.  So, keep this option alive ....

Cheers,
Kireeti.
From: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 25, 2021 at 13:53
To: 'John E Drake' <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>, 'Stewart Bryant' <[email-masked]<mailto:[email-masked]>>
Cc: 'mpls' <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, Kireeti Kompella <[email-masked]<mailto:[email-masked]>>, Ron Bonica <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, 'Jeffrey (Zhaohui) Zhang' <zzhang=[email-masked]<mailto:zzhang=[email-masked]>>
Subject: RE: [mpls] draft-zzhang-intarea-generic-delivery-functions

Cheers,
Adrian

Juniper Business Use Only
From: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, February 23, 2021 10:36 AM
To: John E Drake <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]<mailto:zzhang=[email-masked]>>; Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

Stewart

Hi,

John

Hi Stewart,

Jeffrey

- Stewart

Hi Stewart,

Thanks.
Jeffrey

      0                   1                   2                   3

0001 means ACH

Stewart

Hi Stewart,

Thanks.
Jeffrey

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang
Sent: Thursday, February 18, 2021 10:35 PM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Stewart, all,

Thanks.
Jeffrey

-----Original Message-----
From: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 12, 2021 9:59 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

Thank you Jeffery

- Stewart

Hi,

I just posted https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiItOdNuXbu_RIMekK2pkpOj4Mmj7b9MseV-Y$<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zzhang-intarea-generic-delivery-functions%2F__%3B!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiItOdNuXbu_RIMekK2pkpOj4Mmj7b9MseV-Y%24&data=04%7C01%7Chaoyu.song%40futurewei.com%7C06727c495b364b389ba808d8d9e41f1d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637498921105023464%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=o0B0lxopMtxriRyjvMxWlxe0E9%2ByVqR8AHt95770F%2FA%3D&reserved=0> .

The initial version was posted to the tsvwg (https://urldefense.com/v3/__https://tools.ietf.org/html/draft-zzhang-tsvwg-generic-transport-functions-00__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiItOdNuXbu_RIMekK2pkpOj4Mmj7b5lS_Jea$<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Fdraft-zzhang-tsvwg-generic-transport-functions-00__%3B!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiItOdNuXbu_RIMekK2pkpOj4Mmj7b5lS_Jea%24&data=04%7C01%7Chaoyu.song%40futurewei.com%7C06727c495b364b389ba808d8d9e41f1d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637498921105023464%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kHum%2F4WZBAzMIjzyb66DT6bAYC3uQjbx2cuG4FgAzF8%3D&reserved=0> ). After discussions/feedback we are re-homing it to intarea wg. This new version also contains quite some changes based on the comments and feedback that we received (special thanks to Stewart).

Thanks.
Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 26 Feb 2021 01:34:39 +0000

Hi Adrian,

  *   But as John says, lots of hardware then (and probably now) sees bottom of stack and starts to sniff the next nibble.
Can I assume you are talking about multiple label stacks next to each other?

At least in the proposed GDF use case, multiple label stacks are separated by GDF headers, who always start with 0000 nibble.
That is similar to the following:

  *   A BIER header separates the <base tunnel label + BIER label (BoS)> stack and the label stack at the beginning of BIER payload
  *   A MPLS network built on PWs that are realized by another infrastructure MPLS network
Jeffrey
From: Kireeti Kompella <kireeti=[email-masked]>
Sent: Thursday, February 25, 2021 6:19 PM
To: [email-masked]; John E Drake <[email-masked]>; 'Stewart Bryant' <[email-masked]>
Cc: 'mpls' <[email-masked]>; [email-masked]; Ron Bonica <[email-masked]>; [email-masked]; [email-masked]; Jeffrey (Zhaohui) Zhang <[email-masked]>; Kireeti Kompella <[email-masked]>
Subject: Re: [mpls] draft-zzhang-intarea-generic-delivery-functions

Hi Adrian,

Cheers,
Kireeti.

Cheers,
Adrian

Stewart

Hi,

John

Hi Stewart,

Jeffrey

- Stewart

Hi Stewart,

Thanks.
Jeffrey

      0                   1                   2                   3

0001 means ACH

Stewart

Hi Stewart,

Thanks.
Jeffrey

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang
Sent: Thursday, February 18, 2021 10:35 PM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Stewart, all,

Thanks.
Jeffrey

-----Original Message-----
From: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 12, 2021 9:59 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

Thank you Jeffery

- Stewart

Hi,

Thanks.
Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 26 Feb 2021 01:39:13 +0000

Hi Rakesh,

GDF is a generic way to implement different functions. I am not convinced by "they are completely different use-cases with different requirements".
I have a slide showing how the two and PW work seamlessly together.

Jeffrey

From: Rakesh Gandhi (rgandhi) <rgandhi=[email-masked]>
Sent: Thursday, February 25, 2021 10:03 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; John E Drake <[email-masked]>; Stewart Bryant <[email-masked]>; Rakesh Gandhi <[email-masked]>
Cc: mpls <[email-masked]>; [email-masked]; Kireeti Kompella <[email-masked]>; Ron Bonica <[email-masked]>; <[email-masked]> <[email-masked]>; [email-masked]
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

Hi Jeffrey,
I do not think we should mix IOAM and GDF. They are completely different use-cases with different requirements. Let's please not overload definitions of labels and GACH/CW header.

For each label in the received packet, there is a corresponding one-to-one CWGACH header (that contains it's length) in the packet in the right order.  E.g. for PW Label, IOAM Label or GDF Label. So there is no ambiguity. Good thing is all labels would be together in the label stack before EOS (good for label based hashing). And similarly, all CW/GACH header are together right after the EOS in the matching order.

Thanks,
Rakesh

From: mpls <[email-masked]<mailto:[email-masked]>> on behalf of Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]<mailto:zzhang=[email-masked]>>
Date: Tuesday, February 23, 2021 at 10:39 AM
To: John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>, Stewart Bryant <[email-masked]<mailto:[email-masked]>>, Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, Kireeti Kompella <[email-masked]<mailto:[email-masked]>>, Ron Bonica <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] draft-zzhang-intarea-generic-delivery-functions

Hi John,

Jeffrey

Hi,

John

Hi Stewart,

Jeffrey

- Stewart

Hi Stewart,

Thanks.
Jeffrey

      0                   1                   2                   3

0001 means ACH

Stewart

Hi Stewart,

Thanks.
Jeffrey

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang
Sent: Thursday, February 18, 2021 10:35 PM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Stewart, all,

Thanks.
Jeffrey

-----Original Message-----
From: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 12, 2021 9:59 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

Thank you Jeffery

- Stewart

Hi,

Thanks.
Jeffrey

---

From: Haoyu Song <[email-masked]>
Date: Fri, 26 Feb 2021 02:06:06 +0000

Hi all,

Cheers,
Haoyu

From: Int-area <[email-masked]<mailto:[email-masked]>> On Behalf Of Kireeti Kompella
Sent: Thursday, February 25, 2021 3:19 PM
To: [email-masked]<mailto:[email-masked]>; 'John E Drake' <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; 'Stewart Bryant' <[email-masked]<mailto:[email-masked]>>
Cc: 'mpls' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Jeffrey (Zhaohui) Zhang' <zzhang=[email-masked]<mailto:zzhang=[email-masked]>>
Subject: Re: [Int-area] [mpls] draft-zzhang-intarea-generic-delivery-functions

Hi Adrian,

Cheers,
Kireeti.

Cheers,
Adrian

Stewart

Hi,

John

Hi Stewart,

Jeffrey

- Stewart

Hi Stewart,

Thanks.
Jeffrey

      0                   1                   2                   3

0001 means ACH

Stewart

Hi Stewart,

Thanks.
Jeffrey

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang
Sent: Thursday, February 18, 2021 10:35 PM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Stewart, all,

Thanks.
Jeffrey

-----Original Message-----
From: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 12, 2021 9:59 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

Thank you Jeffery

- Stewart

Hi,

Thanks.
Jeffrey

---

From: Haoyu Song <[email-masked]>
Date: Fri, 26 Feb 2021 02:08:29 +0000

Hi all,

Cheers,
Haoyu

Hi Adrian,

Cheers,
Kireeti.

Cheers,
Adrian