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

[Stewart Bryant <[e-mail]>]

> On 23 Feb 2021, at 15:18, Jeffrey (Zhaohui) Zhang <[e-mail]> wrote:
> 
> 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.

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


>  
> Jeffrey