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

[Joel Halpern <[e-mail]>]

The point is that there are multiple ways, compatible with the base mna 
hdr draft, that a new specific set of opcodes can encode any need for a 
relationship among them.  The exact way one does so depends upon the 
kind of relationship, the needed data for each component, etc.  Jags 
example is one of several such.  THere is no need to include any 
specification for this in the MNA HDR draft.


Also, simply adding a C' format is not as simple as it might be, as it 
would break the paradigm we have of being able to determine the format 
from either the special label or the context of previous labels in the 
MNA HDR substack.

Yours,

Joel

On 6/6/2024 2:02 AM, Tianran Zhou wrote:
>
> 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]]
> *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]
>