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

[Joel Halpern <[e-mail]>]

So you are proposing to require C' always between B and C, even though 
the use cases we have seen to date do not require a grouping mechanism?  
And even though there are ways to achieve grouping with the existing 
formats?   That does not seem beneficial.

Yours,

Joel

On 6/6/2024 12:10 PM, Tianran Zhou wrote:
> It’s a simple extension to the existing mechanism.
> But this need to change existing process sequence. Specifically, c’ 
> must follow b, and c must follow c’.
> If it is in another document, it will need to update this hdr. I don’t 
> think it is a good way to.
>
> Tianran
>
>
> ------------------------------------------------------------------------
>
> Sent from WeLink
> *发件人： *Tony Li<[e-mail]>
> *收件人： *Tianran Zhou<[e-mail]>
> *抄送： *Joel M. Halpern<[e-mail]>;Jaganbabu Rajamanickam 
> (jrajaman)<[e-mail]>;[e-mail];mpls<[e-mail]>;mpls-chairs<[e-mail]>;[e-mail];Zhukeyi(Kaiyin,Datacom 
> Standard&Patent)<[e-mail]>
> *主题： *Re: [mpls] Working Group Last Call on draft-ietf-mpls-mna-hdr
> *时间： *2024-06-06 23:58:21
>
>
> [WG chair hat: on]
>
> Hi all,
>
> Speaking as WG chair, this discussion is going around in a 
> less-than-productive circle.
>
> We need specifics.  Could we please put our thoughts together in a 
> coherent draft?  This should describe the use case, the specific 
> encodings, the parsing procedures, the action semantics, the 
> sub-actions, etc.  Am I forgetting something?
>
> Thanks,
> Tony
>
>
>> On Jun 6, 2024, at 8:45 AM, Tianran Zhou 
>> <zhoutianran=[e-mail]> wrote:
>>
>> C’ does not add any complexity. We can use it just as C all the way.
>> But this improves the scalability and flexibility. We are able to 
>> group, and reduce the redundant data.
>>
>> Tianran
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> Sent from WeLink
>> *发件人：*Joel Halpern<[e-mail]>
>> *收件人：*Tianran Zhou<[e-mail]>;Jaganbabu Rajamanickam 
>> (jrajaman)<jrajaman=[e-mail]>;[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-06 23:10:14
>>
>> The point is that there are multiple ways, compatible with the base 
>> mna hdr draft, that a new specific set of opcodes can encode any need 
>> for a relationship among them.  The exact way one does so depends 
>> upon the kind of relationship, the needed data for each component, 
>> etc.  Jags example is one of several such.  THere is no need to 
>> include any specification for this in the MNA HDR draft.
>>
>>
>> Also, simply adding a C' format is not as simple as it might be, as 
>> it would break the paradigm we have of being able to determine the 
>> format from either the special label or the context of previous 
>> labels in the MNA HDR substack.
>>
>> Yours,
>>
>> Joel
>>
>> On 6/6/2024 2:02 AM, Tianran Zhou wrote:
>>> 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.
>>>
>>> <image003.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] 
>>> <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.
>>> <image004.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] 
>>> <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
>>>         fordraft-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
>>>         athttps://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 [e-mail]
>>>         _______________________________________________
>>>         mpls mailing list [e-mail]
>>>         To unsubscribe send an email [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]
>