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

[John Drake <[e-mail]>]

 Jie,
Actually, the subject draft had a PSD indicator and Loa told them to take it out.  This is actually normal, since as you point out, we don't know if we actually need PSD.
John 

    On Sunday, September 29, 2024 at 08:46:46 PM PDT, Dongjie (Jimmy) <jie.dong=[e-mail]> wrote:  
 
 
Hi Joel,
 
  
 
Having some fields defined as reserved is to leave room for future functions which currently we don’t have in mind.
 
  
 
In this case, according to the MNA framework and the recent poll on IOAM and PSD, it is clear that PSD is in the scope of MNA, and using one bit flag as the indicator for PSD is one candidate approach currently under discussion, which can have impact to the encoding of the NAS. It is better to finalize the discussion about the PSD indication, then make necessary changes to draft-ietf-mpls-mna-hdr accordingly.
 
  
 
IMO making a bit reserved first then updating its semantic very soon is not good for standardization nor implementation.
 
  
 
Best regards,
 
Jie
 
  
 
From: Joel Halpern [mailto:[e-mail]]
Sent: Sunday, September 29, 2024 10:12 PM
To: Zafar Ali (zali) <zali=[e-mail]>; Tony Li <[e-mail]>
Cc: mpls <[e-mail]>
Subject: [mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr (2nd WG call)
 
  
 
I fail to see the coupling you are asserting.  We can happily define the reserved bit in the ISD RFC.  And then, if the WG adopts a PSD draft, it can define that bit to have specific meaning, if the solution needs that.  We do this all the time in lots of our protocols.  That is in fact why we define reserved bits.  Any solution implementing PSD will know about that bit and its meaning.  The fact that some ISD solutions that do not support PSD do not know aobut the bit does not cause any difficulty.  The PSD solution already needs to deal with requiring that the node addressed by the bottom of the stack understands PSD and will properly remove the PSD.
 
I also disagree with a number of the other objections.  I am trying to think through the clearest way to explain my disagreement.  I hope to post that within a few days.
 
Yours,
 
Joel
 
On 9/29/2024 9:55 AM, Zafar Ali (zali) wrote:
 

Hi Tony 
 
 
 
I am aware of the thread but all we hear is that chairs are discussing the responses and will share further update, “interest” vs. “consensus” debate, the chairs are discussing how to initiate the PSD debate, etc. There were 65 emails on the original PSD poll. I am not sure why we need another round of debate and what will be the nature of that debate. Why not just start WG adoption call and gauge the WG “consensus”.
 
 
 
For the reason many others and I mentioned, I also fail to see the rush to progress draft-ietf-mpls-mna-hdr, prematurely.
 
Let’s first have the working group complete the work on PSD and all the pieces and gain implementation maturity. 
 
 
 
Thanks
 
 
 
Regards … Zafar
 
 
 
From:Tony Li <[e-mail]> on behalf of Tony Li <[e-mail]>
Date: Sunday, September 29, 2024 at 2:00 AM
To: Zafar Ali (zali) <[e-mail]>
Cc: Tianran Zhou <zhoutianran=[e-mail]>, Dongjie (Jimmy) <jie.dong=[e-mail]>, Tarek Saad <[e-mail]>, mpls <[e-mail]>, mpls-chairs<[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Working Group Last Call on draft-ietf-mpls-mna-hdr (2nd WG call)
 
[WG chair hat: on]
 
 
 
Hi Zafar,
 




 

On Sep 28, 2024, at 10:22 PM, Zafar Ali (zali) - zali at cisco.com<[e-mail]> wrote:
 
 
 
There was a rather encrypted WG poll on PSD interest which shows clear support from vendors and operators to work on the PSD option.
 
However, the working group has not heard any outcome of the poll.
 

 
 
Tarek posted the outcome of the poll on August 14th: https://mailarchive.ietf.org/arch/msg/mpls/qHBCt-X17u_VLIbuJuuS22C-ru8/
 
 
 
There were several subsequent comments on that thread that were also relevant.
 
 
 
T
 
 
 



 _______________________________________________ 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]