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

["Jaganbabu Rajamanickam (jrajaman)" <[e-mail]>]

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.



[cid:image002.png@01DAB78E.8CF69420]

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]<mailto:zhoutianran=[e-mail]>>
Date: Wednesday, June 5, 2024 at 8:25 PM
To: Jaganbabu Rajamanickam (jrajaman) <[e-mail]<mailto:[e-mail]>>, Joel Halpern <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, MPLS Working Chairs <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Zhukeyi(Kaiyin, Datacom Standard&Patent) <[e-mail]<mailto:[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.
[cid:image001.png@01DAB7F0.42875390]
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]<mailto:[e-mail]>>; Tianran Zhou <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; MPLS Working Chairs <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Zhukeyi(Kaiyin,Datacom Standard&Patent) <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Date: Wednesday, June 5, 2024 at 8:39 AM
To: Tianran Zhou <zhoutianran=[e-mail]<mailto:zhoutianran=[e-mail]>>, [e-mail]<mailto:[e-mail]> <je_drake=[e-mail]<mailto:je_drake=[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, MPLS Working Chairs <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Zhukeyi(Kaiyin,Datacom Standard&Patent) <[e-mail]<mailto:[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]<mailto:[e-mail]><je_drake=[e-mail]<mailto:je_drake=[e-mail]>>
收件人： Tianran Zhou<[e-mail]<mailto:[e-mail]>>
抄送： John Drake<[e-mail]<mailto:[e-mail]>>;Tarek Saad<[e-mail]<mailto:[e-mail]>>;[e-mail]<mailto:[e-mail]>;MPLS Working Chairs<[e-mail]<mailto:[e-mail]>>;[e-mail]<mailto:[e-mail]>;Zhukeyi(Kaiyin,Datacom Standard&Patent)<[e-mail]<mailto:[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]<mailto:je_drake=[e-mail]>>
收件人： Tarek Saad<[e-mail]<mailto:[e-mail]>>;[e-mail]<mailto:[e-mail]>;Tianran Zhou<[e-mail]<mailto:[e-mail]>>
抄送： MPLS Working Chairs<[e-mail]<mailto:[e-mail]>>;[e-mail]<mailto:[e-mail]>;Zhukeyi(Kaiyin,Datacom Standard&Patent)<[e-mail]<mailto:[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]]
Sent: Tuesday, June 4, 2024 10:50 AM
To: [e-mail]<mailto:[e-mail]>
Cc: MPLS Working Chairs <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
mpls mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>


_______________________________________________

mpls mailing list -- [e-mail]<mailto:[e-mail]>

To unsubscribe send an email to [e-mail]<mailto:[e-mail]>