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

[Tony Li <[e-mail]>]

[WG chair hat: on]

Hi Stewart,

Allow me to reiterate things that I think you know quite well.

The WG leadership also participates within the WG and should always explicitly state whether they are acting in their role as WG leadership or as a participant.

The WG leadership has no position on technical issues. The WG leadership’s goal is to ensure and expedite process. That is all.

WG leadership does have the responsibility for determining the consensus of the WG. Doing so without conducting a hum, poll, MeetEcho poll, or similar would be inappropriate. WG chairs cannot read minds and cannot and should not draw conclusions without explicit input. Even with some explicit input, no matter how often repeated or how loudly proclaimed, it may not be the consensus of the WG and does not make for consensus.

Yelling does not work.

Repetition does not help.

WG leadership (including our AD) has decided that we will not conduct a consensus check on PSD. Rather we will debate the topic on the respective drafts as they come up.

Regards,
Tony


> On Oct 3, 2024, at 2:47 AM, Stewart Bryant - stewart.bryant at gmail.com <[e-mail]> wrote:
> 
> The WG leadership position may or may not align with the consensus of the WG.
> 
> If the WG disagrees, with the chairs, the AD may express an opinion, but it would be unusual for the WG consensus to take priority on a matter such as this.
> 
> In the event of a disagreement the WG or indeed any member of the WG  can appeal, or and in any case they can elevate their concerns to the IESG at IETF LC, or even post approval through the appeal process.
> 
> The normal approach in cases such as this would be to resolve the PSD situation by WG consensus rather than WGC direction, and I would hope that is the path that we follow.
> 
> Best regards
> 
> Stewart
> 
> 
>> On 30 Sep 2024, at 17:56, Tony Li <[e-mail]> wrote:
>> 
>> 
>> [WG chair hat: on]
>> 
>> As has been pointed out, we have not conducted a discussion and a consensus check on whether PSD is required. After discussions, WG leadership has decided not to take that path and that we will simply continue to progress documents and let discussions happen within that context.
>> 
>> Regards,
>> Tony
>> 
>> 
>>> On Sep 30, 2024, at 7:47 AM, John Drake <[e-mail]> wrote:
>>> 
>>> Hi,
>>> 
>>> I will defer to the chairs who are responsible for judging consensus. 
>>> 
>>> Thanks,
>>> 
>>> John
>>> 
>>> On Monday, September 30, 2024 at 07:44:17 AM PDT, Tianran Zhou <zhoutianran=[e-mail]> wrote:
>>> 
>>> 
>>> > There is no consensus that PSD is required and as Joel points out
>>> 
>>> Could you please point out how you get this?
>>> 
>>> Tianran 
>>> 
>>> 
>>> 
>>> Sent from WeLink
>>> 发件人： John Drake<je_drake=[e-mail] <mailto:je_drake=[e-mail]>>
>>> 收件人： Zafar Ali (zali)<[e-mail] <mailto:[e-mail]>>;Gyan Mishra<[e-mail] <mailto:[e-mail]>>
>>> 抄送： Tianran Zhou<[e-mail] <mailto:[e-mail]>>;Dongjie (Jimmy)<[e-mail] <mailto:[e-mail]>>;[e-mail] <mailto:[e-mail]>;MPLS Working Chairs<[e-mail] <mailto:[e-mail]>>;[e-mail] <mailto:[e-mail]>
>>> 主题： Re: [mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr (2nd WG call)
>>> 时间： 2024-09-30 21:36:02
>>> 
>>> Gyan,
>>> 
>>> There is no consensus that PSD is required and as Joel points out, the only PSD proposal on the table works just fine with draft-ietf-mpls-mna-hdr.
>>> 
>>> John 
>>> 
>>> 
>>> On Sunday, September 29, 2024 at 08:23:20 PM PDT, Gyan Mishra <[e-mail]> wrote:
>>> 
>>> 
>>> 
>>> Dear Chairs & WG 
>>> 
>>> To clarify my position on PSD work is that the work should be completed meaning at a minimum implemented by two vendors for interoperability and at WGLC state.  The MNA header draft now in WGLC could then be progressed including PSD solution.
>>> 
>>> Thank you 
>>> 
>>> Gyan
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Sun, Sep 29, 2024 at 3:33 AM Gyan Mishra <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Dear Chairs & WG
>>> 
>>> I agree with points raised by  Zafar, Jimmy, Tianran, Loe and other WG members that this is a hardware implementation that is standards track and that said must have a minimum two interoperable implementations.
>>> 
>>> I support both ISD and PSD.
>>> 
>>> There has been a lot of discussions on ML about both and I think both should be included in this draft as they are in the MNA framework architecture draft section 3.6.
>>> 
>>> https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-fwk-10#name-encoding-of-post-stack-data
>>> 
>>> I agree the PSD work should be completed before we move forward with progressing this document.
>>> 
>>> This was from “IOAM and PSD” discussion this past summer:
>>> 
>>> From Michel Menth 8/3/23 below 
>>> - presented some results at an interim meeting before:
>>> https://datatracker.ietf.org/meeting/interim-2024-mpls-01/session/mpls
>>> 
>>> IOAM requires mutable data. In combination with multiple labels, e.g., for SR, these mutable data need to be near the bottom of the stack, otherwise they get popped along the way. Moving them to PSD makes encoding more efficient without increasing the effective header length that needs  to be parsed. Therefore, we think PSD is the better option for applications like IOAM.
>>> 
>>> This draft is not ready for progression at this time.
>>> 
>>> Kind Regards 
>>>  <http://www.verizon.com/>
>>> Gyan Mishra
>>> Network Solutions Architect 
>>> Email [e-mail] <mailto:[e-mail]>
>>> M 301 502-1347
>>> 
>>> 
>>> 
>>> 
>>> On Sun, Sep 29, 2024 at 1:24 AM Zafar Ali (zali) <zali=[e-mail] <mailto:[e-mail]>> wrote:
>>> Dear chairs and the WG,
>>> 
>>>  
>>> 
>>> I agree with points raised by Jimmy, Tianran, Loe and others.
>>> 
>>>  
>>> 
>>> This is hardware implementation.
>>> 
>>> The ask is to progress the document as a standards track RFC.
>>> 
>>> Having at least two interoperable implementations by vendors should be a bare minimum bar.
>>> 
>>>  
>>> 
>>> Support for PSD is part of the MNA architecture
>>> 
>> 
>> _______________________________________________
>> mpls mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>