Re: [mpls] Notes from Open DT meeting 2022-04-07.

Hi Haoyu,
I think that there might be an operational value in controlling IOAM
capability per a flow. If that is the case, then we can discuss using the
Reserved field in IOAM-in-MPLS shim proposed in draft-gandhi-mpls-ioam-sr
<https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-ioam-sr-02>.

Regards,
Greg

On Thu, Apr 7, 2022 at 1:17 PM Haoyu Song <haoyu.song@futurewei.com> wrote:

> Hi Greg,
>
>
>
> I’m curious where is the concept of IOAM session specified?
>
> My understanding is that IOAM run statelessly. A capable node, unless it’s
> configured to not process IOAM, should process it if it finds the IOAM
> header in a packet. The head node determines on which packets the IOAM
> header is added.
>
>
>
> Regards,
>
> Haoyu
>
>
>
> *From:* mpls <mpls-bounces@ietf.org> *On Behalf Of * Greg Mirsky
> *Sent:* Thursday, April 7, 2022 12:39 PM
> *To:* Robert Raszuk <rraszuk@gmail.com>
> *Cc:* mpls@ietf.org
> *Subject:* Re: [mpls] Notes from Open DT meeting 2022-04-07.
>
>
>
> Hi Robert,
>
> I believe that the IOAM session identifier will be present in IOAM-in-MPLS
> shim, whether as ISD or PSD.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, Apr 7, 2022 at 12:35 PM Robert Raszuk <rraszuk@gmail.com> wrote:
>
> Hi Greg,
>
>
>
> Well In-Situ OAM was just an example of an action.
>
>
>
> But your answer actually brings a very interesting yet orthogonal to the
> original question a new consideration :)
>
>
>
> How said IOAM identifiers (many as there can be millions of flows) is
> connected with ISD (or PSD) encoded action ?
>
>
>
> Thx a lot,
> R.
>
>
>
>
>
>
>
>
>
> On Thu, 7 Apr 2022 at 21:29, Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Hi Robert,
>
> I' try to answer the IOAM-related question.
>
> An IOAM monitoring session is expected to have a unique identifier. That
> identifier can be provisioned to P nodes that are required to produce
> op-path telemetry information for the monitored flow.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, Apr 7, 2022 at 12:14 PM Robert Raszuk <rraszuk@gmail.com> wrote:
>
> Dear WG,
>
>
>
> I would like to state that I agree with comments made by Jie & Haoyu that
> the presented solution is a rather significant departure from main MPLS
> architecture and requires new data plane changes to fetch and process ISDs
> and PSDs (even if still MPLS based).
>
>
>
> However I have a bit more fundamental question to this proposal.
>
>
>
> I can see that it could be made to work with LDP or RSVP based LSPs.
>
>
>
> But it is very unclear to me how the proposed solution would work with
> concept of domain wide MPLS labels. Especially considering requirement that
> not all LSR nodes need to execute given function on a specific packets.
>
>
>
> Is support of MNA compatible work with SR-MPLS considering as example case
> where there is no transit segment endpoints, but just ingress and egress
> LSRs. Let's take basic execution of in-situ OAM (postcard mode) on just few
> specific P routers. For simplicity let's assume that MNA and that function
> is supported on all P routers in the domian.
>
>
>
> How would P nodes inspecting the arriving packets know that the encoded
> action is for them to execute ?
>
>
>
> Kind regards,
>
> Robert
>
>
>
>
>
>
>
> On Thu, 7 Apr 2022 at 18:40, Loa Andersson <loa@pi.nu> wrote:
>
> Folks,
>
> I have placed my notes fron the meeting in the agenda for the meeting,
> so it will be found following the link below.
>
> On 2022-04-05 00:36, Loa Andersson wrote:
> >
> > Open DT,
> >
> > I have placed the proposed agenda for the meeting on Thursday at:
> >
> > https://trac.ietf.org/trac/mpls/wiki/2022-04-07-agenda
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fmpls%2Fwiki%2F2022-04-07-agenda&data=04%7C01%7Chaoyu.song%40futurewei.com%7C6bb3483203a44e8b1e0108da18ce6338%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637849571968049992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TidgS84HmJvxdfDcYar5pq0jGb7fT4sHPU8cYeDEi0s%3D&reserved=0>
>
> /Loa
>
> >
> > /Loa
> >
> > PS
> >
> > I had an AP to see if we should change the time for the meeting due to
> > the change to DST in the US and Europe. For this meeting I have not been
> > able to do the poll. Will do for the meeting next week. So it stays at
> > 11pm Beijing time.
> >
> >
> >
> >
>
> --
> Loa Andersson                        email: loa@pi.nu
> Senior MPLS Expert                          loa.pi.nu@gmail.com
> Bronze Dragon Consulting             phone: +46 739 81 21 64
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%40futurewei.com%7C6bb3483203a44e8b1e0108da18ce6338%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637849571968049992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5yaBcNaHwAe1nmwSClOxjmkaxlpaovr48%2Fm0i4UegYY%3D&reserved=0>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%40futurewei.com%7C6bb3483203a44e8b1e0108da18ce6338%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637849571968049992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5yaBcNaHwAe1nmwSClOxjmkaxlpaovr48%2Fm0i4UegYY%3D&reserved=0>
>
>