[mpls] Re: Poll: IOAM and PSD

[Joel Halpern <[e-mail]>]

It seems to me that using the same terminology for two very different 
aspects is inviting confusion.

Yours,

Joel

On 8/4/2024 3:13 AM, Loa Andersson wrote:
> Joel,
>
>
> Den 04/08/2024 kl. 06:02, skrev Joel Halpern:
>> I wondeer if we can find some better terminology. 
> I have no opposition to "better terminology", only that I think what 
> we have will serve unless there are proposals for improvements.
>
> As always when I try to write definitions in English, please remember 
> that English is not my mother tongue, try to understand what I mean 
> and help me to improve.
>
> What we currently have I think was proposed Stewart and says that 
> information is considered "mutable" if that information in a flow is 
> changes per packet or is changed by one nodes forwarding packets 
> belonging to the flow.
>
> I still think that is good enough, but would welcome improvements.
>
>> You are correct that the sequence number on packets is not the same 
>> in successive packets in a flow.  So, depending upon how you use the 
>> term "mutable" it is mutable between packets in a flow.  It is not 
>> changed (mutatated) by the devices that process it.  We have other 
>> use cases where we use "mutable" to mean that.   Can we disentangle 
>> them?
>
> Maybe something like this (though I guess we should give some context):
>
> - there are two types of mutable information in MPLS IOAM packets
>
>   -- packets where the ingress LER put in for example a sequence 
> number that is
>      increased per packet.
>   -- packets carrying information that one or more node in the 
> (non-deterministically)
>      changes prior to forwarding the packet
>
> Caveat: modulo grammar
>
> And, yes I think this is what Stewart said from the start.
>
> /Loa
>> Thanks,
>>
>> Joel
>>
>> On 8/3/2024 11:44 PM, Loa Andersson wrote:
>>> Greg,
>>>
>>> I think Michael is right.
>>>
>>> DEX is useful and we need it, but it does not solve all and any 
>>> problem.
>>>
>>> I thought DEX was about transporting data/info generated by a node, 
>>> and outgoing packet. This data is by defiintion immutable and is for 
>>> example never hashed for load sharing purposes
>>>
>>> The issue with mutable data, e.g. the sequence number, is that it is 
>>> in an incoming packet and mutable. If the network is doing ECMP by 
>>> scanning the label stack, then the sequence number can't in the 
>>> first 20 bits of an LSE.
>>>
>>> Right?
>>>
>>> /Loa
>>>
>>> Den 04/08/2024 kl. 22:58, skrev Greg Mirsky:
>>>> Hi Michael,
>>>> I don't think that "IOAM requires mutable data" is an accurate 
>>>> statement. RFC 9326 IOAM Direct Export 
>>>> <https://datatracker.ietf.org/doc/rfc9326/> indeed defines optional 
>>>> parameters, Flow ID and Sequence Number, to ease the correlation 
>>>> process of collected telemetry data. For some applications, e.g., 
>>>> DetNet over MPLS <https://datatracker.ietf.org/doc/rfc8964/>, both 
>>>> these parameters already are present as part of the DetNet MPLS 
>>>> encapsulation as S-label (Service) and Sequence Number in d-CW or 
>>>> d-ACH, respectively. Furthermore, the IPPM WG draft on collecting 
>>>> telemetry data 
>>>> <https://datatracker.ietf.org/doc/draft-ietf-ippm-hybrid-two-step/> can 
>>>> be used without the use of the optional IOAM-DEX fields, i.e., 
>>>> Flow-ID and Sequence Number.
>>>>
>>>> Regards,
>>>> Greg
>>>>
>>>> On Sat, Aug 3, 2024 at 6:43 AM Michael Menth 
>>>> <[e-mail]> wrote:
>>>>
>>>>     Hi all,
>>>>
>>>>     we're not operators but researchers who implemented some IOAM
>>>>     flavors in combination with SR using P4 on Tofino. We've presented
>>>>     some results at an interim meeting before:
>>>> https://datatracker.ietf.org/meeting/interim-2024-mpls-01/session/mpls
>>>>
>>>>     IOAM requires mutable data. In combination with multiple labels,
>>>>     e.g., for SR, these mutable data need to be near the bottom of the
>>>>     stack, otherwise they get popped along the way. Moving them to PSD
>>>>     makes encoding more efficient without increasing the effective
>>>>     header length that needs to be parsed. Therefore, we think PSD is
>>>>     the better option for applications like IOAM.
>>>>
>>>>     Regards
>>>>
>>>>     Michael
>>>>
>>>>     Am 30.07.2024 um 17:25 schrieb Tony Li:
>>>>>
>>>>>     [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 [e-mail]
>>>>
>>>>     --     Prof. Dr. habil. Michael Menth
>>>>     University of Tuebingen
>>>>     Faculty of Science
>>>>     Department of Computer Science
>>>>     Chair of Communication Networks
>>>>     Sand 13, 72076 Tuebingen, Germany
>>>>     phone: [phone]
>>>>     mailto:[e-mail] <mailto:[e-mail]>
>>>>     http://kn.cs.uni-tuebingen.de
>>>>
>>>>     _______________________________________________
>>>>     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]
>>>
>