Hi Joerg, MTU size decrease has been an issue since day one of MPLS. MNA becomes part of the MTU decrease, so this is not a new issue. Regards, Tony > On Nov 13, 2024, at 11:10 AM, Joerg Ott - ott at in.tum.de <mailforwards@xxxxxxxxxxxxxx> wrote: > > Hi Toni, > > thanks much for the quick clarification. If MTU size decrease is not a serious issue to point out explicitly because this goes without saying for the WG, then I am happy. > > Best, > Jörg > > On 12.11.24 23:32, Tony Li wrote: >> Hi Joerg, >> Thank you very much for your review. >>> My nits are essentially two questions, unrelated to transport specifics: >>> >>> 1. The document shall be informational in nature, but uses normative language >>> when it comes to expressing what individual definitions of network actions >>> shall include. But it seems that this normative style is not fully carried >>> through, so that I would advise the authors to do one more pass to validate >>> that all occurrences of must/may/... vs. MUST/MAY/... are correct. >> We have reviewed as you have requested and are satisfied with our usage of terms. Again, this is an informational document and we are using upper case normative terms only where we feel extreme clarity is called for. Specifically, in the discussion of RLD where we are actually proposing implementation specifics and on points where we felt that there some significant need for emphasis. >>> 2. The document describes many choice of how a given solution for a certain >>> network action may realise, e.g., parameter encoding. I value the freedom put >>> forward here but should the framework document provide more guidance in places? >> If it is helpful, we have in hand a single ISD and a single PSD proposal and we are happy with the specifics of those proposals. >>> It does so in some places, e.g., by suggesting that a solution needs to >>> justify their choice under certain circumstances. (This reads a bit odd -- to >>> whom would somebody justify and who is to judge?) I am just curious how much >>> openness is needed or desirable or necessary as opposed to limiting the design >>> space. Such deliberate choice could be made explicit in the beginning. >>> >>> As a concrete example, a solution will have to specify how to skip unknown >>> data. Given the many different options how to encode what, will it is obvious >>> how to achieve this? How about the reuse of elements across solutions? Could >>> interoperability of different design choices be achieved? >> Our designers have had no issues coming up with specific designs that the WG is satisfied with. >> Tony >> _______________________________________________ >> Tsv-art mailing list -- tsv-art@xxxxxxxx >> To unsubscribe send an email to tsv-art-leave@xxxxxxxx > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
