Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"
Gyan Mishra <hayabusagsm@gmail.com> Sat, 16 April 2022 22:37 UTC
Return-Path: <hayabusagsm@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8713A095C; Sat, 16 Apr 2022 15:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkcIqseCC0Yv; Sat, 16 Apr 2022 15:37:19 -0700 (PDT)
Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265F93A0B02; Sat, 16 Apr 2022 15:37:12 -0700 (PDT)
Received: by mail-pj1-x1035.google.com with SMTP id mp16-20020a17090b191000b001cb5efbcab6so14428030pjb.4; Sat, 16 Apr 2022 15:37:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FSzphdd0j3/XBX1+GsFFibbIR5+am/WIpKe2GjBG0kw=; b=h5jrpnyD/bByf1jCzrH/Fofpa8JzJG4OCZuJ1ZSHr1EBXIIMZMSqi3VwUryP1yu0Sc 8WdP9anfU9qMgWZkdBW7a2QejwM/RZ6W+VszpPFp0sHh4+rMOXP0pNjEVo3l+4P5osl6 +bVucMmaKR9e2KLV9tyZ6gHi+MC7G2AjDc70hQyd6v/UH8N1jpiO3A4qrUSbh5ITUzST 9QIr8NpMOxdC8L8LXn1Sq5kdrXhsR7ulBHkC0sAh4rwa+KDjBqFGsEZVna9nt2eAMYSR rkqC9z1rLhusGKAC1Nl9DbZ64iCpBXKDe5YAY6GddPNuZ4J8k7Ge7dsrMBmK9Y/ehC/y mKhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FSzphdd0j3/XBX1+GsFFibbIR5+am/WIpKe2GjBG0kw=; b=lMKbweHP3zwbEE2NRVHYDtzvdX7e4M1Iz2if/EeTMVGL9+or3XGafLDvi9FgyWoXNS aaKLu6qPZKk4AY6GN+kO0cM1mVNBRITsNkSsK2JrZ77rT6QEEIJ6U6Zf+nyCMC8WsXeO NRJBUBXixsKFRzxBftaGeJIYftrvI4LWSBeTozQ/2PdOmWpVp6OdZEEdHtSsSK606MtE E01GaVdZEVJLT4QSJXNi8x0cshqY5eKPP6VfuysGwsgR9KjqxhQnGn8j6n8qXE2TgrtX n5/tXL/6ByL8Z3xOAudJHfS0G7tYtfE7BzUvgW8URVR+SKcnfZO/EJ3ZiTgTegk9uprR 9ZEw==
X-Gm-Message-State: AOAM533lx3uo5NmQpdfAfdv7HWmOqHXovK/3D5ISG28XLS7EnbhXj2qE dDlCqZiL3bRRBV5U7Yh+tVNyNwLmZaeiaP/DG3ZXpHPB
X-Google-Smtp-Source: ABdhPJz3uYg1BlaggEMcqJi59dI/7NQkAjdBvh6RsGyHDdiddZkPnXEujjWc+0RQGlNac2+HhzQ0VG9rnq3d0S0UO6o=
X-Received: by 2002:a17:902:7789:b0:156:8b5c:606f with SMTP id o9-20020a170902778900b001568b5c606fmr4871011pll.100.1650148630940; Sat, 16 Apr 2022 15:37:10 -0700 (PDT)
MIME-Version: 1.0
References: <CAH6gdPyXbPh0=k6KvZJyzyvapBrjjkby50MbmGNQOAG1GDX1OA@mail.gmail.com> <3FA9B00A-864D-464A-8BA5-368C1EDAC580@gmail.com> <CAH6gdPzQmuZAFvnDoUqH6ENNd5qCjLpgHidDhZ-etMt=Y5pqXw@mail.gmail.com> <CABNhwV0hYRNzsvkbomzobGG79z738cv2J39Wx_tG55nL6QAfxA@mail.gmail.com> <1DCB8FC1-E5AB-4629-9CF3-BA0EF9EFEC72@cisco.com>
In-Reply-To: <1DCB8FC1-E5AB-4629-9CF3-BA0EF9EFEC72@cisco.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sat, 16 Apr 2022 18:36:57 -0400
Message-ID: <CABNhwV0AaR8PW=oMX_A+PTzHp5aGQzi11EV=x3d1qPvb6=j-bg@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: Ketan Talaulikar <ketant.ietf@gmail.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "draft-ietf-lsr-ip-flexalgo@ietf.org" <draft-ietf-lsr-ip-flexalgo@ietf.org>, lsr <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f9505905dccd2afb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/S5Mgke-UzsOd84m_XedqBz66JMg>
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Apr 2022 22:37:28 -0000
Hi Acee Responses in-line On Sat, Apr 16, 2022 at 5:53 PM Acee Lindem (acee) <acee@cisco.com> wrote: > Again, speaking as WG member: > > Hi Gyan, Ketan, > > I agree since for the IGPs we’ve traditionally used “application” for > control plane routing applications (shortest-path, RSVP TE, SR, etc.). I > know Robert suggested “logical data plane”… What are the thoughts on this? > > Gyan> I read through the comments on the thread related to ASLA and > confusion with the word application defining a data plane which I and I > think most in the WG agree the term application being applied to a data > plane is no doubt confusing. > I am good with “logical data plane”. Data plane instance, identifier, slice or transport would work as well. > > > Thanks, > Acee > > > > *From: *Gyan Mishra <hayabusagsm@gmail.com> > *Date: *Saturday, April 16, 2022 at 11:46 AM > *To: *Ketan Talaulikar <ketant.ietf@gmail.com> > *Cc: *Acee Lindem <acee@cisco.com>, "Peter Psenak (ppsenak)" < > ppsenak@cisco.com>, "draft-ietf-lsr-ip-flexalgo@ietf.org" < > draft-ietf-lsr-ip-flexalgo@ietf.org>, lsr <lsr@ietf.org> > *Subject: *Re: [Lsr] Working Group Last Call for > draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) > In IP Networks" > > > > Thank you Ketan. > > > > Ack on convergence on new term for application.😃 > > > > Thanks > > > > Gyan > > > > On Sat, Apr 16, 2022 at 10:01 AM Ketan Talaulikar <ketant.ietf@gmail.com> > wrote: > > Hi Gyan, > > > > Your proposal looks ok to me. Note though that we seem to be converging > towards using an alternate term instead of "application" in this context. > > > > Thanks, > > Ketan > > > > > > On Sat, Apr 16, 2022 at 12:50 PM Gyan Mishra <hayabusagsm@gmail.com> > wrote: > > > > Hi Ketan > > > > My understanding was that IGP Flex Algo could only be used with SR-MPLS or > SRv6 data plane using prefix SID or SRv6 locator to steer packets. > > > > So it was my understanding that the IP Flex Algo draft was providing a > solution for IP based networks ( Non SR-MPLS or SRv6) networks which was > valuable gap to be filled. > > > > However your editorial comments shed some light that IGP Flex Algo may be > used in IP based ( Non SR-MPLD or SRv6) based networks. This is confusing > to me however below paragraph makes it more clear to me as to why you > stated IGP Flex Algo is open to beyond SR ( even though not yet developed). > > > > IGP Flex Algo draft Section 14 describes forwarding plane use cases for > Flex Algo which are SR-MPLS and SRv6 and 14.3 mentions that any application > that wants to use Flex Algo can use it but that application needs to be > developed to install the Flex Algo entires into the forwarding plane such > as for RSVP-TE or native IPv4 or IPv6 forwarding plane. > > > > I think if IGP Flex Algo was developed as part of the draft to support > other applications such as RSVP-TE and native IPv4 or IPv6 forwarding plane > I think we could say that IGP Flex Algo can be used outside of SR data > plane but that development has not been done even though it maybe possible > in the future once developed or it may never be developed based on industry > demand. So I think it’s safe to say at this time IGP Flex Algo only > supports SR-MPLS and SRv6 forwarding planes only. However now once IP Flex > Algo is published and implemented we can safely say that it has been > extended beyond SR data plane. > > > > I would change the verbiage slightly to make it more clear. You mention > that the IGP Flex Algo draft is the base Flex Algo draft but I disagree as > if it were then the IP Flex Algo draft or any other application of Flex > Algo with a new data plane would be an update to the base Flex Algo draft > but here in this case I don’t think so and even for any other application. > Each data plane instance of Flex Algo starting with the IP Flex Algo draft > and then maybe future RSVP Flex Algo draft would be their own independent > “base” Flex Algo draft onto themselves. That is one option, to keep each > data plane specification of Flex Algo independent specifications. > > > > If we think that IP Flex Algo and future data plane applications such as > RSVP-TE and beyond will be extensions of the IGP Base specification, so > then will be updates to the base specification, then I think we can call IP > Flex Algo an extension to the base specification. > > > > This is what I think the verbiage should state which is a hybrid of yours > and Peter’s verbiage. > > > > This is if each application is standalone per data plane and is not an > extension and so IGP Flex Algo would not be a base specification. > > > > NEW > > > > > An IGP Flexible Algorithm (Flex-Algorithm) allows the IGP to compute > > constraint-based paths. The IGP Flex-Algorithm specification > > currently only supports the application Segment Routing with (SR) > data planes - SR MPLS and > > SRv6. > > > > This document specifies IGP Flex-Algorithm, so that it can be used > in any IP network > > for native IPv4 and IPv6 forwarding in the absence of SR. > > > > > > Verbiage if IGP Flex Algo is a base and this draft is an extension and > updates the base. We don’t have to say IGP Flex Algo currently only > supports dropping the word currently as we are now extending with IP Flex > Algo. > > > > > NEW > > > > An IGP Flexible Algorithm (Flex-Algorithm) allows the IGP to compute > > constraint-based paths. The base IGP Flex-Algorithm specification > only supports the application Segment Routing with (SR) data planes - SR > MPLS and SRv6. > > > > This document extends IGP Flex-Algorithm, so that it can be used > > natively with IPv4 and IPv6 forwarding. > > > > > > > > > > Kind Regards > > > > Gyan > > > > Sent from my iPhone > > > > On Apr 16, 2022, at 12:21 AM, Ketan Talaulikar <ketant.ietf@gmail.com> > wrote: > > Hi Gyan, > > > > I am not sure what the confusion is here. The following is how Peter and I > concluded this point. My comment was of editorial nature. > > > > Thanks, > > Ketan > > > > > > 3) This draft makes assertions that IGP FlexAlgo cannot be > deployed > > > without SR. This is not true since the base IGP FlexAlgo spec > > explicitly > > > opens it up for usage outside of the SR forwarding plane. We > already > > > have BIER and MLDP forwarding planes as users of the IGP > > FlexAlgo. My > > > suggestion is to remove such assertions from the document. It is > > > sufficient to just say that the document enables the use of IGP > > FlexAlgo > > > for IP prefixes with native IP forwarding. > > > > ##PP > > where do you see such assertion? Each flex-algo data-plane/app can be > > deployed independently. > > > > > > KT> Let me clarify what I meant by taking the example of the abstract. > > > > OLD > > > > An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute > > constraint-based paths. As currently defined, IGP Flex-Algorithm is > > used with Segment Routing (SR) data planes - SR MPLS and SRv6. > > Therefore, Flex-Algorithm cannot be deployed in the absence of SR. > > > > This document extends IGP Flex-Algorithm, so that it can be used for > > regular IPv4 and IPv6 prefixes. This allows Flex-Algorithm to be > > deployed in any IP network, even in the absence of SR. > > > > > > NEW > > > > An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute > > constraint-based paths. The base IGP Flex-Algorithm document > > specified use with Segment Routing (SR) data planes - SR MPLS and > > SRv6. > > > > This document extends IGP Flex-Algorithm, so that it can be used with > > regular IPv4 and IPv6 forwarding. > > ##PP2 > ok > > > > On Sat, Apr 16, 2022 at 8:07 AM Gyan Mishra <hayabusagsm@gmail.com> wrote: > > > > Hi Acee > > > > Fixing a typo > > > > On Fri, Apr 15, 2022 at 10:34 PM Gyan Mishra <hayabusagsm@gmail.com> > wrote: > > > > Hi Acee > > > > My question cane up from the list of questions posed by Ketan and Peter’s > response to question #3. > > > > See excerpt below. > > > > I am confused by what Ketan stated in his question below and also Peter’s > response which is why I am asking the question again. > > > > I believe the goal of the draft is for Flex Ago to be deployed > independently of SR filling the gap of IGP Flex Algo providing that > solution. So based on what Ketan stated in his question that IGP Flex Algo > is data plane agnostic and can be used with IP data plane then there is no > gap to be filled by this draft. > > > > Maybe I am misreading Ketan’s question. > > > > So this is a very important point made by Ketan that if IGP Flex Algo is > open to usage “outside of SR”, then it is very important to restate the > goal of this draft, removing assertions in the draft that this draft is for > non SR IP data planes, as that can be accomplished today by IGP Flex Algo, > and the gap or new solution being filled by this draft is for IP prefix > based Flex Algo with Native IP Forwarding. > > > > This as well is quite confusing to me as if IGP Flex Algo can be used > outside of SR then can do everything that this draft is supposed to > accomplish. > > > > So what then is the purpose of this draft? > > > > In Peter’s response is stated that each Flex Algo data plane / app can be > deployed independently meaning this draft and IGP flex Algo can act as 2 > ships in the night. Also confusing. > > > > 3) This draft makes assertions that IGP FlexAlgo cannot be deployed > > without SR. This is not true since the base IGP FlexAlgo spec explicitly > > opens it up for usage outside of the SR forwarding plane. We already > > have BIER and MLDP forwarding planes as users of the IGP FlexAlgo. My > > suggestion is to remove such assertions from the document. It is > > sufficient to just say that the document enables the use of IGP FlexAlgo > > for IP prefixes with native IP forwarding. > > ##PP > where do you see such assertion? Each flex-algo data-plane/app can be > deployed independently. > > > > > > > > On Fri, Apr 15, 2022 at 7:51 PM Acee Lindem (acee) <acee@cisco.com> wrote: > > Gyan, > > > > What is your point here? Is this a trick question? > > > > Thanks, > > Acee > > > > *From: *Gyan Mishra <hayabusagsm@gmail.com> > *Date: *Friday, April 15, 2022 at 5:31 PM > *To: *"Peter Psenak (ppsenak)" <ppsenak@cisco.com> > *Cc: *Acee Lindem <acee@cisco.com>, Ketan Talaulikar < > ketant.ietf@gmail.com>, "draft-ietf-lsr-ip-flexalgo@ietf.org" < > draft-ietf-lsr-ip-flexalgo@ietf.org>, "lsr@ietf.org" <lsr@ietf.org> > *Subject: *Re: [Lsr] Working Group Last Call for > draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) > In IP Networks" > > > > > > Hi Peter > > > > My understanding is that the main goal of this draft is to be able to use > flex algo over IPv4 or IPv6 data plane as that is not possible with > existing Flex Algo which can only be used on SR data plane. > > > > Is that correct or am I missing something? > > > > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo > > > > > > Abstract > > > > An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute > > constraint-based paths. As currently defined, IGP Flex-Algorithm is > > used with Segment Routing (SR) data planes - SR MPLS and SRv6. > > Therefore, Flex-Algorithm cannot be deployed in the absence of SR. > > > > This document extends IGP Flex-Algorithm, so that it can be used for > > regular IPv4 and IPv6 prefixes. This allows Flex-Algorithm to be > > deployed in any IP network, even in the absence of SR. > > > > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-19 > > > > Abstract > > > > IGP protocols traditionally compute best paths over the network based > > on the IGP metric assigned to the links. Many network deployments > > use RSVP-TE based or Segment Routing based Traffic Engineering to > > steer traffic over a path that is computed using different metrics or > > constraints than the shortest IGP path. This document proposes a > > solution that allows IGPs themselves to compute constraint-based > > paths over the network. This document also specifies a way of using > > Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets > > along the constraint-based paths. > > > > Kind Regards > > > > Gyan > > > > > > -- > > [image: Image removed by sender.] <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* > > *M 301 502-1347* > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* *M 301 502-1347*
- [Lsr] Working Group Last Call for draft-ietf-lsr-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Robert Raszuk
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Robert Raszuk
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Huzhibo
- Re: [Lsr] Working Group Last Call for draft-ietf-… Robert Raszuk
- Re: [Lsr] Working Group Last Call for draft-ietf-… John E Drake
- Re: [Lsr] Working Group Last Call for draft-ietf-… Robert Raszuk
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ron Bonica
- Re: [Lsr] Working Group Last Call for draft-ietf-… Dongjie (Jimmy)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Dongjie (Jimmy)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Les Ginsberg (ginsberg)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Les Ginsberg (ginsberg)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Parag Kaneriya
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- [Lsr] [Need AD’s Judgement and Explanation] Re: W… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Acee Lindem (acee)
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… John Scudder
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Acee Lindem (acee)
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Peter Psenak
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Acee Lindem (acee)
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Peter Psenak
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Peter Psenak
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Peter Psenak
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Acee Lindem (acee)
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… John E Drake
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang