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

[Greg Mirsky <[e-mail]>]

Hi Jie,
I'm trying to imagine a case where several MNAs use the same AD entity.
Although I still cannot come up with a realistic scenario, I think the
simple solution could be defining a new MNA that combines all the MNAs that
need to use that AD. But I am really curious to learn what scenario you
have in mind. Or is that a sort of a mental exercise?

Regards,
Greg

On Fri, Jun 14, 2024 at 10:50 PM Dongjie (Jimmy) <jie.dong=
[e-mail]> wrote:

> Hi Joel and all,
>
>
>
> A generic grouping mechanism would allow ancillary data being shared among
> multiple actions, so that only one copy of the ancillary data needs to be
> carried in MPLS packet. Opcodes which need to reuse the same ancillary data
> would be put into the same group, and there can be multiple groups to allow
> flexible sharing.
>
>
>
> The solution you proposed could also work, while the cost is additional
> opcodes (in your example, opcode C4, C5 and C6) need to be defined for data
> reuse with other actions. And it requires additional rules for the ordering
> between opcodes, which to my understanding is also something new and not
> specified in the mna-hdr draft yet. Thus I would say that with both
> solutions, some new mechanism or rule needs to be introduced to allow
> grouping and data reuse. I guess it is the same for other possible
> solutions.
>
>
>
> If we want to make MNA efficient in carrying ancillary data (especially in
> ISD), I’d suggest to take grouping into consideration early rather than
> late, and include necessary mechanism in the base format.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Joel Halpern <[e-mail]>
> *Sent:* Wednesday, June 12, 2024 9:55 PM
> *To:* Dongjie (Jimmy) <[e-mail]>
> *Cc:* [e-mail]; Zhukeyi(Kaiyin,Datacom Standard&Patent) <
> [e-mail]>
> *Subject:* Re: [mpls] Re: Working Group Last Call on
> draft-ietf-mpls-mna-hdr
>
>
>
> 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]
> <jrajaman=[e-mail]>]
> *Sent:* Thursday, June 6, 2024 7:18 PM
> *To:* Tianran Zhou <zhoutianran=[e-mail]>
> <zhoutianran=[e-mail]>; Joel Halpern
> <[e-mail]> <[e-mail]>; [e-mail]
> *Cc:* [e-mail]; MPLS Working Chairs <[e-mail]>
> <[e-mail]>; [e-mail];
> Zhukeyi(Kaiyin,Datacom Standard&Patent) <[e-mail]>
> <[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]
> <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]
> <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]
> <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]>
> <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]>
> <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] <[e-mail]>]
> *Sent:* Tuesday, June 4, 2024 10:50 AM
> *To:* [e-mail]
> *Cc:* MPLS Working Chairs <[e-mail]> <[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
>
>
>
> 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]
>
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>