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 protected]> 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 > > > Juniper Business Use Only > From: mpls <[email protected] <mailto:[email protected]>> On Behalf > Of Jeffrey (Zhaohui) Zhang > Sent: Tuesday, February 23, 2021 10:19 AM > To: Stewart Bryant <[email protected] > <mailto:[email protected]>>; Rakesh Gandhi <[email protected] > <mailto:[email protected]>> > Cc: mpls <[email protected] <mailto:[email protected]>>; [email protected] > <mailto:[email protected]>; Kireeti Kompella <[email protected] > <mailto:[email protected]>>; Ron Bonica <[email protected] > <mailto:[email protected]>>; <[email protected] <mailto:[email protected]>> > <[email protected] <mailto:[email protected]>>; [email protected] > <mailto:[email protected]> > Subject: Re: [mpls] draft-zzhang-intarea-generic-delivery-functions > > [External Email. Be cautious of content] > > 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 > 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 1|Version| Reserved | Channel Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | | > ~ 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 > > From: Stewart Bryant <[email protected] > <mailto:[email protected]>> > Sent: Monday, February 22, 2021 7:30 PM > To: Jeffrey (Zhaohui) Zhang <[email protected] <mailto:[email protected]>> > Cc: Stewart Bryant <[email protected] > <mailto:[email protected]>>; [email protected] > <mailto:[email protected]>; mpls <[email protected] <mailto:[email protected]>>; > [email protected] <mailto:[email protected]>; Kireeti Kompella <[email protected] > <mailto:[email protected]>>; Ron Bonica <[email protected] > <mailto:[email protected]>>; <[email protected] <mailto:[email protected]>> > <[email protected] <mailto:[email protected]>> > Subject: Re: draft-zzhang-intarea-generic-delivery-functions > > [External Email. Be cautious of content] > > 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 protected] > <mailto:[email protected]>> 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 protected] > <mailto:[email protected]>> > Sent: Monday, February 22, 2021 5:15 AM > To: Jeffrey (Zhaohui) Zhang <[email protected] <mailto:[email protected]>> > Cc: Stewart Bryant <[email protected] > <mailto:[email protected]>>; [email protected] > <mailto:[email protected]>; mpls <[email protected] <mailto:[email protected]>>; > [email protected] <mailto:[email protected]>; Kireeti Kompella <[email protected] > <mailto:[email protected]>>; Ron Bonica <[email protected] > <mailto:[email protected]>>; <[email protected] <mailto:[email protected]>> > <[email protected] <mailto:[email protected]>> > Subject: Re: draft-zzhang-intarea-generic-delivery-functions > > [External Email. Be cautious of content] > > 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 protected] > <mailto:[email protected]>> 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 protected] > <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]>; mpls <[email protected] > <mailto:[email protected]>>; [email protected] <mailto:[email protected]>; Kireeti > Kompella <[email protected] <mailto:[email protected]>>; Ron Bonica > <[email protected] <mailto:[email protected]>>; <[email protected] > <mailto:[email protected]>> <[email protected] <mailto:[email protected]>> > 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 protected] > <mailto:[email protected]>> > Sent: Tuesday, January 12, 2021 9:59 AM > To: Jeffrey (Zhaohui) Zhang <[email protected] <mailto:[email protected]>> > Cc: Stewart Bryant <[email protected] > <mailto:[email protected]>>; [email protected] > <mailto:[email protected]>; mpls <[email protected] <mailto:[email protected]>>; > [email protected] <mailto:[email protected]>; Kireeti Kompella <[email protected] > <mailto:[email protected]>>; Ron Bonica <[email protected] > <mailto:[email protected]>>; <[email protected] <mailto:[email protected]>> > <[email protected] <mailto:[email protected]>> > 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 protected] > <mailto:[email protected]>> 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$ > > <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). > > Comments and suggestions are appreciated. > > Thanks. > Jeffrey > > Juniper Business Use Only > > > Juniper Business Use Only > > > > Juniper Business Use Only > > > > Juniper Business Use Only > > > Juniper Business Use Only >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
