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

["[e-mail]" <[e-mail]>]

The only problem I see is that to this point, we only have speculation that this capability will be necessary.  I.e., as Yakov pointed out, for a given RFC, there are an infinite number of issues that it doesn’t address, so trying to enumerate them is pointless.

Sent from my iPhone

On Jun 17, 2024, at 6:21 PM, Jaganbabu Rajamanickam <[e-mail]> wrote:



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]>
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]]
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]]
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.

 

<image001.png>

 

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]]
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.

<image002.png>

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]]
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]> 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]> 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]]
Sent: Tuesday, June 4, 2024 10:50 AM
To: [e-mail]
Cc: MPLS Working Chairs <[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 https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-hdr/" target="_blank" rel="nofollow">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" target="_blank" rel="nofollow">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]

_______________________________________________
mpls mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]