Re: [mpls] Poll 2: New SPL vs re-purposed ELI for carrying Network Action Indicators

Hi Robert,
thank you for your response. Please find my follow-up notes inlined below
under the GIM>> tag.

Regards,
Greg

On Fri, Jun 17, 2022 at 11:41 AM Robert Raszuk <rraszuk@gmail.com> wrote:

> Hi Greg,
>
> RFC9197 is clear what protocols can be used to realize it.
>
> Quote:
>
>    Data-Fields can be encapsulated into a variety of protocols, such as
>    Network Service Header (NSH), Segment Routing, Generic Network
>    Virtualization Encapsulation (Geneve), or IPv6.
>
> I do not see any L2.5 protocol suitable to be used for IOAM extension.
>
GIM>> Do you consider this list to be exhaustive? Personally, I interpret
"such as" as an indication of non-exhaustive, exemplary listing. Also,
should I understand your statement "I do not see any L2.5
protocol suitable to be used for IOAM extension" as the declaration of
non-support of the application of IOAM in, for example, MPLS networks?

>
> So the way I would see this applicable to the topic is via local punt
> indication and IOAM data would sit in packet payload (PSD) not within the
> label stack.
>
GIM>> I am not sure that PSD can be used in the scope
of draft-decraene-mpls-slid-encoded-entropy-label-id. I think I need Bruno
to help me here. I'll ask him in the other discussion thread.

>
> Slice_ID would be programmed among other things to execute IOAM on a
> packet.
>
GIM>> Would kindly elaborate on how you envision such a mechanism?

>
> Many thx,
> Robert
>
>
>
> On Fri, 17 Jun 2022 at 18:28, Greg Mirsky <gregimirsky@gmail.com> wrote:
>
>> Hi Robert,
>> could you please clarify why you believe that ioam "is just control plane
>> on how to handle a slice"? Do you believe that support of RFC 9197
>> <https://datatracker.ietf.org/doc/rfc9197/> does not command any change
>> in a respective data plane and can be achieved with a common extension(s)
>> in the control plane? Also, could you kindly explain how IOAM Trace Data
>> could be collected?
>>
>> Regards,
>> Greg
>>
>> On Fri, Jun 17, 2022 at 8:47 AM Robert Raszuk <rraszuk@gmail.com> wrote:
>>
>>> HI,
>>>
>>>
>>>> * * entropy*
>>>> * * slice id*
>>>>       * nffrr
>>>>       * ioam
>>>>       * detnet
>>>>       * sfc
>>>>       * np
>>>>       * aan
>>>>
>>>> I count 8.
>>>>
>>>
>>> I count 2.
>>>
>>> entropy as is and slice_id
>>>
>>> Rest is just control plane on how to handle a slice. Exactly as
>>> described in my RAF proposal.
>>>
>>>
>>>> Zero room for growth.
>>>>
>>>
>>> Infinite room for grow.
>>>
>>> Our job is to think farther ahead.
>>>>
>>>
>>> Our job is to also think holistically on what we are transporting. And
>>> that is real user's data - not SP's instructions.
>>>
>>> Many thx,
>>> R.
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>