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

["[e-mail]" <[e-mail]>]

A very comprehensive summary.  I think we are in a simple situation that is being complicated by FUD

Sent from my iPhone

On Oct 5, 2024, at 2:11 PM, Greg Mirsky <[e-mail]> wrote:



Hi Loa,

thank you for sharing your thoughts. I've added my notes below tagged GIM>>.

Regards,

Greg

On Fri, Oct 4, 2024 at 1:28 AM Loa Andersson <[e-mail]> wrote:

NOTE: This is not an attempt to call WG consensus, merely a way to
explain my position on the ISD vs. PSD position.

Greg,

We have ONE technology - MNA.

WE are discussing two ways of to encapsulate NA's and AD in a packet -
ISD and PSD.

GIM>> I see three elements:

1. MNA Header
2. In-Stack encapsulation of NA and AD
3. Post-Stack encapsulation of NA and AD

 Several observations about the relationship among these elements:

• #1 must be flexible to support ## 2 and 3
• #2 has no dependency on #3
• The solution for #3 may use #1 or #2 or a combination of both

From these observations, I conclude that ##1 and 2 can be progressed while the interested party discusses #3

We one group saying that we don't need PSD.

GIM>> I think that is a bit nuanced (if you view me being in that group). In my opinion, so far, there is no use case that the WG agreed on that cannot be realized using the ISD MNA approach.

We have another group saying that we don't need ISD.

GIM>> No comments here. 

Both groups are rather small.

GIM>> Do you have any statistics to support that conclusion? 

It seem that most participants say that we need both, but just how that
will be accomplished is manifestly unclear.

GIM>> Same as above. 

I'm reluctant to have someone that say "we don't need ISD", specify an
ISD solution.

GIM>> I am open to discuss constructive arguments from anyone. 

I'm reluctant to have someone that say "we don't need PSD", specify a
PSD solution.

GIM>> Same as above. 

You say "each method has issues" and that "must be thoroughly
investigated". Happy to hear that, since that is the first step to a
mutual understanding of each others position.

GIM>> I apologize if I was sufficiently clear in my earlier comment. That was not regarding ISD vs.PSD (MNA HDR and the ISD solution, in my opinion, are clear and are ready for publication), but about the PSD solution.

Until we definitely sort out the relationship between how we encapsulate
both ISD and PSD, I don't think we can rule out interdependencies that
will impact one or both solutions.

GIM>> Besides my comments (mostly editorial and nits) on the draft-ietf-mpls-mna-hdr, I haven't seen any other comments. Unless I've missed comments from other participants, what specific issues, in your opinion, require continued discussion of MNA HDR and ISD?

That is why I want to wait progressing either of the solutions to past
WGLC. And I'd like to see but solutions as working group documents.

/Loa

