[mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr (2nd WG call)

[Greg Mirsky <[e-mail]>]

Hi Zafar,
are you proposing a text for the updated charter of the MPLS WG that any
draft that changes the MPLS data plane can be progressed only after two
independent HW implementations demonstrate interoperability in a verifiable
way according to the pre-determined procedure? Do I get your intention
correctly?

Regards,
Greg

On Tue, Oct 8, 2024 at 5:50 PM Zafar Ali (zali) <[e-mail]> wrote:

> Greg
>
>
>
> IDR requires interoperable “software” implementations – so the bar for
> “hardware” implementation must be higher and now lower.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Tuesday, October 8, 2024 at 8:45 PM
> *To: *Zafar Ali (zali) <[e-mail]>
> *Cc: *Tony Li <[e-mail]>, Stewart Bryant <
> [e-mail]>, mpls <[e-mail]>
> *Subject: *Re: [mpls] Re: Working Group Last Call on
> draft-ietf-mpls-mna-hdr (2nd WG call)
>
> Hi Zafar,
>
> AFAICS, IDR does not require interoperable hardware implementations on
> which you insist. Am I correct? Furthermore, are you suggesting that the
> MPLS WG must update its charter to accommodate your demand?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Oct 8, 2024 at 5:37 PM Zafar Ali (zali) <[e-mail]> wrote:
>
> Hi Greg
>
>
>
> Re: Can you point out to me to where in IETF, Routing Area, or MPLS WG
> document such requirement is stated?
>
>
>
> From the Routing Area here is an example: https://wiki.ietf.org/group/idr
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Tuesday, October 8, 2024 at 8:21 PM
> *To: *Zafar Ali (zali) <[e-mail]>
> *Cc: *Tony Li <[e-mail]>, Stewart Bryant <
> [e-mail]>, mpls <[e-mail]>
> *Subject: *Re: [mpls] Re: Working Group Last Call on
> draft-ietf-mpls-mna-hdr (2nd WG call)
>
> Hi Zafar,
>
> you said:
>
> This is why interop between at least two hardware implementations is a
> minimal requirement to progress the standard track document.
>
> Can you point out to me to where in IETF, Routing Area, or MPLS WG
> document such requirement is stated?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Oct 8, 2024 at 4:45 PM Zafar Ali (zali) <zali=
> [e-mail]> wrote:
>
> Hi Tony,
>
>
>
> I agree with you that “the encoding is complex”.
>
>
>
> I would like to add that merely ensuring backward compatibility is not a
> barometer for gauging whether a design change is major or not.
>
> This is a major design change to MPLS that will requires hardware re-spin
> if we find issues during interoperability testing.
>
> This is why interop between at least two hardware implementations is a
> minimal requirement to progress the standard track document.
>
> This is a WG document; why rush it and create risks?
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
> *From: *Tony Li <[e-mail]>
> *Date: *Tuesday, October 8, 2024 at 12:51 PM
> *To: *Stewart Bryant <[e-mail]>
> *Cc: *mpls <[e-mail]>
> *Subject: *[mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr
> (2nd WG call)
>
>
> [WG chair hat: off]
>
> Hi Stewart,
>
> To be accurate, this is not a design change to MPLS. No legacy equipment
> will cease to function because of this.
>
> It is an addition, and while the encoding is complex, it’s conceptually
> quite simple.
>
> Whether it is ‘significant’ or not is highly subjective.
>
> T
>
>
> > On Oct 8, 2024, at 3:28 PM, Stewart Bryant - stewart.bryant at gmail.com
> <[e-mail]> wrote:
> >
> > I would really like to hear from the h/w engineers first hand, rather
> than be told that "they looked at it”.
> >
> > Without that interaction it is difficult to make an objective decision
> on a significant design change to MPLS.
> >
> > - Stewart
> >
> >
> >> On 7 Oct 2024, at 16:50, Joel Halpern <[e-mail]> wrote:
> >>
> >> I am sure that this change is trivial for some hardware.  What is not
> obvious is that it is trivial for a sufficiently large portion of the
> hardware that the imposition of the extra complexity and / or development
> passes makes sense.  We have been told that hardware engineers looked at
> and improved the design.  I try not to pretend to expertise I do not have.
> >>
> >> Yours,
> >>
> >> Joel
> >>
> >>> On 10/7/2024 10:52 AM, Stewart Bryant wrote:
> >>> Joel
> >>>
> >>> The hardware at the point of decision is having to check for other
> triggers, so the check is not unique. How much of a burden is it to make
> both the  32bit and 64bit check in parallel?
> >>>
> >>> I suspect in the scheme of things the extra gates needed  would be
> trivial.
> >>>
> >>> Stewart
> >>>
> >>>
> >>>
> >>>> On 7 Oct 2024, at 3:42 PM, Joel Halpern <[e-mail]> wrote:
> >>>>
> >>>> I understand the driver for suggesting experimental.  However, I am
> little concerned by this approach.  This forwarding is presumably typically
> supported in hardware.  While some hardware will have the identification
> adjustable, it does not seem at all clear that all, or even most, hardware
> will have that flexibility.   Asking implementors to respin software is
> something we do all the time, and is quite reasonable.  But asking folks to
> respin behavior that may be embedded in ASIC chips is both a major
> imposition and a significant backwards compatibility problem.
> >>>>
> >>>> thus, while I sympathize with the suggest, I think we really need to
> publish this draft promptly as a Proposed Standard if we expect folks to
> implement it.
> >>>>
> >>>> Yours,
> >>>>
> >>>> Joel
> >>>>
> >>>>
> >>>>> On 10/7/2024 10:31 AM, Stewart Bryant wrote:
> >>>>> I have been thinking the same.
> >>>>>
> >>>>> Hop by hop changes of this magnitude are a big deal.
> >>>>>
> >>>>> The safest option would be to run it as experimental protocol on an
> ESPL. That way we can learn more about the design and its properties and if
> we need to make a change we have plenty more ESPLs
> >>>>>
> >>>>> If the experiment succeeds we can move to PS with a BSPL.
> >>>>>
> >>>>> Stewart
> >>>>>
> >>>>>>> On 7 Oct 2024, at 10:13 AM, IJsbrand Wijnands <
> [e-mail]> wrote:
> >>>>>> Dear MPLS WG,
> >>>>>>
> >>>>>> Given the nature of the changes to the MPLS architecture for
> supporting ISD in the data-plane, and the various concerns that have raised
> on the list, I believe that this document should be on the experimental
> track.
> >>>>>>
> >>>>>> I do not support publishing this document on standards track.
> >>>>>>
> >>>>>> Thx,
> >>>>>>
> >>>>>> Ice.
> >>>>>>
> >>>>>>> On 24 Sep 2024, at 15:25, Tarek Saad <[e-mail]> wrote:
> >>>>>>>
> >>>>>>> Dear WG,
> >>>>>>>
> >>>>>>> This email starts a two-week Working Group last call for
> draft-ietf-mpls-mna-hdr. This is the 2nd WG last call for this document.
> >>>>>>> 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
> at
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mpls-mna-hdr
> >>>>>>>
> >>>>>>> This poll runs until October 8, 2024.
> >>>>>>>
> >>>>>>> Thank you,
> >>>>>>> Tarek (for the MPLS WG co-chairs)
> >>>>>>> _______________________________________________
> >>>>>>> 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]
> >
> > _______________________________________________
> > 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]
>
>