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

["Dongjie (Jimmy)" <[e-mail]>]

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]>; Toerless Eckert <[e-mail]>
> Cc: Matthew Bocci (Nokia) <matthew.bocci=[e-mail]>;
> mpls <[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]> 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]> To
> >>>>>> unsubscribe send an email to [e-mail] <mailto:
> >>>> [e-mail]>
> >>>>
> >>>> --
> >>>> ---
> >>>> [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 to [e-mail]
> 
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]