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

[Jaganbabu Rajamanickam <[e-mail]>]

Hello Adrian,
   I like your proposal

    “Mechanisms that allow sharing of AD between multiple MNAs indicated by
different Opcodes can be described in other documents and do not rely on
any explicit provision in the base header format described in this
document.”

  Please suggest, which section in the mna hdr solution would be apt to
insert the above statement ?

Thanx,
Jags

On Mon, Jun 17, 2024 at 5:55 PM Adrian Farrel <[e-mail]> wrote:

> Well now. I think you may have said, a tad more bluntly than me, what I
> said.
>
>
>
> And I wasn’t proposing any hook in the hdr draft. Just a mention of
> something like “Mechanisms that allow sharing of AD between multiple MNAs
> indicated by different Opcodes can be described in other documents and do
> not rely on any explicit provision in the base header format described in
> this document.” This would acknowledge the potential for sharing, without
> going any further.
>
>
>
> As to holding up the hdr draft: we seem to be pretty busy making quite a
> lot of changes to it at the moment, I’m sure a small edit won’t hold
> anything up.
>
>
>
> Adrian
>
>
>
> *From:* Joel Halpern <[e-mail]>
> *Sent:* 17 June 2024 19:43
> *To:* [e-mail]; 'Greg Mirsky' <[e-mail]>;
> 'Dongjie (Jimmy)' <jie.dong=[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [mpls] Re: Working Group Last Call on
> draft-ietf-mpls-mna-hdr
>
>
>
> 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:
>
>    1. Deliver a packet to an identified service (think along the lines of
>    identifying a VRF)
>    2. 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 be a more graceful approach such as:
>
>    3. Define the MNAs that might share the data
>    4. 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:
>
>    5. The first MNA to be defined does not need to do anything special
>    (just describes the AD to carry the actual value)
>    6. Any opcode-based NAI always has space for at least 13 bits of data
>    (which is enough for a flag and a referenced opcode)
>    7. 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]> <[e-mail]>
> *Sent:* 16 June 2024 05:03
> *To:* Dongjie (Jimmy) <jie.dong=[e-mail]>
> <jie.dong=[e-mail]>
> *Cc:* [e-mail]; Zhukeyi(Kaiyin,Datacom Standard&Patent)
> <[e-mail]> <[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]
> <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]
>
>
>
> _______________________________________________
>
> 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]
>