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

["Zafar Ali (zali)" <[e-mail]>]

Hi Joel

Re: asking folks to respin behavior that may be embedded in  ASIC chips is both a major imposition and a significant backwards compatibility problem.

What I hear from the proponent of the proposal is that it is flawless for any future implementation, extension, and interop.
If the proponent’s claims are true, then why there be a need to change the experimental RFC? It will be just a tag change.

Thanks

Regards … Zafar

From: Joel Halpern <[e-mail]>
Date: Monday, October 7, 2024 at 10:43 AM
To: Stewart Bryant <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr (2nd WG call)
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]