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]>
Sent: Monday, February 22, 2021 7:30 PM
To: Jeffrey (Zhaohui) Zhang <[email protected]>
Cc: Stewart Bryant <[email protected]>; [email protected]; mpls
<[email protected]>; [email protected]; Kireeti Kompella <[email protected]>; Ron
Bonica <[email protected]>; <[email protected]> <[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
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
