Re: [mpls] Comments on draft-andersson-mpls-mna-fwk-01

[John E Drake <[e-mail]>]

Hi,

The draft 'draft-song-mpls-eh-indicator' specifically precludes in-stack ancillary data.  I have made the point before that the Framework draft, i.e., the subject draft, already allows this if we define every network action to have either no ancillary data or *only* post-stack ancillary data.

So, I think the question Tony is really asking is whether we include an optimization for that draft's solution by allowing the NAI field to be not present in the NAS.  We can certainly do that, by permitting each post-stack element to consist of a codepoint that identifies the specified network action along with its ancillary data, if any.  However, there is the elephant in the room which has been studiously ignored by the proponents of *only* post-stack network actions (indicators and ancillary data), viz, if a transit LSR cannot find the bottom of the stack, it can't find the post-stack network action, which renders solutions of this type less than useful.

As I mentioned in the call today, to specifically exclude at this point the possibility of in-stack ancillary data for all time is a complete failure in judgement, particularly since the evidence that it works, the ELI/EL, is compelling.

Yours Irrespectively,

John



Juniper Business Use Only
From: mpls <[e-mail]> On Behalf Of Tony Li
Sent: Thursday, May 26, 2022 1:50 PM
To: Dongjie (Jimmy) <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [mpls] Comments on draft-andersson-mpls-mna-fwk-01

[External Email. Be cautious of content]


Hi Jimmy,

Thank you for your comments.  I've replied to each and every one of them.  As you commented inside of a Word document, I've replied in kind.  Please see the attached document.

I have made a number of the changes that you've suggested.  I will send a separate post to the list with the updated document and a diff.

Many of the changes that you suggested hinge on a single question which you did not raise directly.  That question should have the input of the broader group, so I'll raise it explicitly now:

        Currently the framework document implicitly precludes some of the mechanisms found in draft-song-mpls-eh-indicator.
        Should the framework draft be broadened to encompass this draft?

Speaking personally (co-author hat off), I don't see an architectural reason to disagree. Please don't take this as support of the draft.  I still believe that this is a sub-optimal approach, but could it work architecturally?  I have to say that yes, it could, and thus the framework draft could and should be broadened to encompass this.

If the group agrees with this, the changes to implement this are minimal and straightforward.

Could I please get input from the group?

Regards,
Tony


> On May 25, 2022, at 7:34 AM, Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>> wrote:
>
> Dear authors,
>
> Thanks for the effort in organizing and updating this document. I've reviewed the current version and have a number of comments and suggestions.
>
> In my view, the most important thing for this framework document is to describe the possible changes introduced to the MPLS architecture, the MPLS data plane encoding, and the processing behaviors of the LSRs.
>
> Please find the attached file for the details of my review notes.
>
> Hope it helps and looking forward to your feedback.
>
> Best regards,
> Jie
> <draft-andersson-mpls-mna-fwk-01_Jie Dong_0525.docx>
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!HzFyeWZ8Oi08nfapvflV1zbpwVpGFu67e-ycZHEZ_BptHbCXseKnAlTwuSUoNXsJ2rgOD6D8uSfO6D9n$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!HzFyeWZ8Oi08nfapvflV1zbpwVpGFu67e-ycZHEZ_BptHbCXseKnAlTwuSUoNXsJ2rgOD6D8uSfO6D9n$>