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

[Joel Halpern <[e-mail]>]

I can think of multiple possible approaches to the  information reuse 
issue.  None of them require explict provision in the base hdr format, 
as they will be specific to the cases that need the sharing.  I strongly 
suspect that the right solution will be different for different sharing 
cases.

What is clear to me is that a generic sharing container will likely not 
work, and if it works will likely be awkward to use in many cases.

Given the range of possible solutions, I see no reason to put any hook 
in the hdr draft, nor do I see any reason to hold up the hdr draft while 
we debate the hypotheticals interminably.

Yours,

Joel

On 6/17/2024 1:51 PM, Adrian Farrel wrote:
>
> Hey Greg,
>
> I’m playing a sort of hypothetical game here, but let’s suppose….
>
> Consider two NAs:
>
>   * Deliver a packet to an identified service (think along the lines
>     of identifying a VRF)
>   * Route a packet using resources and forwarding path according to an
>     identified service (think along the lines of network slicing)
>
> These NAs could be independently present. That is, you might want to 
> have one, or the other, or both.
>
> Both NAs need a “service identifier”. Let’s (continuing the 
> hypothetical drift) assume that a service identifier requires more 
> than 20 bits of AD, so it won’t fit in a single Format B or C LSE.
>
> Currently you’d have to include two LSEs for each NA.
>
> Tianran’s proposal says that you’d only need a total of three LSEs.
>
> Now, this is all being hypothetical from my point of view. I don’t 
> know if those NAs would ever exist, nor what form the service 
> identifier might take. So, yes, this is a sort of mental exercise. But 
> the point is, I think, that it is possible to dream up scenarios.
>
> The trouble with the approach we are taking to MNA is that we are 
> defining a generic mechanism with all sorts of potential future uses. 
> While we do have the use case draft, it certainly doesn’t cover all 
> possible future use cases.
>
> So, the question for us to consider is, is it possible that we will 
> discover several NAs that have common AD? And, if so, will the AD be 
> small enough to be carried in-stack, but large enough to warrant 
> saving LSEs?
>
> Well, that begs a question: do we want to minimise the size of the 
> NAS? I think we generally have that ambition.
>
> Now, after that preamble, I’m not convinced by the proposed technical 
> resolution. I think there may bea more graceful approach such as:
>
>   * Define the MNAs that might share the data
>   * Assign one bit of the AD to mean
>
> 0: The AD contains the actual value
>
> 1: The AD contains the Opcode (NAI) of the LSE that contains the 
> actual value
>
> This is made possible because:
>
>   * The first MNA to be defined does not need to do anything special
>     (just describes the AD to carry the actual value)
>   * Any opcode-based NAI always has space for at least 13 bits of data
>     (which is enough for a flag and a referenced opcode)
>   * Ordering rules should mean that the actual value is always present
>     in the stack first
>
> This approach would not need anything in the base specification, but 
> could be covered in a future draft explaining how it s done.
>
> It might be nice, however, if the spec mentioned the possibility of 
> two NAs sharing AD. It would be only a simple sentence (unless this 
> would sit better in the framework, although it is a bit late to add to 
> that?)
>
> Cheers,
>
> Adrian
>
> *From:*Greg Mirsky <[e-mail]>
> *Sent:* 16 June 2024 05:03
> *To:* Dongjie (Jimmy) <jie.dong=[e-mail]>
> *Cc:* [e-mail]; Zhukeyi(Kaiyin,Datacom Standard&Patent) 
> <[e-mail]>
> *Subject:* [mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr
>
> 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]
>         <mailto:jrajaman=[e-mail]>]
>         *Sent:* Thursday, June 6, 2024 7:18 PM
>         *To:* Tianran Zhou <zhoutianran=[e-mail]>
>         <mailto:zhoutianran=[e-mail]>; Joel Halpern
>         <[e-mail]> <mailto:[e-mail]>;
>         [e-mail]
>         *Cc:* [e-mail]; MPLS Working Chairs
>         <[e-mail]> <mailto:[e-mail]>;
>         [e-mail]; Zhukeyi(Kaiyin,Datacom
>         Standard&Patent) <[e-mail]> <mailto:[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]
>
>     _______________________________________________
>     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]