[mpls] Re: Poll: IOAM and PSD

["[e-mail]" <[e-mail]>]

Joel’s right.  This might  be termed an ‘IQ Test’ that we failed

Sent from my iPhone

> On Aug 4, 2024, at 11:21 AM, Joel Halpern <[e-mail]> wrote:
> 
> 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]
>>>> 
>> 
> 
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]