[mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr

["Jaganbabu Rajamanickam (jrajaman)" <[e-mail]>]

Hello Loa,

    This is not a proposal to change our MNA header solution.

    The example which I gave is that how an application could allocate their opcode and manage their multiple sub-action grouping. These kind of semantics has to be defined by that specific application when they allocate their opcode and define their semantics which is not in the scope of the MNA header solution document.

     Where they want to encode their sub-actions and Ancillary Data then the application decides where to encode their sub-actions and the common Ancillary Data.

Thanx,
Jags


From: Loa Andersson <[e-mail]>
Date: Thursday, June 6, 2024 at 4:10 AM
To: Jaganbabu Rajamanickam (jrajaman) <[e-mail]>, Joel Halpern <[e-mail]>, [e-mail] <[e-mail]>, Tianran Zhou <[e-mail]>
Cc: [e-mail] <[e-mail]>, MPLS Working Chairs <[e-mail]>, [e-mail] <[e-mail]>, Zhukeyi(Kaiyin, Datacom Standard&Patent) <[e-mail]>
Subject: Re: [mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr
Jags,

Interesting, never thought about this. However, considering the ongoing
WGLC, this is a rather big change. Would you want to include it in
"draft-ietf-mpls-mna-hdr" or a separate draft?

/Loa

Den 2024-06-06 kl. 03:26, skrev Jaganbabu Rajamanickam (jrajaman):
>
> Option-1:
>
> A Single opcode could define their own internal sub-actions as part of
> their AD and operate on it.
>
> Example: Opcode=10 with AD length as 20 bits
>
> The 20 bits AD could be split in to 4 bits sub-actions and 16 bits of AD
>
> In this case, we could group four sub-actions and could enable and
> disable individually.
>
> An application could have multiple network actions, but it might not
> want to execute all of them. In this case, there is no need to
> allocate multiple opcodes; a single application opcode could be
> allocated, and multiple network actions could be encoded as
> sub-actions within the AD.
>
> For example, if the application allocates the opcode value 10, it
> could have multiple network actions "A", "B", "C", and "D", which may
> rely on the same Ancillary Data.
>
> By setting the bits A, B, C, D it could specify the grouping on
> network actions.
>
> Thanx,
>
> Jags
>
> *From: *Tianran Zhou <zhoutianran=[e-mail]>
> *Date: *Wednesday, June 5, 2024 at 9:04 PM
> *To: *Jaganbabu Rajamanickam (jrajaman) <[e-mail]>, Joel
> Halpern <[e-mail]>, [e-mail] <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>, MPLS Working Chairs
> <[e-mail]>, [e-mail]
> <[e-mail]>, Zhukeyi(Kaiyin, Datacom
> Standard&Patent) <[e-mail]>
> *Subject: *RE: [mpls] Re: Working Group Last Call on
> draft-ietf-mpls-mna-hdr
>
> Looking at existing opcode proposals.
>
> Each opcode is defined by specific atom function.
>
> If there is no such grouping, both option 1 and 2  need a lot of
> opcode to enumerate all the combinations.
>
> Tianran
>
> *From:*Jaganbabu Rajamanickam (jrajaman)
> [mailto:jrajaman=[e-mail]]
> *Sent:* Thursday, June 6, 2024 8:48 AM
> *To:* Tianran Zhou <[e-mail]>; Joel Halpern
> <[e-mail]>; [e-mail]
> *Cc:* [e-mail]; MPLS Working Chairs <[e-mail]>;
> [e-mail]; Zhukeyi(Kaiyin,Datacom
> Standard&Patent) <[e-mail]>
> *Subject:* Re: [mpls] Re: Working Group Last Call on
> draft-ietf-mpls-mna-hdr
>
> I think these grouping should be part of a specific application and
> not part of generic MNA header solution.
>
> The functionality of the new grouping format mentioned  below could be
> achieved by the option-1 which I have provided in this email using the
> current MNA header solution draft.
>
> Also the application that needs grouping should use their own
> semantics to define whatever they need to achieve.
>
> I couldn’t see any real application use case that may require a new
> grouping format.
>
> If you have something in your mind please help us to understand.
>
> Thanx,
>
> Jags
>
> *From: *Tianran Zhou <zhoutianran=[e-mail]>
> *Date: *Wednesday, June 5, 2024 at 8:25 PM
> *To: *Jaganbabu Rajamanickam (jrajaman) <[e-mail]>, Joel
> Halpern <[e-mail]>, [e-mail] <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>, MPLS Working Chairs
> <[e-mail]>, [e-mail]
> <[e-mail]>, Zhukeyi(Kaiyin, Datacom
> Standard&Patent) <[e-mail]>
> *Subject: *RE: [mpls] Re: Working Group Last Call on
> draft-ietf-mpls-mna-hdr
>
> I think the new format only need a simple extension to existing mna
> hdr mechanism.
>
> I can give a reference design for this type C’. It’s just like format C.
>
> GL(group length) indicates the number of LSEs in this group.
>
> If the data is short, I can only use this type C’, as A+B+C’.
>
> It also support A+B+C’+D.
>
> It’s completely  compatible with type C.
>
> Tianran
>
> *From:*Jaganbabu Rajamanickam (jrajaman)
> [mailto:jrajaman=[e-mail]
> <mailto:jrajaman=[e-mail]>]
> *Sent:* Wednesday, June 5, 2024 9:03 PM
> *To:* Joel Halpern <[e-mail]>; Tianran Zhou
> <[e-mail]>; [e-mail]
> *Cc:* [e-mail]; MPLS Working Chairs <[e-mail]>;
> [e-mail]; Zhukeyi(Kaiyin,Datacom
> Standard&Patent) <[e-mail]>
> *Subject:* Re: [mpls] Re: Working Group Last Call on
> draft-ietf-mpls-mna-hdr
>
> I agree with Tony and Joel,
>
> IMO, the grouping may not be required, that could be achieved by the
> existing MNA hdr solution.
>
> Option-1:
>
> A Single opcode could define their own internal sub-actions as part of
> their AD and operate on it.
>
> Example: Opcode=10 with AD length as 20 bits
>
> The 20 bits AD could be split in to 4 bits sub-actions and 16 bits of AD
>
> In this case, we could group four sub-actions and could enable and
> disable individually.
>
> Option-2:
>
> In the worst case a single opcodes could define multiple actions and
> include a single AD.
>
> Example: Opcode=10, Opcode=11
>
> Could define a new opcode 12, that may execute the network action of
> 10 and 11 with the same AD
>
> The grouping is going be more complex operations in the forwarding and
> the same behaviour could be achieved by the above.
>
> Thanx,
>
> Jags
>
> *From: *Joel Halpern <[e-mail]>
> *Date: *Wednesday, June 5, 2024 at 8:39 AM
> *To: *Tianran Zhou <zhoutianran=[e-mail]>,
> [e-mail] <je_drake=[e-mail]>
> *Cc: *[e-mail] <[e-mail]>, MPLS Working Chairs
> <[e-mail]>, [e-mail]
> <[e-mail]>, Zhukeyi(Kaiyin,Datacom
> Standard&Patent) <[e-mail]>
> *Subject: *Re: [mpls] Re: Working Group Last Call on
> draft-ietf-mpls-mna-hdr
>
> I can not tell from the descriptions you have posted what change would
> be applied to the hdr draft.  Just saying "Some type C information can
> apply to following type C entries" seems so vague that I do not see
> how an implementor can use that information.  I can see how a specific
> solution could specify an opcode C1 and a furhter opcode C2 and could
> say C2 must follow C1 and uses the information from C1. But that does
> not need any change to the hdr draft.
>
> Yours,
>
> Joel
>
> On 6/5/2024 8:28 AM, Tianran Zhou wrote:
>
>     I do not really understand your question. Could you please give me
>     more information?
>
>     Let me try to answer. Type c can have data. What l want to do is
>     to reduce the redundant information when there are more than one
>     actions.
>
>     Tianran
>
>     ------------------------------------------------------------------------
>
>
>     Sent from WeLink
>
>     *发**件人：***[e-mail]<je_drake=[e-mail]>
>
>     *收件人：***Tianran Zhou<[e-mail]>
>
>     *抄送：***John Drake<[e-mail]>;Tarek
>     Saad<[e-mail]>;[e-mail];MPLS Working
>     Chairs<[e-mail]>;[e-mail];Zhukeyi(Kaiyin,Datacom
>     Standard&Patent)<[e-mail]>
>
>     *主**题**：***Re: [mpls] Re: Working Group Last Call on
>     draft-ietf-mpls-mna-hdr
>
>     *时间**：***2024-06-05 00:30:48
>
>     You didn’t answer my question
>
>     Sent from my iPhone
>
>         On Jun 4, 2024, at 12:08 PM, Tianran Zhou
>         <zhoutianran=[e-mail]>
>         <mailto:zhoutianran=[e-mail]> wrote:
>
>         
>
>         Hi John,
>
>         One packet may need multiple actions/opcodes.
>         The group format will indicate several actions can share the
>         same metadata.
>
>         Tianran
>
>         ------------------------------------------------------------------------
>
>
>         Sent from WeLink
>
>         *发**件人：***John Drake<je_drake=[e-mail]>
>
>         *收件人：***Tarek Saad<[e-mail]>;[e-mail];Tianran
>         Zhou<[e-mail]>
>
>         *抄送：***MPLS Working
>         Chairs<[e-mail]>;[e-mail];Zhukeyi(Kaiyin,Datacom
>         Standard&Patent)<[e-mail]>
>
>         *主**题**：***Re: [mpls] Re: Working Group Last Call on
>         draft-ietf-mpls-mna-hdr
>
>         *时间**：***2024-06-04 21:36:51
>
>         So, for what are the post opcode bits in each of the
>         subsequent format C LSEs used?
>
>         On Monday, June 3, 2024 at 08:40:12 PM PDT, Tianran Zhou
>         <zhoutianran=[e-mail]>
>         <mailto:zhoutianran=[e-mail]> wrote:
>
>         Hi WG and Authors,
>
>         This draft proposed the 4 LSE formats with sequence: A-B-C-D.
>
>         I want to propose a new LSE format. Let’s call it C’ temporarily.
>
>         C’ is a kind of group, which can group several C formats.
>
>         So the sequence is A-B-C’-C-D.
>
>         This format can reduce the redundancy of several LSEs.
>
>         For example, if several LSEs have the same flow id, we can
>         just put this flow id at the beginning of the group. And all
>         the following LSEs in this group can use.
>
>         Best,
>
>         Tianran
>
>         *From:*Tarek Saad [mailto:[e-mail]
>         <mailto:[e-mail]>]
>         *Sent:* Tuesday, June 4, 2024 10:50 AM
>         *To:* [e-mail]
>         *Cc:* MPLS Working Chairs <[e-mail]>
>         <mailto:[e-mail]>; [e-mail]
>         *Subject:* [mpls] Working Group Last Call on
>         draft-ietf-mpls-mna-hdr
>
>         Dear WG,
>
>         This email starts a two-week Working Group last call for
>         draft-ietf-mpls-mna-hdr
>         <https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-hdr/>.
>
>         Please indicate your support or concern for this draft. If you
>         are opposed to the progression of the draft to RFC, please
>         articulate your concern. If you support it, please indicate
>         that you have read the latest version, and it is ready for
>         publication in your opinion. As always, review comments and
>         nits are most welcome.
>
>         Please send your comments to the mpls WG mailing list
>         ([e-mail])
>
>         If necessary, comments may be sent unidirectional to the WG
>         chairs.
>
>         Note, currently there are 5 IPR disclosures against this
>         document at
>         https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mpls-mna-hdr
>         <https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mpls-mna-hdr>
>
>         This poll runs until June 18, 2024.
>
>         Thank you,
>
>         Tarek (for the MPLS WG co-chairs)
>
>         _______________________________________________
>         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 [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]