[mpls] Re: Poll: IOAM and PSD

[Loa Andersson <[e-mail]>]

Joel,

To me it seem like we are in a typical "send text" situation.

/Loa

Den 04/08/2024 kl. 17:19, skrev Joel Halpern:
> 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]
>>>>
>>

-- 
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
[e-mail]
[e-mail]