[mpls] Re: Addition to draft-ietf-mpls-mna-requirements based on framework RTGDIR review

[Tony Li <[e-mail]>]

Jimmy,

Your wording does not preclude 2 ISD solutions. Or 1000.  This was the original point.

Tony


> On May 23, 2024, at 7:12 PM, Dongjie (Jimmy) <jie.dong=[e-mail]> wrote:
> 
> Hi Loa, Joel, Toerless, et.al, 
> 
> I can understand the point in the text proposed by Matthew, while as I mentioned before during the discussion of another restrictive requirements in this document, I'd prefer if it could be stated in a positive way if possible. 
> 
> Thus instead of stating "no more than one solution SHOULD be defined for encoding ISD (or PSD)", maybe it is better to say: 
> 
> The encoding of ISD (or PSD) SHOULD allow future extensions which are compatible to the base MNA solution to meet the requirements of new use cases. 
> 
> It does not matter to me whether ISD and PSD are put in one or two sentences. 
> 
> Best regards,
> Jie
> 
>> -----Original Message-----
>> From: Loa Andersson [mailto:[e-mail]]
>> Sent: Friday, May 24, 2024 7:54 AM
>> To: Joel Halpern <[e-mail] <mailto:[e-mail]>>; Toerless Eckert <[e-mail] <mailto:[e-mail]>>
>> Cc: Matthew Bocci (Nokia) <matthew.bocci=[e-mail] <mailto:matthew.bocci=[e-mail]>>;
>> mpls <[e-mail] <mailto:[e-mail]>>
>> Subject: [mpls] Re: Addition to draft-ietf-mpls-mna-requirements based on
>> framework RTGDIR review
>> 
>> Joel, et.al.,
>> 
>> Inline plz.
>> 
>> Den 2024-05-23 kl. 22:47, skrev Joel Halpern:
>>> I wonder if there is a different approach to your concern that maybe
>>> we will nee3d more than one "solution"  for MNA.  (I fear that we are
>>> now using "solution" in different ways, but that is a different
>>> problem / discussion.)
>>> 
>>> SUppose we put in the wording Matthew has proposed.
>>> 
>>> Now, ask ourselves what happens if the WG finds that it NEEDS two
>>> encodings (I personally can't see it, but that is a topic on which
>>> reasonable people can differ.)  As far as I can tell, the WG produces
>>> a new draft (eventually RFC) which includes justification as to why a
>>> second encoding is needed, and explicitly updates the requirements
>>> RFC.  Given the cost of having two different encodings for in-stack
>>> data (very high in terms of implementation work) that seems an
>>> eminently reasonable bar.
>> 
>> 
>> Yes, I agree with your reasoning, and I don't really can see it happing (though I
>> can't exclude that it will). That is why I'd rather see the Framework being
>> updated, than the Requirements.
>> 
>> /Loa
>> 
>>> 
>>> Yours,
>>> 
>>> Joel
>>> 
>>> On 5/23/2024 4:39 PM, Toerless Eckert wrote:
>>>> Greg, *:
>>>> 
>>>> I see a lot of agreement. I see no technical arguments for it.
>>>> 
>>>> IMHO there is not sufficient implementation experience to conclude
>>>> that a single MNA solution will suffice to support all desired
>>>> Network Action solutions. I think we can agree and codify that there
>>>> is the desire to have a standardized MNA solution that will support
>>>> all desired Network Action solutions, but unless we know better from
>>>> experience thast this is feasible across all vendors, it is IMHO
>>>> premature to mandate the WG process to only standardize one MNA
>>>> solution.
>>>> 
>>>> But sure, we can always merge alternative MNA solutions into one RFC
>>>> by calling them flavors, right ?
>>>> Aka: The "there SHOULD be only one spec" process requirement already
>>>> has a known IETF process workaround to render it (IMHO) mostly
>>>> meaningless.
>>>> 
>>>> Cheers
>>>>      Toerless
>>>> 
>>>> On Thu, May 23, 2024 at 12:28:10PM -0700, Greg Mirsky wrote:
>>>>> Hi Toerless et al.,
>>>>> firstly, I support adding two requirements proposed by Matthew.
>>>>> Furthermore, several comments in-lined below under the GIM>> tag.
>>>>> 
>>>>> Regards,
>>>>> Greg
>>>>> 
>>>>> On Thu, May 23, 2024 at 11:02 AM Toerless Eckert <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> 
>>>>>> On Thu, May 23, 2024 at 10:38:46AM -0700, Tony Li wrote:
>>>>>>> [WG chair hat: off]
>>>>>>> 
>>>>>>> Hi Toerless,
>>>>>>> 
>>>>>>> a) No one said that the requirements draft only had to contain
>>>>>>> technical
>>>>>> requirements.  No matter the level of the requirement, it makes
>>>>>> sense to write it down, otherwise people seem to be confused about
>>>>>> it.
>>>>>> 
>>>>>> Is there any precedent for this type of requirement in a
>>>>>> requirements RFC ?
>>>>>> 
>>>>> GIM>> What is the purpose of finding such precedent? AFAIK, IETF is
>>>>> GIM>> not
>>>>> governed by the precedent but by rough consensus and the running code.
>>>>> 
>>>>>> E.g.: Was this done in SPRING for compressed header ? (just an
>>>>>> example coming to mind).
>>>>>> (any other relevant requirements RFC would be fine too).
>>>>>> 
>>>>> GIM>> Yes, there was a good discussion in SPRING WG about the SRv6
>>>>> compressed SID
>>>>> <https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/>.
>>>>> 
>>>>> As I understand the outcome of the discussion, the draft defines a
>>>>> single solution with two behaviors.
>>>>> 
>>>>>>> b) If a solution does not meet all requirements, then that gives
>>>>>>> us a
>>>>>> metric to evaluate the solution(s) and determine how to progress.
>>>>>> 
>>>>>> But without saying exactly that explicitly in the requirements
>>>>>> document too, the two requirements proposed by Matt would be
>>>>>> misleading/incomplete. And my proposed requirement text is an
>>>>>> attempt to close that gap.
>>>>>> 
>>>>> GIM>> I agree that explicitly stated requirements are preferable.
>>>>> But in
>>>>> this particular case, if we follow your proposal, all requirements
>>>>> must be clearly identified as either ISD or PSD related. I don't
>>>>> find that to be a productive exercise. Hence, I can live with the
>>>>> requirements as proposed by Matthew.
>>>>> 
>>>>>>> I think Matthew’s point in breaking the requirement up was
>>>>>>> clarity,
>>>>>> which I think is the right direction. Evaluating complex Boolean
>>>>>> expressions is a silicon strength and a natural language challenge.
>>>>>> 
>>>>>> I didn't complain about his requirements being composed of two
>>>>>> requirements. Yes, they are nicely readable.
>>>>>> 
>>>>>> My proposed requirement text is NOT meant as textual enhancements
>>>>>> of his requirements, but as a logically more fundamental
>>>>>> requirement which is missing (if we agree we want it), which is
>>>>>> that we would want that a standardized encoding for in-stack and
>>>>>> post-stack data to support all requirements - so that we do not
>>>>>> need to standardize multiple (potentially
>>>>>> overlapping/competing)
>>>>>> solutions.
>>>>>> 
>>>>>> Cheers
>>>>>>      Toerless
>>>>>> 
>>>>>> * A single standards track A combination of at most one standards
>>>>>> track solution for encoding of in-stack ancillary
>>>>>>>>   data and one standards track solution for encoding of
>>>>>>>> post-stack
>>>>>> ancillary data SHOULD
>>>>>> 
>>>>>> 
>>>>>>> Tony
>>>>>>> 
>>>>>>> 
>>>>>>>> On May 23, 2024, at 9:29 AM, Toerless Eckert <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> a) I do not think this is an appropriate technical requirement
>>>>>>>> because
>>>>>> it is a meta/process
>>>>>>>> requirement.Aka: It is fine for a WG to conclude that it does not
>>>>>>>> want
>>>>>> competing solutions
>>>>>>>> to constrain resources spent and maximize revenue, but i can not
>>>>>> remember that we codified
>>>>>>>> this in requirements documents. Typically i think this type of
>>>>>> agreement is done in WG discussion/consensus.
>>>>>>>> (I may be wrong)
>>>>>>>> 
>>>>>>>> b) I also don't think it would be sufficient or would work:
>>>>>>>> Consider a
>>>>>> solution presented
>>>>>>>> does not solve all requirements. What then ?
>>>>>>>> 
>>>>>>>> Counter proposal: Aka: Maybe the correct requirement for the
>>>>>>>> document
>>>>>> is something like:
>>>>>>>> * A combination of at most one standards track solution for
>>>>>>>> encoding
>>>>>> of in-stack ancillary
>>>>>>>>   data and one standards track solution for encoding of
>>>>>>>> post-stack
>>>>>> ancillary data SHOULD
>>>>>>>>   support all requirements in this document.
>>>>>>>> 
>>>>>>>> Cheers
>>>>>>>>     Toerless
>>>>>>>> 
>>>>>>>> On Thu, May 23, 2024 at 08:58:50AM +0000, Matthew Bocci (Nokia)
>>>>>>>> wrote:
>>>>>>>>> WG
>>>>>>>>> 
>>>>>>>>> One of the issues that came up in the RTGDIR review of
>>>>>> draft-ietf-mpls-mna-fwk was that a clarification that the intent of
>>>>>> the working group is to limit the number of ISD encodings and PSD
>>>>>> encodings to one to ease interoperability (see [RTG-DIR]Re: RtgDir
>>>>>> Early review:
>>>>>> draft-ietf-mpls-mna-fwk-06.txt<
>>>>>> https://mailarchive.ietf.org/arch/msg/rtg-dir/KpUCyBhdVgn7nWG8j_Y6g
>>>>>> Zj5xSw/
>>>>>> 
>>>>>>> ).
>>>>>>>>> This is probably better addressed in the requirements draft.
>>>>>>>>> Therefore, I propose that we add the following two new
>>>>>>>>> requirements
>>>>>> to section 3.5.  Requirements on Ancillary Data:
>>>>>>>>>   *   Not more than one standards track solution SHOULD be
>>>>>>>>> defined for
>>>>>> encoding in-stack ancillary data.
>>>>>>>>>   *   Not more than one standards track solution SHOULD be
>>>>>>>>> defined for
>>>>>> encoding post-stack ancillary data.
>>>>>>>>> Please let me know if you have any comments.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thanks
>>>>>>>>> 
>>>>>>>>> Matthew
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> mpls mailing list -- [e-mail] To unsubscribe send an email
>>>>>>>>> to [e-mail]
>>>>>>>> _______________________________________________
>>>>>>>> mpls mailing list -- [e-mail] <mailto:[e-mail]> <mailto:[e-mail]> To
>>>>>>>> unsubscribe send an email to [e-mail] <mailto:[e-mail]> <mailto:
>>>>>> [e-mail] <mailto:[e-mail]>>
>>>>>> 
>>>>>> --
>>>>>> ---
>>>>>> [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]>
>> 
>> _______________________________________________
>> 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]>