Re: [mpls] draft-ietf-mpls-mna-hdr ready to start the WGLC process
"jmh.direct" <jmh.direct@joelhalpern.com> Fri, 04 August 2023 23:38 UTC
Return-Path: <jmh.direct@joelhalpern.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0440BC15108D for <mpls@ietfa.amsl.com>; Fri, 4 Aug 2023 16:38:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.804
X-Spam-Level:
X-Spam-Status: No, score=-2.804 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSXw8OsL-sE4 for <mpls@ietfa.amsl.com>; Fri, 4 Aug 2023 16:38:14 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C73C151088 for <mpls@ietf.org>; Fri, 4 Aug 2023 16:38:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4RHhwk39RTz1ntww; Fri, 4 Aug 2023 16:38:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1691192294; bh=pBQNf+oF47+dKs7fn8BXLtMi0Gi2YdpgO1JFe0ZsnaE=; h=Date:Subject:In-Reply-To:From:To:Cc:From; b=kQS2LZRKY4bXqZpjtZEqlPSzkOn7PMR0R+1e/YIj18u51cM6PX5go+7hOkVIL40aG qVE+PvPtgreR31oiroSScd0dZuWEL6KKvErm9wXAuWaWsjRuwr8mzYNty3dt1WFKo4 Oz1O/T5MLmtROE/XgiAcW/hKZr1V0HhwKrBRvIio=
X-Quarantine-ID: <BQuEqWMOn9tk>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [IPv6:2600:381:ce01:a97e:8991:caa6:b47c:dd48] (unknown [IPv6:2600:381:ce01:a97e:8991:caa6:b47c:dd48]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4RHhwd37Xkz1nsGP; Fri, 4 Aug 2023 16:38:08 -0700 (PDT)
SavedFromEmail: jmh.direct@joelhalpern.com
Date: Fri, 04 Aug 2023 19:38:06 -0400
In-Reply-To: <E5EE8BA8-EFEC-49C8-92D8-49B3C5FAFC09@tony.li>
Importance: normal
From: "jmh.direct" <jmh.direct@joelhalpern.com>
To: Tony Li <tony.li@tony.li>, "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Haoyu Song <haoyu.song@futurewei.com>, "mpls@ietf.org" <mpls@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_1761380867570780"
Message-Id: <4RHhwd37Xkz1nsGP@mailb2.tigertech.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/Nydr4f5726bH_TanmZkMd8hZgBA>
Subject: Re: [mpls] draft-ietf-mpls-mna-hdr ready to start the WGLC process
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Aug 2023 23:38:19 -0000
Thanks. Sounds good to me.Yours,JoelSent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone -------- Original message --------From: Tony Li <tony.li@tony.li> Date: 8/4/23 7:31 PM (GMT-05:00) To: "Joel M. Halpern" <jmh@joelhalpern.com> Cc: Haoyu Song <haoyu.song@futurewei.com>, mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-mna-hdr ready to start the WGLC process Side nit: The acronym MSD is already taken by “Maximum SID Depth”, which has slightly different semantics.We already have another appropriate term defined, Entropy Readable Label Depth (ERLD) which actually has the semantics that we’re after, tho of course, we are not concerned just with Entropy.I would like to propose that we define Readable Label Depth (RLD) to be a synonym for ERLD, retroactively, and use that term hereafter.TonyOn Aug 4, 2023, at 2:26 PM, Joel Halpern <jmh@joelhalpern.com> wrote: The working group has so far been clear that maximum visible stack depth (MSD) matters. If the WG changes that view, then various things are possible. As long as we take that view, having multiple occurrences of ISD is necessary. Yours,Joel On 8/4/2023 5:17 PM, Haoyu Song wrote: @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;}@font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face {font-family:"\@SimSun"; panose-1:2 1 6 0 3 1 1 1 1 1;}p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; font-size:11.0pt; font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;}span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri",sans-serif; color:windowtext;}.MsoChpDefault {mso-style-type:export-only; font-size:10.0pt; font-family:"Calibri",sans-serif; mso-ligatures:none;}div.WordSection1 {page:WordSection1;} Hi Greg,Thanks for the explanation, although I think my point is perfectly technical and specific.We are designing a protocol for dataplane. Therefore I think the simplicity and correctness considerations are critical. The procedure described by Joel does bind to an implementation and deployment scenario with the implication of multiple NAS copies in the stack. If we assume to support only a single NAS, the procedure could be quite different, which also needs to be documented. If we reject such an idea, we need specific technical reasons. Best,Haoyu From: Greg Mirsky <gregimirsky@gmail.com> Sent: Friday, August 4, 2023 1:54 PM To: Haoyu Song <haoyu.song@futurewei.com> Cc: Tony Li <tony.li@tony.li>; jmh.direct <jmh.direct@joelhalpern.com>; Joel M. Halpern <jmh@joelhalpern.com>; Stewart Bryant <stewart.bryant@gmail.com>; mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-mna-hdr ready to start the WGLC process Of course. You've said: My gut feeling is that maintaining a single NAS requires fewer lines of dataplane processing code. It also keeps the header overhead minimum which can potentially avoid other troubles such as MTU limitation. So I suggest we actually do such evaluations before deciding the final scheme. You, as a seasoned developer, may decide to allow only a single NAS in the stack, while other implementors may decide differently. But, in my opinion, the architecture and the solution MUST NOT preclude any of such decisions (and it doesn't, AFAICS). And consideration of the Path MTU before pushing a new NAS onto a packet is, in my opinion, a common practice (at least it should be), not specific to MNA. Hence my invitation to you, please separate implementation and deployment issues from what really impacts the MNA architecture and solution. I hope that my position is clearer to you now. Regards, Greg On Fri, Aug 4, 2023 at 1:42 PM Haoyu Song <haoyu.song@futurewei.com> wrote: Greg, Please be specific which of my comment is not technical and specific? Best,Haoyu From: Greg Mirsky <gregimirsky@gmail.com> Sent: Friday, August 4, 2023 1:38 PM To: Haoyu Song <haoyu.song@futurewei.com> Cc: Tony Li <tony.li@tony.li>; jmh.direct <jmh.direct@joelhalpern.com>; Joel M. Halpern <jmh@joelhalpern.com>; Stewart Bryant <stewart.bryant@gmail.com>; mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-mna-hdr ready to start the WGLC process Hi Haoyu, I consider the questions you brought up, the number of NASes allowed in the stack and MNA impact on MTU, to be implementation-related and operational, which, in my opinion, should have no impact on the ISD MNA solution. Hence, let us be constructive and concentrate on the questions as formulated in the original email Before we ask for the RTG Dir review we'd like to ask the authors if there are any further changes or updates that they want to do prior to starting the WGLC process? Joel provided the authors with the text addressing scenario that, as I understand, we had agreed requires explicit discussion in the draft-ietf-mpls-mna-hdr. Do you have an additional issue that must be resolved before the document is moved further in the process? I would appreciate it if your comments were technical and specific. Regards, Greg On Fri, Aug 4, 2023 at 11:23 AM Haoyu Song <haoyu.song@futurewei.com> wrote: I don’t quite understand the point. May need more explanations. I have a more general related question: Is only the LER allowed to push NAS or any LSR can push NAS as well? Regarding to the complication, we’d better have some objective method to evaluate it. My gut feeling is that maintaining a single NAS requires fewer lines of dataplane processing code. It also keeps the header overhead minimum which can potentially avoid other troubles such as MTU limitation. So I suggest we actually do such evaluations before deciding the final scheme. Best regards,Haoyu From: Tony Li <tony1athome@gmail.com> On Behalf Of Tony Li Sent: Thursday, August 3, 2023 4:18 PM To: jmh.direct <jmh.direct@joelhalpern.com> Cc: Haoyu Song <haoyu.song@futurewei.com>; Joel M. Halpern <jmh@joelhalpern.com>; Greg Mirsky <gregimirsky@gmail.com>; Stewart Bryant <stewart.bryant@gmail.com>; mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-mna-hdr ready to start the WGLC process It’s more complicated and it breaks some functional aspects that we have now. Suppose that the node pushing a NAS wants it to have a bounded lifetime. By placing the NAS (and any copies) judiciously, it can limit the effect of the NAS a portion of the path. If a NAS self-replicates, then this capability would be lost. Tony On Aug 3, 2023, at 3:54 PM, jmh.direct <jmh.direct@joelhalpern.com> wrote: That is an alternative solution. It seems more complicated to me. Yours, Joel Sent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone -------- Original message -------- From: Haoyu Song <haoyu.song@futurewei.com> Date: 8/3/23 6:41 PM (GMT-05:00) To: Tony Li <tony.li@tony.li>, "Joel M. Halpern" <jmh@joelhalpern.com> Cc: Greg Mirsky <gregimirsky@gmail.com>, Stewart Bryant <stewart.bryant@gmail.com>, mpls@ietf.org Subject: RE: [mpls] draft-ietf-mpls-mna-hdr ready to start the WGLC process Then we may consider to ban the possibility of having multiple NAS replications in the stack. There will be only one and if it emerges at the top, the node must be responsible to re-push it to a proper depth. This can avoid many troubles. Haoyu From: Tony Li <tony1athome@gmail.com> On Behalf Of Tony Li Sent: Thursday, August 3, 2023 3:23 PM To: Joel M. Halpern <jmh@joelhalpern.com> Cc: Haoyu Song <haoyu.song@futurewei.com>; Greg Mirsky <gregimirsky@gmail.com>; Stewart Bryant <stewart.bryant@gmail.com>; mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-mna-hdr ready to start the WGLC process It would seem that the reasonable answer is for the node pushing the NAS to understand the MSD and do the math. This should not be hard. The rule should be simple: the NAS should fit, in its entirety, within the MSD. Now, you’re going to immediately say: what if it doesn’t? Well, as we’ve just said: there will always be limitations. If you have a 64 byte MSD, then you probably shouldn’t be trying to use a 64 byte NAS. There’s just not much that we can do about that. Tony On Aug 3, 2023, at 1:51 PM, Joel Halpern <jmh@joelhalpern.com> wrote: A reasonable question, separate from the problem I am trying to fix.Yours,Joel On 8/3/2023 4:48 PM, Haoyu Song wrote: For the second question, I’m asking if the MNA substack must be considered as a whole or it can be partially used. Let’s say the stack contains x actions with the depth of y. If only x’ action with the depth of y’ are visible, is that okay to only execute these and ignore the others? If so, we will have a lot of consistency troubles. So the best way is to avoid this and ensure every MNA-aware node to be able to see the entire substack. Then what’s the procedure and actual limitation of the substack size (plus the forwarding labels in front of it)? Must the node behavior of the entire network be deterministic to be able to correctly use it? We’d better have clear answer to all these questions before we move forward. Haoyu From: Greg Mirsky <gregimirsky@gmail.com> Sent: Thursday, August 3, 2023 1:14 PM To: Haoyu Song <haoyu.song@futurewei.com> Cc: Stewart Bryant <stewart.bryant@gmail.com>; Tony Li <tony.li@tony.li>; Joel Halpern <jmh@joelhalpern.com>; mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-mna-hdr ready to start the WGLC process Hi Haoyu, I agree with Joel, that the question you are asking is likely to be addressed as part of operational procedures. I can imagine that MNA be deployed in an SDN paradigm and that would allow for better control of paths that MNA-equipped packets take, for a more predictable actions node apply to such packets. For your second question, I assume that you refer to a situation when ISD MNA doesn't fit entirely into a cash memory of a particular node. Is that, in your opinion, a result of not accurate MSD advertisement or a mistake in constructing the label stack and placing ISD MNA? Regards, Greg On Thu, Aug 3, 2023 at 12:03 PM Haoyu Song <haoyu.song@futurewei.com> wrote: I have more questions. If we think of a network with mixed MNA-aware and MAN-unaware nodes, the situation becomes more complicated. The MAN-unaware node may push new labels into the stack which inadvertently push the existing MNA substack out of reach for the MNA-aware node and effectively make them "unaware" of the existing MNA. How to deal with this? Another question: it that okay if a node can only reach a part of the MNA substack (i.e., a part of the substack is out of reach)? Best, Haoyu -----Original Message----- From: mpls <mpls-bounces@ietf.org> On Behalf Of Stewart Bryant Sent: Thursday, August 3, 2023 2:03 AM To: Tony Li <tony.li@tony.li>; Joel Halpern <jmh@joelhalpern.com> Cc: mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-mna-hdr ready to start the WGLC process I can see that if a node is going to push some labels it has to bring the MNH into view for other nodes along the subpath it is adding. Is that dept a network wide parameter with a single value or a path parameter and if the path changes for any reason (perhaps in a legacy node doing FRR) what is the procedure? Now eventually the stack gets popped. Is the procedure to copy the MNH in its entirety to overwrite the old MNH instance? Are there any exceptions to this? Is there a risk that the popping node cannot see far enough into the stack to find the new MNH? - Stewart > On 1 Aug 2023, at 19:14, Tony Li <tony.li@tony.li> wrote: > > > >> As far as I know, there is no text in the draft yet to deal with preserving access to hop-by-hop MNA when MNA-capable nodes add entries to the label stack. And there is not yet WG agreement on the approach to be used, so I have some difficulty proposing text. > > > I thought that we had agreement: > > If the node is pushing enough labels that the hbh NAS would be below the window, then the node needs to copy the NAS into the window. > > If the node is modifying the NAS, then it needs to make its modifications and then do the above. > > T > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________mpls mailing listmpls@ietf.orghttps://www.ietf.org/mailman/listinfo/mpls
- [mpls] draft-ietf-mpls-mna-hdr ready to start the… Loa Andersson
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Joel Halpern
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Tony Li
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Joel Halpern
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… John E Drake
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Loa Andersson
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Tony Li
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Joel Halpern
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Dongjie (Jimmy)
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Stewart Bryant
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Andrew G. Malis
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Joel Halpern
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Haoyu Song
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Joel Halpern
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Greg Mirsky
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Haoyu Song
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Joel Halpern
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Tony Li
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… jmh.direct
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Greg Mirsky
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Haoyu Song
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… jmh.direct
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Greg Mirsky
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Tony Li
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Dongjie (Jimmy)
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Tony Li
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Dongjie (Jimmy)
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Haoyu Song
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Joel Halpern
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Greg Mirsky
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Joel Halpern
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Haoyu Song
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Greg Mirsky
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Haoyu Song
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Haoyu Song
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Haoyu Song
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Greg Mirsky
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Joel Halpern
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Joel Halpern
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Tony Li
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… jmh.direct
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Tony Li
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Haoyu Song
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Tony Li
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Haoyu Song
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Tony Li
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Haoyu Song
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Haoyu Song
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Joel Halpern
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Tony Li
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Joel Halpern
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Haoyu Song
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Tony Li
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Greg Mirsky
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Greg Mirsky
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Jeff Tantsura
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Tony Li
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Dongjie (Jimmy)
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… liu.yao71
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Dongjie (Jimmy)
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Joel Halpern
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Tony Li
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Haoyu Song
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Haoyu Song
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Greg Mirsky
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Joel Halpern
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Greg Mirsky
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Tony Li
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Haoyu Song
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Greg Mirsky
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Greg Mirsky
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Dongjie (Jimmy)
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Dongjie (Jimmy)
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Greg Mirsky
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Joel Halpern
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Joel Halpern
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… John E Drake
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Greg Mirsky
- Re: [mpls] draft-ietf-mpls-mna-hdr ready to start… Greg Mirsky