Den 03/10/2024 kl. 17:36, skrev Greg Mirsky:
> Hi Loa,
> I agree with you that each method has issues and these must be
> thoroughly investigaved. But I fail to understand how that can prevent
> the WG from progressing the current version of draft-ietf-mpls-mna-hdr.
> AFAICS, if we need the P-bit - the PSD specification re-defines the
> R(eserved) flag (that what reserved fields are for, and we've used that
> technique number of times before). And if we choose Opcode - the PSD
> draft will define it without any other impact on the MNA Header. Am I
> missing something here?
>
> Regards,
> Greg
>
> On Thu, Oct 3, 2024 at 1:13 AM Loa Andersson <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Greg,
>
>     I think the jury is still out on this!
>
>     If we know that the MNA PS header follow the LSE with the BoS set or if
>     there are no other PS headers present, the the p-flag is enough.
>
>     It also have the benefit that it saves a LSE compared to the
>     OpCode/Offset method.
>
>     Tony said in a mail 2024-09-02 "Some of us consider saving one LSE per
>     packet to be ample reward."
>
>     On the other hand if the MNA PS header is not immediately after the LSE
>     with the BoS set, I think we need the OpCode/Offset, but I have not yet
>     dug deep enough to say so.
>
>     Also if we could specify both methods (p-flag and  OpCode/Offset) so we
>     can optimize when possible. However two methods also have drawbacks.
>
>     Currently I don't think this has been discussed enough.
>
>     /Loa
>
>     Den 02/10/2024 kl. 20:39, skrev Greg Mirsky:
>      > I agree with John on the P-bit usefulness. As was discussed (and I
>      > presented on DetNet and BIER cases), many applications use their
>     Post-
>      > stack Headers (PSHs). As a result, we cannot assume that PSD always
>      > immediately follows the BoS, and thus PSD requires explicit
>      > specification of the offset from the BoS LSE. That can be done
>     using PSD
>      > Option code point. With that said, what is the role of the P-bit
>     that
>      > some insist on? Indicate that somewhere in the NAS there's PSD
>     Option?
>      > That doesn't look useful to me.
>      >
>      > Regards,
>      > Greg
>      >
>      > On Wed, Oct 2, 2024 at 11:06 AM John Drake
>      > <je_drake=[e-mail]
>     <mailto:[e-mail]>
>      > <mailto:[e-mail]
>     <mailto:[e-mail]>>> wrote:
>      >
>      >     Further, if we decide to use an opcode with ancillary data
>      >     indicating the offset to the PSD we would not need a PSD
>     indicator bit
>      >
>      >     On Wednesday, October 2, 2024 at 11:01:58 AM PDT, John Drake
>      >     <je_drake=[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>> wrote:
>      >
>      >
>      >     Joel is correct.  We have had many discussions of how PSD
>     indicators
>      >     can be added to the framework provided by the subject draft,
>     none of
>      >     which require any changes now to that draft.  So, assuming
>     that we
>      >     ever decide that we need PSD, we can easily add those PSD
>     indicators
>      >     to that draft.
>      >
>      >     On Wednesday, October 2, 2024 at 10:31:05 AM PDT, Joel Halpern
>      >     <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>      >
>      >
>      >     No, that does not follow.   PSD can build on the ISD draft. There
>      >     are no
>      >     changes required to the ISD (mna-hdr) draft to enable
>     supporting PSD.
>      >     Additional opcdes, flags, or other indications can be added
>     in whatever
>      >     PSD draft the working group adopts, if it ever does.
>      >
>      >     The only justification for holding up the ISD draft that I
>     can see
>      >     would
>      >     be if there was support needed in nodes that support ISD and
>     not PSD.
>      >     There is  no indication of such a need.
>      >
>      >     Please do not put words in my mouth.  I have been very clear
>     that the
>      >     ISD draft should be advanced.
>      >
>      >     Yours,
>      >
>      >     Joel
>      >
>      >     On 10/2/2024 1:21 PM, Loa Andersson wrote:
>      >      > Joel,
>      >      >
>      >      > Since you agree that PSD can't be done in isolation, but
>     will depend
>      >      > on ISD (or at least the MPLS label stack), I guess that
>     you also
>      >     agree
>      >      > that we should wait with progress the ISD draft.
>      >      >
>      >      > /Loa
>      >      >
>      >      > Den 02/10/2024 kl. 14:57, skrev Joel Halpern:
>      >      >> You highlight one of many open questions about what a P-
>     flag would
>      >      >> mean.  Which strongly suggests that deferring adding it
>     until we
>      >     have
>      >      >> a working group draft on PSD, which can add it, would be
>     sensible.
>      >      >> And you have not responded meaningfully to my earlier
>     concern that
>      >      >> ther ei sno benefit to assigning the bit isntead of reserving
>      >     it, as
>      >      >> the draft currently does.
>      >      >>
>      >      >> Yours,
>      >      >>
>      >      >> Joel
>      >      >>
>      >      >> On 10/2/2024 6:01 AM, Loa Andersson wrote:
>      >      >>> Zafar and Tianran,
>      >      >>>
>      >      >>> I certainly think that we should have the p-flag re-
>     inserted.
>      >      >>>
>      >      >>> The problematic part is that we can't guarantee that the
>     MNA Post-
>      >      >>> Stack header directly after the LSE with the BoS set. There
>      >     might be
>      >      >>> some CW there and we need to be able (one way or
>     another) to tell
>      >      >>> where the MNA Post-stack header starts. OpCode + offset?
>     That
>      >     is by
>      >      >>> definition ISD, so we need to think a bit about how we
>     specify
>      >     this.
>      >      >>>
>      >      >>> /Loa
>      >      >>>
>      >      >>>
>      >      >>>
>      >      >>> Den 01/10/2024 kl. 18:37, skrev Zafar Ali (zali):
>      >      >>>> Dear chairs and the WG,
>      >      >>>>
>      >      >>>> I agree with Tianran.
>      >      >>>>
>      >      >>>> I am also concerned about lack of implementation
>     experience and
>      >      >>>> interoperability for a data plane change addressing a
>     subset
>      >     of the
>      >      >>>> MNA architecture.
>      >      >>>>
>      >      >>>> These are hardware changes that are not proven or
>     demonstrated in
>      >      >>>> the field, yet.
>      >      >>>>
>      >      >>>> Thanks
>      >      >>>>
>      >      >>>> Regards … Zafar
>      >      >>>>
>      >      >>>> *From: *Tianran Zhou
>     <zhoutianran=[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      >      >>>> *Date: *Monday, September 30, 2024 at 8:08 PM
>      >      >>>> *To: *Joel Halpern <[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >      >>>> *Cc: *mpls <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >      >>>> *Subject: *[mpls] Re: Working Group Last Call on
>      >      >>>> draft-ietf-mpls-mna- hdr (2nd WG call)
>      >      >>>>
>      >      >>>> Looking at the use case draft, PSD can address all use
>     cases and
>      >      >>>> future proof. In this sense, there is no need to
>     implement ISD
>      >     at all.
>      >      >>>>
>      >      >>>> I also started a thread in the working group mailing
>     list to
>      >      >>>> investigate the operators requirements. I only got one
>      >     requirement
>      >      >>>> on noffrr. There’s rare interest on existing MNA.
>      >      >>>>
>      >      >>>> I can’t believe we are going to publish such paper work
>     in a
>      >     hurry.
>      >      >>>>
>      >      >>>> Tianran
>      >      >>>>
>      >      >>>>
>      >      >>>>
>      >      >>>>
>      >   
>       ------------------------------------------------------------------------
>      >      >>>>
>      >      >>>>
>      >      >>>>
>      >      >>>> Sent from WeLink
>      >      >>>>
>      >      >>>> *发**件人： *Joel Halpern<[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      >>>> <mailto:[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>>>
>      >      >>>>
>      >      >>>> *收件人： *Tianran Zhou<[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      >>>> <mailto:[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>>>
>      >      >>>>
>      >      >>>> *抄送： *mpls<[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >     <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>>
>      >      >>>>
>      >      >>>> *主**题**： *Re: [mpls] Re: Working Group Last Call on
>     draft-
>      >     ietf-
>      >      >>>> mpls- mna-hdr (2nd WG call)
>      >      >>>>
>      >      >>>> *时间**： *2024-09-30 10:40:20
>      >      >>>>
>      >      >>>> Given that the PSD proposal on the table requires the
>     ISD draft,
>      >      >>>> and does not require any changes to the ISD draft, I do not
>      >      >>>> understand your comments.  You have said you do not
>     want any ISD
>      >      >>>> solution, and now you are suggesting we adopt a PSD
>     solution that
>      >      >>>> requires ISD?
>      >      >>>>
>      >      >>>> And it is not clear that we need a PSD solution at all.
>      >      >>>>
>      >      >>>> If we need a PSD solution, I expect with some
>     clarifications and
>      >      >>>> modifications the jags psd draft can serve as a basis
>     for further
>      >      >>>> work.  I would strongly prefer to get the ISD work
>     done.  Then we
>      >      >>>> can have the debate about whethere we need PSD, and
>     then discuss
>      >      >>>> what a solution should look like.
>      >      >>>>
>      >      >>>> Yours,
>      >      >>>>
>      >      >>>> Joel
>      >      >>>>
>      >      >>>> On 9/29/2024 10:16 PM, Tianran Zhou wrote:
>      >      >>>>
>      >      >>>>     Then why not adopting that PSD proposal as the base for
>      >      >>>> discussion?
>      >      >>>>     And find out how it will require the draft-ietf-
>     mpls-mna-hdr.
>      >      >>>>
>      >      >>>>     Best,
>      >      >>>>
>      >      >>>>     Tianran
>      >      >>>>
>      >      >>>>     *From:*Joel Halpern [mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      >>>>     <mailto:[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>>]
>      >      >>>>     *Sent:* Monday, September 30, 2024 9:43 AM
>      >      >>>>     *To:* Tianran Zhou <[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >      >>>>     <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >      >>>>     *Cc:* mpls <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >     <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >      >>>>     *Subject:* Re: [mpls] Re: Working Group Last Call on
>      >     draft-ietf-
>      >      >>>>     mpls-mna-hdr (2nd WG call)
>      >      >>>>
>      >      >>>>     So we should hold up the ISD draft for some proposal to
>      >      >>>> appear?  The
>      >      >>>>     one PSD proposal we have on the table does not
>     require any
>      >     changes
>      >      >>>>     to the mna-hdr ISD draft.    That seems to request
>      >     arbitrary delay
>      >      >>>>     from the WG without justification.
>      >      >>>>
>      >      >>>>     Yours,
>      >      >>>>
>      >      >>>>     Joel
>      >      >>>>
>      >      >>>>     On 9/29/2024 9:36 PM, Tianran Zhou wrote:
>      >      >>>>
>      >      >>>>         So the next step for the WG is to work out the
>     PSD and
>      >     see how
>      >      >>>>         ISD and PSD can complement and be compatible.
>      >      >>>>
>      >      >>>>         It’s not the time to finalize draft-ietf-mpls-
>     mna-hdr in
>      >      >>>> hurry.
>      >      >>>>
>      >      >>>>         Especially when there is no hands on
>     implementation.
>      >      >>>>
>      >      >>>>         Tianran
>      >      >>>>
>      >      >>>>         *From:*Joel Halpern [mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      >>>>         <mailto:[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>>]
>      >      >>>>         *Sent:* Monday, September 30, 2024 9:06 AM
>      >      >>>>         *To:* Tianran Zhou <[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >      >>>>         <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >      >>>>         *Cc:* mpls <[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
>      >     <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >      >>>>         *Subject:* Re: [mpls] Re: Working Group Last
>     Call on
>      >      >>>> draft-ietf-
>      >      >>>>         mpls-mna-hdr (2nd WG call)
>      >      >>>>
>      >      >>>>         If someone wants to put a proposal on the table for
>      >     PSD that
>      >      >>>>         does not require ISD, they can do so.  And the
>     WG can,
>      >     if the
>      >      >>>>         process moves that far, consider that solution.
>     But, by
>      >      >>>>         definition, if the solution does not use ISD
>     then it
>      >     has no
>      >      >>>>         impact on advancing the mna-hdr draft solution for
>      >     those cases
>      >      >>>>         which use ISD.  I still do not see the coupling
>     you are
>      >      >>>> asserting.
>      >      >>>>
>      >      >>>>         In particular, while the requirements permit such a
>      >     solution,
>      >      >>>>         they do not mandate it.  Since we do not even
>     have a
>      >     proposal
>      >      >>>>         for how to do PSD without ISD, it seems really
>      >     confusing to be
>      >      >>>>         objecting to advancing the mna-hdr draft on
>     such a basis.
>      >      >>>>
>      >      >>>>         Yours,
>      >      >>>>
>      >      >>>>         Joel
>      >      >>>>
>      >      >>>>         On 9/29/2024 8:43 PM, Tianran Zhou wrote:
>      >      >>>>
>      >      >>>>             Hi Greg,
>      >      >>>>
>      >      >>>>             Please see below:
>      >      >>>>
>      >      >>>>                 5.   Subject to the constraints in these
>      >      >>>> requirements, a
>      >      >>>>             Network
>      >      >>>>
>      >      >>>>                      Action solution MAY carry MNA
>     information
>      >      >>>> in-stack,
>      >      >>>>             post-stack,
>      >      >>>>
>      >      >>>>                      or both in-stack and post-stack.
>      >      >>>>
>      >      >>>>                 6.   Solution specifications MUST NOT
>     require an
>      >      >>>>             implementation to
>      >      >>>>
>      >      >>>>                      support in-stack ancillary data,
>     unless the
>      >      >>>>             implementation
>      >      >>>>
>      >      >>>>                      chooses to support an NA that uses
>     in-stack
>      >      >>>>             ancillary data.
>      >      >>>>
>      >      >>>>             Tianran
>      >      >>>>
>      >      >>>>             *From:*Greg Mirsky
>     [mailto:[e-mail] <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      >>>>             <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>>]
>      >      >>>>             *Sent:* Monday, September 30, 2024 8:24 AM
>      >      >>>>             *To:* Tianran Zhou <[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >      >>>>             <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >      >>>>             *Cc:* Tony Li <[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>>
>     <mailto:[e-mail] <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>>;
>      >      >>>>             Zafar Ali (zali) <[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>>
>     <mailto:[e-mail] <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>>;
>      >      >>>>             mpls <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >     <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>; mpls-chairs
>      >      >>>>             <[e-mail] <mailto:mpls-
>     [e-mail]> <mailto:mpls- <mailto:mpls->
>      > [e-mail] <mailto:[e-mail]>>> <mailto:mpls-
>     [e-mail] <mailto:[e-mail]> <mailto:mpls-
>     <mailto:mpls->
>      > [e-mail] <mailto:[e-mail]>>>;
>      >      >>>> draft-
>      >      >>>> [e-mail] <mailto:ietf-mpls-mna-
>     [e-mail]> <mailto:[e-mail] <mailto:ietf-mpls-
>     [e-mail]>>
>      >     <mailto:draft-ietf-mpls-mna- <mailto:draft-ietf-mpls-mna->
>     <mailto:draft-ietf-mpls-mna- <mailto:draft-ietf-mpls-mna->>
>      >      >>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      >      >>>>             *Subject:* Re: [mpls] Re: Working Group
>     Last Call on
>      >      >>>> draft-
>      >      >>>>             ietf-mpls-mna-hdr (2nd WG call)
>      >      >>>>
>      >      >>>>             Hi Tianran,
>      >      >>>>
>      >      >>>>             Please point me to the part of RFC 9613
>     <https://
>      >      >>>> http://datatracker.ietf.org/doc/rfc9613/" rel="noreferrer nofollow" target="_blank">datatracker.ietf.org/doc/rfc9613/ <http://
>     http://datatracker.ietf.org/doc/rfc9613/" rel="noreferrer nofollow" target="_blank">datatracker.ietf.org/doc/rfc9613/> <http://
>      > http://datatracker.ietf.org/doc/rfc9613/" rel="noreferrer nofollow" target="_blank">datatracker.ietf.org/doc/rfc9613/ <http://datatracker.ietf.org/" rel="noreferrer nofollow" target="_blank">http://datatracker.ietf.org/
>     doc/rfc9613/>>> that supports your
>      >      >>>> request.
>      >      >>>>
>      >      >>>>             Regards,
>      >      >>>>
>      >      >>>>             Greg
>      >      >>>>
>      >      >>>>             On Sun, Sep 29, 2024 at 4:44 PM Tianran Zhou
>      >      >>>>             <zhoutianran=[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >      >>>>             <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>>> wrote:
>      >      >>>>
>      >      >>>>                 The IPR poll for the two document did
>     not hit the
>      >      >>>> point.
>      >      >>>>
>      >      >>>>                 The point is how can the MNA mechanism
>     disable
>      >     the ISD
>      >      >>>>                 and use PSD only.
>      >      >>>>
>      >      >>>>                 The draft-ietf-mpls-mna-hdr need to
>     resolve this.
>      >      >>>>
>      >      >>>>                 Tianran
>      >      >>>>
>      >      >>>>                 *From:*Tony Li
>     [mailto:[e-mail] <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      >>>>                 <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>>] *On Behalf Of *Tony Li
>      >      >>>>                 *Sent:* Monday, September 30, 2024 12:13 AM
>      >      >>>>                 *To:* Zafar Ali (zali) <[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      >>>>                 <mailto:[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>>>
>      >      >>>>                 *Cc:* Tianran Zhou
>     <[e-mail] <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      >>>>                 <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>>>; Dongjie (Jimmy)
>      >      >>>>                 <[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>
>     <mailto:[e-mail] <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>>>;
>      >      >>>>                 Tarek Saad <[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      >>>>                 <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>>>;
>     mpls <[e-mail] <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      >>>>                 <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>>>; mpls-chairs
>     <mpls-
>      >      >>>> [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>> <mailto:mpls-
>     <mailto:mpls->
>      > [e-mail] <mailto:[e-mail]> <mailto:mpls-
>     [e-mail] <mailto:[e-mail]>>>>; draft-
>      >      >>>> [e-mail] <mailto:ietf-mpls-mna-
>     [e-mail]> <mailto:[e-mail] <mailto:ietf-mpls-
>     [e-mail]>>
>      >      >>>> <mailto:draft-ietf-mpls-mna- <mailto:draft-ietf-mpls-
>     mna-> <mailto:draft-ietf-mpls-mna- <mailto:draft-ietf-mpls-mna->>
>      >      >>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      >      >>>>                 *Subject:* Re: Working Group Last Call on
>      >     draft-ietf-
>      >      >>>>                 mpls-mna-hdr (2nd WG call)
>      >      >>>>
>      >      >>>>                 Hi Zafar,
>      >      >>>>
>      >      >>>>                     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”.
>      >      >>>>
>      >      >>>>                 That’s exactly what we’re doing. The
>     process
>      >     for doing
>      >      >>>>                 this begins with an IPR poll.
>      >      >>>>
>      >      >>>>                 Nic started the IPR poll on draft-mb-mpls-
>      >     ioam-dex and
>      >      >>>>                 draft-gandhi-mpls-ioam-dex on Sept 3.
>      >      >>>>
>      >      >>>> https://mailarchive.ietf.org/arch/msg/mpls/" rel="noreferrer nofollow" target="_blank">https://mailarchive.ietf.org/arch/msg/mpls/ <https://
>     http://mailarchive.ietf.org/arch/msg/mpls/" rel="noreferrer nofollow" target="_blank">mailarchive.ietf.org/arch/msg/mpls/> <https://
>      > http://mailarchive.ietf.org/arch/msg/mpls/" rel="noreferrer nofollow" target="_blank">mailarchive.ietf.org/arch/msg/mpls/ <http://mailarchive.ietf.org/" rel="noreferrer nofollow" target="_blank">http://mailarchive.ietf.org/
>     arch/msg/mpls/>>
>      >      >>>>                 XU3Ycij6Oq2kGWi14k3eXmpdQvM/ <https://
>      >      >>>> http://mailarchive.ietf.org/arch/msg/mpls/" rel="noreferrer nofollow" target="_blank">mailarchive.ietf.org/arch/msg/mpls/ <http://
>     http://mailarchive.ietf.org/arch/msg/mpls/" rel="noreferrer nofollow" target="_blank">mailarchive.ietf.org/arch/msg/mpls/> <http://
>      > http://mailarchive.ietf.org/arch/msg/mpls/" rel="noreferrer nofollow" target="_blank">mailarchive.ietf.org/arch/msg/mpls/ <http://mailarchive.ietf.org/" rel="noreferrer nofollow" target="_blank">http://mailarchive.ietf.org/
>     arch/msg/mpls/>>
>      >      >>>>                 XU3Ycij6Oq2kGWi14k3eXmpdQvM/>
>      >      >>>>
>      >      >>>> https://mailarchive.ietf.org/arch/msg/" rel="noreferrer nofollow" target="_blank">https://mailarchive.ietf.org/arch/msg/ <https://
>     http://mailarchive.ietf.org/arch/msg/" rel="noreferrer nofollow" target="_blank">mailarchive.ietf.org/arch/msg/> <https://
>      > http://mailarchive.ietf.org/arch/msg/" rel="noreferrer nofollow" target="_blank">mailarchive.ietf.org/arch/msg/ <http://mailarchive.ietf.org/arch/" rel="noreferrer nofollow" target="_blank">http://mailarchive.ietf.org/arch/
>     msg/>>
>      >      >>>>                 mpls/7NmJqyMHDairPxEn7PGxz99KNiI/ <https://
>      >      >>>> http://mailarchive.ietf.org/arch/msg/" rel="noreferrer nofollow" target="_blank">mailarchive.ietf.org/arch/msg/ <http://
>     http://mailarchive.ietf.org/arch/msg/" rel="noreferrer nofollow" target="_blank">mailarchive.ietf.org/arch/msg/> <http://mailarchive.ietf.org/" rel="noreferrer nofollow" target="_blank">http://mailarchive.ietf.org/
>     <http://mailarchive.ietf.org/" rel="noreferrer nofollow" target="_blank">http://mailarchive.ietf.org/>
>      >     arch/msg/>
>      >      >>>>                 mpls/7NmJqyMHDairPxEn7PGxz99KNiI/>
>      >      >>>>
>      >      >>>>                 Tony
>      >      >>>>
>      >      >>>> _______________________________________________
>      >      >>>>                 mpls mailing list -- [e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      >>>> <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >      >>>>                 To unsubscribe send an email to mpls-
>      > [e-mail] <mailto:[e-mail]> <mailto:mpls-
>     [e-mail] <mailto:[e-mail]>>
>      >      >>>>                 <mailto:[e-mail]
>     <mailto:[e-mail]> <mailto:mpls- <mailto:mpls->
>      > [e-mail] <mailto:[e-mail]>>>
>      >      >>>>
>      >      >>>>             _______________________________________________
>      >      >>>>
>      >      >>>>             mpls mailing list [e-mail]
>     <mailto:[e-mail]> <mailto:--
>      > [e-mail] <mailto:[e-mail]>> <mailto:[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
>      >      >>>>
>      >      >>>>             To unsubscribe send an email tompls-
>     [e-mail] <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      >>>> <mailto:[e-mail] <mailto:mpls-
>     [e-mail]> <mailto:[e-mail] <mailto:mpls-
>     [e-mail]>>>
>      >      >>>>
>      >      >>>>
>      >      >>>> _______________________________________________
>      >      >>>> mpls mailing list -- [e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>      >      >>>> To unsubscribe send an email to [e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      >>>
>      >      >
>      >
>      >     _______________________________________________
>      >     mpls mailing list -- [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >     To unsubscribe send an email to [e-mail]
>     <mailto:[e-mail]> <mailto:mpls- <mailto:mpls->
>      > [e-mail] <mailto:[e-mail]>>
>      >     _______________________________________________
>      >     mpls mailing list -- [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >     To unsubscribe send an email to [e-mail]
>     <mailto:[e-mail]> <mailto:mpls- <mailto:mpls->
>      > [e-mail] <mailto:[e-mail]>>
>      >     _______________________________________________
>      >     mpls mailing list -- [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >     To unsubscribe send an email to [e-mail]
>     <mailto:[e-mail]> <mailto:mpls- <mailto:mpls->
>      > [e-mail] <mailto:[e-mail]>>
>      >
>
>     --
>     Loa Andersson
>     Senior MPLS Expert
>     Bronze Dragon Consulting
>     [e-mail] <mailto:[e-mail]>
>     [e-mail] <mailto:[e-mail]>
>

--
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
[e-mail]
[e-mail]

_______________________________________________
mpls mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]