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 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Associated Channel Header
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 protected]>
Sent: Thursday, February 18, 2021 6:49 PM
To: Stewart Bryant <[email protected]>
Cc: Jeffrey (Zhaohui) Zhang <[email protected]>; mpls <[email protected]>;
[email protected]; Kireeti Kompella <[email protected]>; Ron Bonica
<[email protected]>; <[email protected]> <[email protected]>; [email protected]
Subject: Re: [mpls] draft-zzhang-intarea-generic-delivery-functions
[External Email. Be cautious of content]
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 protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>> 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).
>
> Comments and suggestions are appreciated.
>
> Thanks.
> Jeffrey
>
> Juniper Business Use Only
_______________________________________________
mpls mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!VXglGy7lcO2Pe-wXQDgZaYzzz0Ckq57ZSdkkJ0Sz5yTrNvCrxSb9ClooNd2pzrpq$>
Juniper Business Use Only
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
