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

[Greg Mirsky <[e-mail]>]

Hi Zafar,
can you share details on how you arrived at the conclusion that MNA "is a
major hardware change to a technology"? Had any HW expert shared that
position with MPLS WG?
Secondly, what do you imply by

The idea of pushing the change based on legality is dangerous.

Does that mean that you do not support your own proposal to update the
charter of the MPLS WG?

Regards,
Greg

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

> Hi Greg
>
>
>
> This is a major hardware change to a technology that is widely deployed
> over many decades.
>
> The idea of pushing the change based on legality is dangerous.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Tuesday, October 8, 2024 at 8:56 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,
>
> 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]
>
>