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

[Loa Andersson <[e-mail]>]

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]