Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Gyan Mishra <hayabusagsm@gmail.com> Sat, 03 October 2020 17:45 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 1071E3A0C9A for <lsr@ietfa.amsl.com>; Sat, 3 Oct 2020 10:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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 PP_RXB0WRsB9 for <lsr@ietfa.amsl.com>; Sat, 3 Oct 2020 10:45:52 -0700 (PDT)
Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 057993A0C94 for <lsr@ietf.org>; Sat, 3 Oct 2020 10:45:52 -0700 (PDT)
Received: by mail-vs1-xe2d.google.com with SMTP id e62so2077548vsc.10 for <lsr@ietf.org>; Sat, 03 Oct 2020 10:45:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RmfKJVlLh/c3051kmiG2P+vN96RYV4AvRw/6eJpbYKU=; b=KpbZukmgXbUCL59ZGJWGZ6hoMvW/4sbuFDlv4BnrEqKx+NusIF5+9VLmV4/dIoI4SH qR6TFCu1R7dbjUA5O6ODMZGriKoXnDXAGEMclKlNuNGRl+1yzFFV8rSrdPfOEcHEiFid mLNJS31nx+vp8bx5aRkHo+5ihfX4H4xqG/66wnqGs6KSITjMlzuWjtCX6NWjGOFVU5r+ xgzUsjdVTvkvuxPhj5X3EfkTxuPv+XRWhYoPT2tBeyqCb3zTVDM9kGtn6/bXZMMcDzsp VDMdl7w2NZdT2qp5dJ1ooE1B65UH3DEVfxNVvAg+hEma984fNQWapVt2O7VzERRbmWrR AGeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RmfKJVlLh/c3051kmiG2P+vN96RYV4AvRw/6eJpbYKU=; b=sIebeJiphCojKUTC6OvwU9Ab7rPM59jVC/bHZ8GKOJkhVdCFzyAM96Tyoc2CaDrrvb xNhrfb6EEiS6fEl1wheBZDvLaiIRd1+qwyv97lM/yk2s9FYh5FYjSKAM+QEhEkFmXfIu N27pN+pPA/CxjcblX6X4f8gMzW5T6volwgs+GjxPofF/hlBF6mkdEoLSXb2Y24iTmeug NdAbVNBzlkq/JjzG1J7fo/GJ8CiMd7QG4jQYGGhXodJQ5sbJm2nhNBalxeDAsuussy22 FSkKSSJaWI+dmlJrNUuLheBvxjI7Pe/qLT8+jmBPsibpALZ1Gx4oCLQJsRfIKw6c8gSC ZLUw==
X-Gm-Message-State: AOAM532Zob6wxC+7+A0xwOuvhtMEqeLPQbNAAL69864nph9PqtpjY0Hl oggvSA5ZrYSwj2QwU0tS3VFv3uSYDFPkyoRcvSc=
X-Google-Smtp-Source: ABdhPJzTkPmjFFQrhIbL3CE+QPVD5HvYlMT6GbnV99TsB+l150Ki2hrcCl7uMaS7C8PX1eCH0buAH75DOqkiGdlpRbY=
X-Received: by 2002:a67:e248:: with SMTP id w8mr3982491vse.33.1601747150984; Sat, 03 Oct 2020 10:45:50 -0700 (PDT)
MIME-Version: 1.0
References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <DM6PR05MB63482DBC001DD56BEF6F7311AE320@DM6PR05MB6348.namprd05.prod.outlook.com> <CAKz0y8w5VOf_=baG6UCP8Q9s=VLM2ghT2jhiF5FZNN4JXB23eA@mail.gmail.com> <DM6PR05MB63485389C261CA2E0C08DE50AE330@DM6PR05MB6348.namprd05.prod.outlook.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <DM6PR05MB63480E863599BBC810BF334AAE300@DM6PR05MB6348.namprd05.prod.outlook.com> <CABNhwV2+jhjAfxq5FzaukdhCOqXvGCkv75xYWcStN=SCrpni4Q@mail.gmail.com> <f4fdff8b-fe11-cb75-3cd7-7766baedf730@cisco.com> <CB2F6A55-B231-4A2D-821C-D3F2ABE6649E@futurewei.com> <cfae6af4-23d0-44b0-8bb3-f5e631b4c805@Spark> <CABNhwV3MmJeVMhGHqyGzwshSYVijquGsxaNFaryu5mF3j8n_zA@mail.gmail.com> <047be764-8203-ca46-7ee1-6f84f7bf2356@cisco.com> <CABNhwV3MMpMBQL_PXVFmX3RMkKXJVV0PTn4PvB0ctyHfRAMbuA@mail.gmail.com>
In-Reply-To: <CABNhwV3MMpMBQL_PXVFmX3RMkKXJVV0PTn4PvB0ctyHfRAMbuA@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sat, 03 Oct 2020 13:25:51 -0400
Message-ID: <CABNhwV2aoxyp=P6VG8JbH+zn3NDGUMQLE5dOx2RVKy3xghOy7Q@mail.gmail.com>
To: Peter Psenak <ppsenak@cisco.com>
Cc: Jeff Tantsura <jefftant.ietf@gmail.com>, Ron Bonica <rbonica@juniper.net>, Yingzhen Qu <yingzhen.qu@futurewei.com>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f4577f05b0c7d162"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/zGoP-8hLbrUzdaZq-mBKvn18gpo>
Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
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, 03 Oct 2020 17:45:55 -0000
I would think Ron’s IP data plane based flex algo would work identical to SR data plane based flex algo with the base Strict algo 0 providing top layer all node reachability and would contain let’s say loopback0. The algo would have algo and algo # definition on the loopback so the nodes are reachability the discrete non zero algo loopback for the corresponding loopbacks that correlate with algo xyz for the xyz topology. In both IP based algo and the SR based algo would the SR locator or IP based algo be in the BAU base to layer topology SRv6-BE let’s say and SRv6-TE SLA SRH steered would map to non zero algorithms per VRF VPN coloring and would IP based algo do the same. The advent of SR came about filling a much needed gap for operators to provide RSVP TE style per VRF coloring without the added badge of loopback xyz rewrite for the static route coloring issue that you need a separate loopback and static route to RSVP tunnel to steer each per VRF per vpn colored TE tunnel - as you can see with RSVP coloring you have a 1-1 mapping discrete loopback per per VRF steered TE tunnel. So then along came SR to save the day ..end of story.. Back to flex algo ..so SR has the per VRF coloring capability with SR data plane to provide the coloring. I think I maybe confusing to topics as the per VRF TE coloring is using underlay to steer overlay so flex algo is in the underlay so you could do the same SR-TE flex algo steering of underlay thereby steering vpn overlay under pinning of underlay to overlay. How would that be done with IP based flex algo. So with IP based flex algo as well you would be global table routing with no VPN framework. Thanks Gyan On Sat, Oct 3, 2020 at 12:54 PM Gyan Mishra <hayabusagsm@gmail.com> wrote: > > Thanks Peter for the responses to help clear up my flex algo > understanding!! > > On Sat, Oct 3, 2020 at 5:45 AM Peter Psenak <ppsenak@cisco.com> wrote: > >> Gyan, >> >> >> >> On 03/10/2020 02:14, Gyan Mishra wrote: >> >> > >> >> > Hi Jeff >> >> > >> >> > From a domain perspective where you have a group of nodes and >> >> > associated IP addressed and SID are part of a discrete underlay >> instance >> >> > flex algo topology. On those same set of nodes you could have another >> >> > topology and associated address and SIDs for a different flex algo. >> >> >> >> above is right. >> > > Gyan> So per my response to Robert, what I was thinking is that as > the algo 0 strict spf would be used as the base algo to provide > reachability to all nodes within the domain and all neighbors are formed > between all nodes in the domain to populate IGP rib providing base > connectivity reachability. So then underneath of that you can have any > subset of nodes out of the superset all top layer domain nodes level that > can run any other algo desired. Basically creating algo layers under the > top domain wide layer. > >> >> >> >> > How >> >> > this would work is that the topologies would have to be segregated from >> >> > each other as different MT instances or routing process instances. Is >> >> > that correct? >> >> >> >> no MT at all. You can think of each flex-algo as a set of constraints >> >> that is used to calculate the path over the common topology. You can >> >> have many such felx-algos running on a common topology. >> >> > Gyan> Is it safe to say that we can think of it as RSVP TE “like” cSPF > constraints that we are build via traffic engineering PCALC algorithms to > run for dynamic LSP dyamic ERO that is built based on IGP constraints from > TEDs database of TE link attributes and TE or IGP weights metric > constraints to create the dynamic LSP path. So we could think of in TE > framework analogy to flex algo In the per VRF TE next hop vpn coloring use > case with different loopback next hop rewrite per VRF that normal IGP non > TE BAU VPNs traffic would be like the flex algo base strict algo 0 and the > non zero discrete algo would be like the per VRF next hop loopback rewrite > where each per VRF te loopback rewrite would be a different steering non > zero discrete flex algo all running in parallel as ships in the night with > the base algo 0. Sorry for the complex analogy but I think I am getting > it!!😃 > > Does a flex algo use case draft exist and if not I would not mind using > the analogy I said above and build out a use case draft. Cheers! 😊 > >> >> >> >> > >> >> > Can two nodes that run two different flex algo become ospf or isis >> >> > neighbors? >> >> >> >> absolutely. >> >> >> >> Peter >> >> >> >> > >> >> > Kind Regards >> >> > >> >> > Gyan >> >> > >> >> > On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura <jefftant.ietf@gmail.com >> >> > <mailto:jefftant.ietf@gmail.com>> wrote: >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > Hi Yingzhen, >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > Yes, that’s the case. The most important property of an algo >> >> > computed path is that is has to be consecutive, as either SID or IP >> >> > address associated with a particular topology is only known within >> >> > that topology. >> >> > >> >> > >> >> > Looking specifically at Ron’s draft (MPLS could be more complex due >> >> > to potential hierarchy) - the prefix itself defines the >> >> > context(topology) and must be globally unique, since IPv4 header >> >> > can’t have any additional meta-data attached. >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > Cheers, >> >> > >> >> > Jeff >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > On Oct 2, 2020, 1:15 PM -0700, Yingzhen Qu >> >> > <yingzhen.qu@futurewei.com <mailto:yingzhen.qu@futurewei.com>>, >> wrote: >> >> > >> >> > >> >> >> Hi Peter, >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> My understanding of flex-algo is that for traffic destined to a >> >> >> prefix on a particular algo, it can only be routed on routers >> >> >> belong to that algo, which also means only routers in that algo >> >> >> calculates how to reach that prefix and install it into the >> >> >> routing table. It seems to me that using flex-algo (section 12 of >> >> >> the draft) it's possible to have a loopback address associated >> >> >> with only one algo, please correct me if I'm missing or >> >> >> misunderstood something. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Thanks, >> >> >> >> >> >> >> >> >> Yingzhen >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" >> >> >> <lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org> on behalf of >> >> >> ppsenak=40cisco.com@dmarc.ietf.org >> >> >> <mailto:40cisco.com@dmarc.ietf.org>> wrote: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Gyan, >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 02/10/2020 18:30, Gyan Mishra wrote: >> >> >> >> >> >> >> >> >>> All, >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> With SRv6 and IP based flex algo a generic question as it applies >> to >> >> >>> >> >> >>> >> >> >>> both. Is it possible to have within a single IGP domain different >> >> >>> sets >> >> >>> >> >> >>> >> >> >>> of nodes or segments of the network running different algorithms. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> absolutely. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> From >> >> >>> >> >> >>> >> >> >>> both drafts it sounds like all nodes have to agree on same >> algorithm >> >> >>> >> >> >>> >> >> >>> similar to concept of metric and reference bandwidth all have to >> have >> >> >>> >> >> >>> >> >> >>> the same style metric and play to the same sheet of music. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> all participating nodes need to agree on the definition of the >> >> >> flex-algo >> >> >> >> >> >> >> >> >> and advertise the participation. That's it. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> If there was >> >> >>> >> >> >>> >> >> >>> a way to use multiple algorithms simultaneously based on SFC or >> >> >>> services >> >> >>> >> >> >>> >> >> >>> and instantiation of specific algorithm based on service to be >> >> >>> >> >> >>> >> >> >>> rendered. Doing so without causing a routing loop or sub optimal >> >> >>> >> >> >>> >> >> >>> routing. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> you can certainly use multiple algorithms simultaneously and use >> algo >> >> >> >> >> >> >> >> >> specific paths to forward specific traffic over it. How that is >> done >> >> >> >> >> >> >> >> >> from the forwarding perspective depends in which forwarding plane >> you >> >> >> >> >> >> >> >> >> use. Flex-algo control plane is independent of the forwarding >> plane. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> I thought with flex algo that there exists a feature that on >> >> >>> >> >> >>> >> >> >>> each hop there is a way to specify which algo to use hop by hop >> >> >>> similar >> >> >>> >> >> >>> >> >> >>> to a hop by hop policy based routing. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> no, there is no hop-by-hop classification, that is problematic and >> >> >> does >> >> >> >> >> >> >> >> >> not scale for high speeds. Classification is done at the ingress >> only. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> thanks, >> >> >> >> >> >> >> >> >> Peter >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> >> >> >> >> >> Lsr mailing list >> >> >> >> >> >> >> >> >> Lsr@ietf.org <mailto:Lsr@ietf.org> >> >> >> >> >> >> >> >> >> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637372537869296887&sdata=R%2FI%2BAUkcw12FmgDtsh%2FBOL7zLjPF%2BwwRpqwnE2Ndv%2Fg%3D&reserved=0 >> >> >> >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > >> >> > <http://www.verizon.com/> >> >> > >> >> > *Gyan Mishra* >> >> > >> >> > /Network Solutions A//rchitect / >> >> > >> >> > /M 301 502-1347 >> >> > 13101 Columbia Pike >> >> > /Silver Spring, MD >> >> > >> >> > >> >> >> >> -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-134713101 Columbia Pike *Silver Spring, MD > > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
- [Lsr] FW: New Version Notification for draft-boni… Ron Bonica
- Re: [Lsr] New Version Notification for draft-boni… tony.li
- Re: [Lsr] New Version Notification for draft-boni… Jia Chen
- Re: [Lsr] New Version Notification for draft-boni… Huzhibo
- Re: [Lsr] New Version Notification for draft-boni… Joel M. Halpern
- Re: [Lsr] New Version Notification for draft-boni… Huzhibo
- Re: [Lsr] New Version Notification for draft-boni… Robert Raszuk
- Re: [Lsr] New Version Notification for draft-boni… Peter Psenak
- Re: [Lsr] New Version Notification for draft-boni… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Muthu Arul Mozhi Perumal
- Re: [Lsr] New Version Notification for draft-boni… Robert Raszuk
- Re: [Lsr] New Version Notification for draft-boni… Dongjie (Jimmy)
- Re: [Lsr] New Version Notification for draft-boni… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Ron Bonica
- Re: [Lsr] New Version Notification for draft-boni… Robert Raszuk
- Re: [Lsr] New Version Notification for draft-boni… Les Ginsberg (ginsberg)
- Re: [Lsr] FW: New Version Notification for draft-… Jeff Tantsura
- Re: [Lsr] New Version Notification for draft-boni… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] New Version Notification for draft-boni… Ron Bonica
- Re: [Lsr] New Version Notification for draft-boni… Ron Bonica
- Re: [Lsr] FW: New Version Notification for draft-… Acee Lindem (acee)
- Re: [Lsr] FW: New Version Notification for draft-… Ron Bonica
- Re: [Lsr] FW: New Version Notification for draft-… Gyan Mishra
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Gyan Mishra
- Re: [Lsr] FW: New Version Notification for draft-… Yingzhen Qu
- Re: [Lsr] FW: New Version Notification for draft-… Jeff Tantsura
- Re: [Lsr] FW: New Version Notification for draft-… Gyan Mishra
- Re: [Lsr] FW: New Version Notification for draft-… Robert Raszuk
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Gyan Mishra
- Re: [Lsr] FW: New Version Notification for draft-… Gyan Mishra
- Re: [Lsr] FW: New Version Notification for draft-… Gyan Mishra
- Re: [Lsr] FW: New Version Notification for draft-… Yingzhen Qu
- Re: [Lsr] FW: New Version Notification for draft-… Ron Bonica
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Gyan Mishra
- [Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo-01 Huaimo Chen
- Re: [Lsr] FW: New Version Notification for draft-… Dongjie (Jimmy)
- [Lsr] 回复: draft-zhu-lsr-isis-sr-vtn-flexalgo-01 zhuyq8
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Ron Bonica
- Re: [Lsr] FW: New Version Notification for draft-… Dongjie (Jimmy)
- Re: [Lsr] FW: New Version Notification for draft-… Ron Bonica
- Re: [Lsr] FW: New Version Notification for draft-… Jeff Tantsura
- Re: [Lsr] FW: New Version Notification for draft-… Ron Bonica
- Re: [Lsr] FW: New Version Notification for draft-… Jeff Tantsura
- Re: [Lsr] FW: New Version Notification for draft-… Gyan Mishra
- Re: [Lsr] FW: New Version Notification for draft-… Acee Lindem (acee)
- Re: [Lsr] FW: New Version Notification for draft-… Jeff Tantsura
- Re: [Lsr] FW: New Version Notification for draft-… Dongjie (Jimmy)
- Re: [Lsr] FW: New Version Notification for draft-… Dongjie (Jimmy)
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Robert Raszuk
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Gyan Mishra
- Re: [Lsr] FW: New Version Notification for draft-… Dongjie (Jimmy)
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Robert Raszuk
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] FW: New Version Notification for draft-… Dongjie (Jimmy)
- Re: [Lsr] FW: New Version Notification for draft-… Dongjie (Jimmy)
- Re: [Lsr] FW: New Version Notification for draft-… Peter Psenak
- Re: [Lsr] New Version Notification for draft-boni… bruno.decraene
- Re: [Lsr] New Version Notification for draft-boni… Peter Psenak
- Re: [Lsr] New Version Notification for draft-boni… bruno.decraene
- Re: [Lsr] New Version Notification for draft-boni… Peter Psenak
- Re: [Lsr] New Version Notification for draft-boni… bruno.decraene
- Re: [Lsr] New Version Notification for draft-boni… Peter Psenak