[mpls] Re: Poll: IOAM and PSD

[Greg Mirsky <[e-mail]>]

Hi Rakesh,
thank you for referencing individual drafts under discussion in IPPM WG.
Although there are different views about these proposals in IPPM WG, I
don't think that the decision of MPLSWG must be based on not yet adopted
work (if I remember correctly, the MPLS WG used the same test when
considering cases that benefit from MNA (draft-ietf-mpls-mna-usecases
<https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-usecases/>).

Regards,
Greg

On Sun, Aug 11, 2024 at 8:36 AM Rakesh Gandhi <[e-mail]>
wrote:

> Hi Greg,
>
> Sorry for top posting, I am replying to the following comment:
>
> Regarding:
> GIM>> Could you please point me where the use of Timestamp in RFC 9326
> IOAM-DEX is required or even discussed as optional?
>
> <RG>
>
> As IOAM DEX option-type is extensible using the Extension-Flags defined in
> RFC 9326, there are new drafts proposed in the IPPM WG to take advantage of
> it, i.e. to add additional metadata and telemetry information in
> direct-export option.
>
>
>
> https://datatracker.ietf.org/doc/html/rfc9326
>
>     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
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    |        Namespace-ID           |     Flags     |*Extension-Flags*|
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    |               IOAM-Trace-Type                 |   Reserved    |
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    |                         Flow ID (Optional)                    |
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    |                     Sequence Number  (Optional)               |
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>    1. *Adding Measurement period number information for alternate
>    marking:*
>
>
>    -
>    https://datatracker.ietf.org/doc/draft-he-ippm-integrating-am-into-ioam/
>
>
>
>         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
>
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>        |        Namespace-ID           |     Flags     |*Extension-Flags*|
>
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>        |               IOAM-Trace-Type                 |D|L| Reserved  |
>
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>        |                         Flow ID (Optional)                    |
>
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>        |                     Sequence Number  (Optional)               |
>
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> *       |             Measurement Period Number  (Optional)             |*
>
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>                Figure 1: The Extended DEX Option-Type Format
>
>
>
>    - IANA has created the "IOAM DEX Extension-Flags" registry. This
>    registry includes 8 flag bits. Bit 0 (the most significant bit) and bit 1
>    in the registry are allocated by [RFC9326]. IANA is requested to allocate
>    bit 2 as Measurement Period Number in the registry and described in Section
>    5.
>
>
>
> *(2): Adding timestamp information:*
>
>    -
>    https://www.ietf.org/archive/id/draft-ahuang-ippm-dex-timestamp-ext-00.txt
>
>
>
>      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
>
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>      |        Namespace-ID           |     Flags     |*Extension-Flags*|
>
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>      |               IOAM-Trace-Type                 |   Reserved    |
>
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>      |                         Flow ID (Optional)                    |
>
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>      |                     Sequence Number  (Optional)               |
>
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> *     |                   Timestamp Seconds  (Optional)               |*
>
> *     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*
>
> *     |                  Timestamp Fraction  (Optional)               |*
>
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>        Figure 1: IOAM DEX Option-Type Format including the timestamps
>
>
>
>
>
> Thanks,
>
> Rakesh
>
>
>
>
> On Mon, Aug 5, 2024 at 6:43 PM Greg Mirsky <[e-mail]> wrote:
>
>> Hi Rakesh,
>> I have a number of questions based on you responses and would greatly
>> appreciate your helping me to better understand. I'll top-post below and
>> tag my questions with GIM>>:
>>
>>    - Based on my understanding, two IOAM option-types, namely,
>>    Pre-allocated Trace (value 0) and Direct-Export (value 4) are popular.
>>
>> GIM>> What is the measure of "popular"? HW implementations?
>>
>>    - Data fields such as 32-bit Sequence Number or 32-bit Timestamp in
>>    In-Stack LSE can lead to undesired ECMP behavior on nodes that use labels
>>    for ECMP hashing
>>
>> *GIM>> Could you please point me where the use of Timestamp in RFC 9326
>> IOAM-DEX is required or even discussed as optional?*
>>
>> Regards,
>> Greg
>>
>> On Mon, Aug 5, 2024 at 3:32 PM Rakesh Gandhi <[e-mail]>
>> wrote:
>>
>>> Hi Tony,
>>>
>>>
>>>
>>> Although not directly related to the question in the poll but since PSD
>>> is mentioned in the title of this email for poll, like to highlight the
>>> certain advantages of adding IOAM data fields in Post-Stack Network Action
>>> for both post-card based and passport-based methods.
>>>
>>>
>>>
>>>    1. IOAM E2E/POT/TRACE/DEX option-types contain various data fields
>>>    as defined in RFC 9197 and RFC 9326
>>>    <https://datatracker.ietf.org/doc/html/rfc9326>.
>>>    2. Data fields such as 32-bit Sequence Number or 32-bit Timestamp in
>>>    In-Stack LSE can lead to undesired ECMP behavior on nodes that use labels
>>>    for ECMP hashing
>>>       - Data fields in Post-Stack are not included in ECMP hashing
>>>    3. 32-bit data fields do not fit into 30-bit data in In-Stack LSE,
>>>    limited to 11-bit as variable or mutable data
>>>    - RFC standard IOAM format data fields fit well into 32-bit
>>>       Post-Stack Network Action Data
>>>       4. IOAM option types support extensibility to optionally add many
>>>    data fields
>>>       - Node can easily skip In-Stack network action and process the
>>>       next one even when Data in Post-Stack is outside RLD
>>>    5. IOAM-DEX data fields can be seen as metadata in the received
>>>    packets that data plane exports
>>>       - Metadata could easily be in Post-Stack
>>>
>>>
>>> P.S. The IOAM network action and offset for the data fields for both
>>> IOAM methods would be in-stack. The above points are for the data fields.
>>>
>>>
>>> Thanks,
>>>
>>> Rakesh
>>>
>>>
>>>
>>> On Tue, Jul 30, 2024 at 11:27 AM Tony Li <[e-mail]> wrote:
>>>
>>>> [WG chair hat: on]
>>>>
>>>>
>>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> We’ve had many discussions about IOAM and PSD over the last few years.
>>>> We need to reach consensus on the problems that need to be addressed in
>>>> these areas. Therefore, we would like to hear from everyone, especially
>>>> independent operators:
>>>>
>>>>
>>>>
>>>>    1.
>>>>
>>>>    There are many flavors of IOAM.  Which ones would you like to
>>>>    deploy/implement with MNA?
>>>>    2.
>>>>
>>>>    Do you have other applications of MNA that have not been proposed
>>>>    yet?
>>>>
>>>>
>>>>
>>>>  This poll will close in two weeks, at 9am PDT, Aug 13.
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> MPLS chairs
>>>>
>>>> _______________________________________________
>>>> mpls mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>> _______________________________________________
>>> mpls mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>