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

[Joel Halpern <[e-mail]>]

It seems Jie that you have a clear model in your head as to how this 
grouping will work and why / when it will save bytes.  While I can make 
guesses, none of them seem to work since a generic grouping seems to 
still require that we specify exactly which opcodes reuse which information.

Separately, there are multiple solutions that can achieve the same 
savings without needing to define a generic container.  As one example, 
suppose we have opcodes C1, C2, and C3 which frequently occur together 
and which all require long ancillary data with the same semantics.  We 
could define in the same draft an opcode C4 with the same semantics as 
C1, and the additional behavior that it retains its data for reuse.  We 
could then define opcodes C5 and C6 with the same semantics as C2 and C3 
except that they are required to follow a C4 and use its retained data 
instead of having a format D of their own.  Whether that is the right 
design I don't know.  It is one of several designs I thought of looking 
at the question you raised.  In fact, different use cases may want 
different specific solutions.  Which is fine.  None of them need to hold 
up the mna-hdr draft as they do not change the base formats.


Yours,

Joel

On 6/12/2024 5:42 AM, Dongjie (Jimmy) wrote:
>
> Hi Jags, Tianran and all,
>
> Regarding the use cases of grouping, section 4 of 
> draft-ietf-mpls-mna-usecases describes the co-existence of multiple 
> MNA use cases (applications) in the same packet, which may require the 
> presence of multiple ancillary data in the packet. If such ancillary 
> data needs to be carried as ISD, the encoding efficiency of ISD needs 
> to be considered.
>
> One example is the coexistence of IOAM and other flow-based actions, 
> such as flow-based load-balancing and PREOF as defined in Detnet. In 
> these applications, the Flow ID and sequence number can be considered 
> as common ancillary data which can be used for multiple actions.
>
> Apparently, carrying Flow ID and/or sequence number multiple times in 
> ISD would cost additional LSEs, and is a waste of the precious ISD 
> space.  In this case, introduce some grouping mechanism for multiple 
> opcodes/actions, and allow the sharing of common ancillary data sounds 
> reasonable to me.
>
> Best regards,
>
> Jie
>
> *From:*Jaganbabu Rajamanickam (jrajaman) 
> [mailto:jrajaman=[e-mail]]
> *Sent:* Thursday, June 6, 2024 7:18 PM
> *To:* Tianran Zhou <zhoutianran=[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:* [mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr
>
> Yes, this is per application.
>
> As I mentioned before, I couldn’t see any real application where we 
> need cross application grouping.
>
> Thanx,
>
> Jags
>
> *From: *Tianran Zhou <zhoutianran=[e-mail]>
> *Date: *Thursday, June 6, 2024 at 2:03 AM
> *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
>
> Hi Jag,
>
> In your case, if I understand correctly, the application need to know 
> how many actions needed, and predefine/standardize the opcode with for 
> example 4 sub actions (A,B,C,D).
>
> What about other applications? What if an application need 3 sub 
> actions, but are (A, B, *E*)? Where is E?
>
> For option-1, IMHO, you need to define opcode per application. Right?
>
> It’s not scalable.
>
> Tianran
>
> *From:*Jaganbabu Rajamanickam (jrajaman) 
> [mailto:jrajaman=[e-mail] 
> <mailto:jrajaman=[e-mail]>]
> *Sent:* Thursday, June 6, 2024 9:27 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
>
> 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] 
> <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 to [e-mail]
>