Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Robert Raszuk <robert@raszuk.net> Tue, 13 October 2020 11:38 UTC
Return-Path: <robert@raszuk.net>
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 D77FA3A0F61 for <lsr@ietfa.amsl.com>; Tue, 13 Oct 2020 04:38:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 azRUD-QJ67XF for <lsr@ietfa.amsl.com>; Tue, 13 Oct 2020 04:38:18 -0700 (PDT)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 85EEC3A0B2E for <lsr@ietf.org>; Tue, 13 Oct 2020 04:38:17 -0700 (PDT)
Received: by mail-ej1-x629.google.com with SMTP id md26so27750433ejb.10 for <lsr@ietf.org>; Tue, 13 Oct 2020 04:38:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hd4foOdD1riBttrO2huN3+3WVS8Xd/cVXssIm9/Brd8=; b=NjaIFyaNbpE7wi8CympDHBWQhKx2iEu7LwNXq4wb/cQUaPR+DTfNnhSSKnR+c4nvkS GU0I4CRffyPl5nkMxPF17QIAEYtf0zkOuDAZ/8OVGjNuhPdadBbIsOIni5p2c0WertNR 8qzvaK+/rZjUnjGTpzJ8AxqwshoqKGjLZOsLmqxWcqLFflJjxpe9idd0nJi6wnwxYaqH EEUb4ZCwXlYq5wwwgRS2A/hpvdLZu4hyE4eav3NUw0FmgNEimy7liQMxIMucp3CuzzDD 9uPXDnEsG5lidGJUSLAPOtj/UTeZfFNq0Ygkmff2f8s6It8hqb4eiiogZW4IFBDiLVrl +NMw==
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=hd4foOdD1riBttrO2huN3+3WVS8Xd/cVXssIm9/Brd8=; b=cIHDjEXHmPtgvpj/rjn/iY2Eu2ukC5oZkVIQYQ99C2E14Vfryf92oSiFGs2ffbf+Ym RwsEFG4oA8+nwd44uOW82C42ZW8Qo7nwQSjUZwgJ29EDbMsaWZkr7uGWXs3Nn3BRPMUV khOi06OmP+iISBp97ZgN5zfA8QFfukHhzxSJY8TwAFcQC2DQOq8fZ2JIpJDNRrJ3cMdX kyAGQz8O51AjaSPhzwNqt0Qxf++YqoiQkVBhJkGZrqBty21TclZJxvXPC3Kx26k1lQJG cxb4R0CBu2dJULY407ktUIvmjpVZewyY/NQpEMY55xKXIvOPEK5t2FVJ1c0iaZPSp4KJ c/5A==
X-Gm-Message-State: AOAM533gWUs7MkAAoWb3ujzOR0YGVwuxawoiwNfnKWpYbvNmAf+9i3AQ BD97HP1gQpq7a+Oz1vAwgI2DWVr02YfAFt1VEnuI0Q==
X-Google-Smtp-Source: ABdhPJzbiIzTlITNixAF5+WPVv8Kc0Stv0rwvWJlFwHmJhQNc3FcZiV2OafYkh+yA99xdv3wuARK/z37+yIITeHoouI=
X-Received: by 2002:a17:906:d964:: with SMTP id rp4mr5589291ejb.110.1602589095687; Tue, 13 Oct 2020 04:38:15 -0700 (PDT)
MIME-Version: 1.0
References: <160138654056.12980.329207214151594381@ietfa.amsl.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> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> <DM6PR05MB6348C6FBFD50C19C06DE719BAE0E0@DM6PR05MB6348.namprd05.prod.outlook.com> <4896cf59c3314f1c92cdb491d1d8a5a3@huawei.com> <c9b0f0aa-975a-f042-6773-58a603ba5d39@cisco.com> <fe517f068bea428a9a95b3247f20a100@huawei.com> <9c7628a9-d089-1de9-932b-83bb3f875ba3@cisco.com> <34c223a132f748e0a802d538ccd073b0@huawei.com> <c7ad92ab-3ac7-afe9-fa2a-221f80468491@cisco.com>
In-Reply-To: <c7ad92ab-3ac7-afe9-fa2a-221f80468491@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 13 Oct 2020 13:38:05 +0200
Message-ID: <CAOj+MMHMWMT_6WeZdt+8R5Vkg3eh=mpU=GSu-jc-SJ+=zL93Mw@mail.gmail.com>
To: Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>
Cc: "Dongjie (Jimmy)" <jie.dong@huawei.com>, Ron Bonica <rbonica@juniper.net>, Yingzhen Qu <yingzhen.qu@futurewei.com>, Gyan Mishra <hayabusagsm@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000c51a8905b18bd91b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/nMZGXYJUmiXVz0iYHrOeqtkeiCk>
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: Tue, 13 Oct 2020 11:38:21 -0000
Peter, If this is per app how are the constraints shared across apps ? See we have single physical resources (for example links) and single interface outbound queues. If I use per app flex-algo and do not have central controller how is this going to work in practice for any network which attempts to use more then one forwarding schema with dynamic constraints ? Many thx, R. On Tue, Oct 13, 2020 at 10:52 AM Peter Psenak <ppsenak= 40cisco.com@dmarc.ietf.org> wrote: > Hi Jimmy, > > On 13/10/2020 10:02, Dongjie (Jimmy) wrote: > > Hi Peter, > > > > Thanks for your reply. Please see further inline: > > > >> -----Original Message----- > >> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak > >> Sent: Monday, October 12, 2020 4:39 PM > >> To: Dongjie (Jimmy) <jie.dong@huawei.com>; Ron Bonica > >> <rbonica@juniper.net>; Yingzhen Qu <yingzhen.qu@futurewei.com>; Gyan > >> Mishra <hayabusagsm@gmail.com> > >> Cc: lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com> > >> Subject: Re: [Lsr] FW: New Version Notification for > >> draft-bonica-lsr-ip-flexalgo-00.txt > >> > >> Hi Jimmy, > >> > >> On 10/10/2020 05:05, Dongjie (Jimmy) wrote: > >>> Hi Peter, > >>> > >>> Thanks for your reply. It aligns with my understanding of FAD, which > is just a > >> set of constraints for path computation. Thus one Flex-Algo ID could be > used > >> with multiple different data planes. Is this understanding correct? > >> > >> correct. > >> > >>> > >>> If so, my question is about the scenario below: > >>> > >>> A group of nodes in a network support FA-128, a sub-group of them bind > >> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address. > >> > >> just to use the correct terminology, we should use "participate" > instead of > >> "support". > > > > Agree. > > > >> > >>> When one node compute an SR path to a destination, can it compute the > path > >> to only pass the nodes which bind FA-128 to SR SIDs, and avoid the > >> nodes >which bind FA-128 to IP address? If so, how could this node know > the > >> binding of FA to different data planes on other nodes? > >> > >> again, it is the participation problem. > >> > >> Nodes that participate in the SR Flex-algo 128 will advertise the > participation > >> using the SR-Algorithm Sub-TLV. Only these nodes will be used during > the SR > >> flex-algo computation for algo 128. > >> > >> Nodes that participate in IP flex-algo 128 will advertise the > participation using > >> the IGP Algorithm Sub-TLV. Only these nodes will be used during the IP > flex-algo > >> computation for algo 128. > > > > Agree that if participation to Flex-Algo is advertised in a data plane > specific manner, then path computation with Flex-Algo constraints could be > done only using nodes which bind the Flex-Algo to the same data plane. > > it's per app, not per data plane, but yes, that is what the base > flex-algo spec mandates. > > > > > As Robert asked and you confirmed, this implies each data plane needs to > be treated as an independent application of Flex-Algo. We have SR-Algorithm > sub-TLV and IP Algorithm sub-TLV, while there are actually more data planes > to be considered: SR-MPLS, SRv6, IPv4, IPv6, etc., does this mean that > Flex-Algo participation needs to be advertised for SR-MPLS, SRv6, IPv4, > IPv6, etc. separately? > > yes, it needs to be advertised per app. We have SR specific algo > participation, we need one for IP as proposed in Ron's draft. > > Regarding IPv4 vs IPv6, it's up to the authors whether they want to make > the participation for IP flex-algo topology specific or topology > independent, both could work. > > Here's the text from the base flerx-algo draft: > > 10.2. Advertisement of Node Participation for Other Applications > > This section describes considerations related to how other > applications can advertise their participation in a specific Flex- > Algorithm. > > Application-specific Flex-Algorithm participation advertisements MAY > be topology specific or MAY be topology independent, depending on the > application itself. > > Application-specific advertisement for Flex-Algorithm participation > MUST be defined for each application and is outside of the scope of > this document. > > thanks, > Peter > > > > > > Best regards, > > Jie > > > >> > >> thanks, > >> Peter > >> > >>> > >>> Best regards, > >>> Jie > >>> > >>>> -----Original Message----- > >>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak > >>>> Sent: Friday, October 9, 2020 11:58 PM > >>>> To: Dongjie (Jimmy) <jie.dong@huawei.com>; Ron Bonica > >>>> <rbonica=40juniper.net@dmarc.ietf.org>; Yingzhen Qu > >>>> <yingzhen.qu@futurewei.com>; Gyan Mishra <hayabusagsm@gmail.com> > >>>> Cc: lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com> > >>>> Subject: Re: [Lsr] FW: New Version Notification for > >>>> draft-bonica-lsr-ip-flexalgo-00.txt > >>>> > >>>> Hi Jimmy, > >>>> > >>>> > >>>> On 09/10/2020 04:59, Dongjie (Jimmy) wrote: > >>>>> Hi Ron, > >>>>> > >>>>> Thanks for explaining the difference between IP Flex-Algo and SR > >>>>> Flex-algo. As > >>>> you said, the major difference is the data plane. > >>>>> > >>>>> If my understanding is correct, for one Flex-Algo to be used > >>>>> correctly, the set > >>>> of nodes need to apply consistent constraints in computation, and > >>>> bind the FAD to the same data plane. > >>>>> > >>>>> Is it possible that different nodes may use the same Flex-Algo with > >>>>> different > >>>> data plane, e.g. some with SR-MPLS, some with SRv6, and some with > >>>> pure IP etc., or each Flex-Algo is always associated with only one > >>>> data plane? In the former case, should the flex-algo definition also > >>>> indicate the data plane(s) to be used with the flex-algo? > >>>> > >>>> let me respond to this query, as this is not specific to Ron's draft. > >>>> > >>>> FAD is data plane agnostic and is used by all of them. > >>>> > >>>> thanks, > >>>> Peter > >>>> > >>>>> > >>>>> Best regards, > >>>>> Jie > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica > >>>>>> Sent: Sunday, October 4, 2020 4:34 AM > >>>>>> To: Yingzhen Qu <yingzhen.qu@futurewei.com>; Peter Psenak > >>>>>> <ppsenak@cisco.com>; Gyan Mishra <hayabusagsm@gmail.com> > >>>>>> Cc: lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com> > >>>>>> Subject: Re: [Lsr] FW: New Version Notification for > >>>>>> draft-bonica-lsr-ip-flexalgo-00.txt > >>>>>> > >>>>>> Hi Yingzhen, > >>>>>> > >>>>>> IP Flexible Algorithms are like SR Flexible Algorithms in the > >>>>>> following > >>>> respects: > >>>>>> > >>>>>> - Links have IGP metrics, TE metrics, delay metrics and > >>>>>> administrative colors > >>>>>> - FADs define Flexible Algorithms > >>>>>> > >>>>>> More specifically, the FAD: > >>>>>> > >>>>>> - Indicates which metric type the Flexible Algorithm uses > >>>>>> - Specifies constraints in terms of link colors that are included > >>>>>> or excluded from the Flexible Algorithm. > >>>>>> > >>>>>> The significant difference between IP Flexible Algorithms and SR > >>>>>> Flexible Algorithms is: > >>>>>> > >>>>>> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators > >>>>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses. > >>>>>> > >>>>>> So, IP Flexible Algorithms can be deployed in any IP network, even > >>>>>> in the absence of SR. > >>>>>> > >>>>>> Ron > >>>>>> > >>>>>> > >>>>>> Juniper Business Use Only > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Yingzhen Qu <yingzhen.qu@futurewei.com> > >>>>>> Sent: Saturday, October 3, 2020 2:08 PM > >>>>>> To: Peter Psenak <ppsenak@cisco.com>; Gyan Mishra > >>>>>> <hayabusagsm@gmail.com>; Ron Bonica <rbonica@juniper.net> > >>>>>> Cc: lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com> > >>>>>> Subject: Re: [Lsr] FW: New Version Notification for > >>>>>> draft-bonica-lsr-ip-flexalgo-00.txt > >>>>>> > >>>>>> [External Email. Be cautious of content] > >>>>>> > >>>>>> > >>>>>> Hi Peter, > >>>>>> > >>>>>> Using flex-algo, a SRv6 locator can be associated with a single > >>>>>> algo, which means an IPv6 or IPv4 address can also be associated > >>>>>> with a single algo. So my understanding is Ron's proposal is making > >>>>>> the > >>>> configuration of flex-algo easier? > >>>>>> Instead of using the exclude or include list you can configure a > >>>>>> loopback address to a flex-algo directly? > >>>>>> > >>>>>> Thanks, > >>>>>> Yingzhen > >>>>>> > >>>>>> On 10/3/20, 2:47 AM, "Peter Psenak" <ppsenak@cisco.com> wrote: > >>>>>> > >>>>>> Hi Yingzhen, > >>>>>> > >>>>>> On 02/10/2020 22:15, Yingzhen Qu 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. > >>>>>> > >>>>>> you are right. That is exactly what is being done for > flex-algo with > >>>>>> SRv6 - locator is associated with a single algo only. The > proposal > >> uses > >>>>>> the same concept. > >>>>>> > >>>>>> thanks, > >>>>>> Peter > >>>>>> > >>>>>> > > >>>>>> > Thanks, > >>>>>> > Yingzhen > >>>>>> > > >>>>>> > On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" > >>>>>> <lsr-bounces@ietf.org on behalf of > >>>>>> ppsenak=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 > >>>>>> > > >>>>>> https://urldefense.com/v3/__https://nam11.safelinks.protection.outl > >>>>>> oo > >>>>>> k.com/ > >>>>>> ?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&data > >>>>>> = > >>>> 0 > >>>>>> 2 > >>>>>> > >>>> > >> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781 > >>>>>> > >>>> > >> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 > >>>>>> > >>>> > >> 5126&sdata=WI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D > >>>>>> > >>>> > >> &reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR > >>>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$ > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Lsr mailing list > >>>>>> Lsr@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/lsr > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Lsr mailing list > >>>> Lsr@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/lsr > >>> > >>> > >> > >> _______________________________________________ > >> Lsr mailing list > >> Lsr@ietf.org > >> https://www.ietf.org/mailman/listinfo/lsr > > > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr >
- [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