Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"
Ketan Talaulikar <ketant.ietf@gmail.com> Mon, 16 May 2022 14:22 UTC
Return-Path: <ketant.ietf@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 DA9A9C185B3D; Mon, 16 May 2022 07:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.094
X-Spam-Level:
X-Spam-Status: No, score=-7.094 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 (2048-bit key) header.d=gmail.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 ygBD0NdJ_6RB; Mon, 16 May 2022 07:21:59 -0700 (PDT)
Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 ietfa.amsl.com (Postfix) with ESMTPS id D7444C185B3C; Mon, 16 May 2022 07:21:58 -0700 (PDT)
Received: by mail-vs1-xe33.google.com with SMTP id u205so15655881vsu.6; Mon, 16 May 2022 07:21:58 -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=XuNTT1rUvU0qxZ5gYEWY5SzMM2AjIzSV8DerjZVMJl8=; b=SCeXZ+j755IdwqEBQUbksmrmAULlyMwuUqhHvCj+eLIbB9Xp3+hdlHHxKQBVSjjbeG wcRXzFy14fqubXS30x2ttX46rASD10H8ipzSFZ730JarKqbZJanMzcgsECDFdxUOUobW qw8o+6K18FzV6BX9yWIOOCev1wZmrkjowOgKk1L/GYacQkSAlH5fMhiZLLekn8EwFE9l I003MDnj4eJmFjK93lIOpx1yIj1UsLtItTdnSVHSijHd3uz6sjaEyXW9WHoYifIaWTN1 y/jkCD/c5Vk0p9h2jlEWLbCUOb7bxGT0jS+M2bNEWzQSysEIhu13spSPb3504KD7ODmE W7YA==
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=XuNTT1rUvU0qxZ5gYEWY5SzMM2AjIzSV8DerjZVMJl8=; b=nnzQzCyn8I+sPCudni4RxJhuyN1RIFrAy5xbBZUQW4vGQflyWHuT0rhtZkugS0YWOZ fDjHrRoeb0RKF5Cu/nLXQucXx169hmJpUp3NFK2RwXPp6TrGV7mMJ4+L4/6S6iXSGKVy mb4IpUkyg6XjNDi7dWbL4tH190MK6I8gw0l+Dne/4E9eW8plOTwpBKVE6stJpZdIbMrc pzLDKKndIfRxQ7HtZ72BhIGHWYw1KV+Cb2Bh7DlVcpiYM++S63Qg/cFV0e6itzehZEg4 FsTkJM2nebxg59E0zF1Vpzm8xO/EGXNsq2BMt+VuyJXVtUnZM5IJX27tA2sTL2j6rrv9 XSKg==
X-Gm-Message-State: AOAM530qGTy/0pJlWMfor3jo7ThrzvBAl9+1gccEphmt+y8cAySwLHfp KWZ+IKHN4a51vuCPEPredmcRcGni9sBzMS/hg10xLfRi
X-Google-Smtp-Source: ABdhPJzxIC9a8YGNmSxr01Q6JLnFwufOv5cI9nvUegpq4VXh1S9eFImDz7NokJ7RAPyBH9FCnKoOItRBlfG+6Z5HCTc=
X-Received: by 2002:a67:c893:0:b0:325:5b5d:d1dd with SMTP id v19-20020a67c893000000b003255b5dd1ddmr6495380vsk.33.1652710917672; Mon, 16 May 2022 07:21:57 -0700 (PDT)
MIME-Version: 1.0
References: <36E526F2-34CB-4C0A-84C2-79A50D9D4C36@cisco.com> <CAH6gdPwrshSVGNsjJVqND8kpNBTBQWicggEz_qyP0DtMYY5wjg@mail.gmail.com> <ada98772-db20-186d-6833-4c0a1e502b99@cisco.com> <CAH6gdPzSCafeyBUJC9NyvX_=nxGJ3PXbdMukwDbUduomwq6-iQ@mail.gmail.com> <e2c0480d-67cb-2287-574c-b8bdf9172a53@cisco.com>
In-Reply-To: <e2c0480d-67cb-2287-574c-b8bdf9172a53@cisco.com>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Mon, 16 May 2022 19:51:46 +0530
Message-ID: <CAH6gdPy9q1xO=Pcn9XXrwHbZUtSFZhMFx3A7yCQfU=RB9wryng@mail.gmail.com>
To: Peter Psenak <ppsenak@cisco.com>
Cc: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "draft-ietf-lsr-ip-flexalgo@ietf.org" <draft-ietf-lsr-ip-flexalgo@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002a10d605df21bfb6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ED-TqOpTAuIbLtwfCqOkoWIiMxY>
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.34
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: Mon, 16 May 2022 14:22:00 -0000
Thanks Peter and the changes look good to me. Thanks, Ketan On Mon, May 16, 2022 at 3:25 PM Peter Psenak <ppsenak@cisco.com> wrote: > Hi Ketan, > > > On 13/05/2022 15:32, Ketan Talaulikar wrote: > > Hi Peter, > > > > Thanks for your updates to the draft and your responses below. > > > > I would like to point out a few remaining points to be fixed/addressed. > > > > a) There is a discrepancy regarding the size of the Metric field for the > > OSPFv2 IP Algo Reachability sub-TLV between the figure and the text > > description. The text needs to be fixed to reflect 4 octets size. > > fixed > > > > > b) For the OSPFv3 IP Algo Prefix Reachability sub-TLV the Type should be > > 2 octets and the discrepancy in the sub-TLV name in the Figure needs to > > be corrected. Length should now become 8. > > fixed. > > > > > c) The references to the sections of draft-lsr-flex-algo in this > > document need corrections in Sec 7 ? In general, I think the references > > to the base draft sections 11, 12, and 13 (except that M-flag is always > > used) would be helpful. > > I removed the references to any particular sections and kept only the > references to the draft itself. This is better as the sections tends to > change and the result is that the references to sections are incorrect. > > thanks, > Peter > > > > > > Thanks, > > Ketan > > > > On Wed, May 11, 2022 at 3:20 PM Peter Psenak <ppsenak@cisco.com > > <mailto:ppsenak@cisco.com>> wrote: > > > > Hi Ketan, > > > > > > please see inline (##PP): > > > > On 11/04/2022 08:25, Ketan Talaulikar wrote: > > > Hello All, > > > > > > Following are some comments on this draft: > > > > > > 1) Is this draft about opening the use of all IGP Algorithms for > IP > > > (Algo) Routing or intended to be specific to Flexible Algorithms > > (i.e. > > > algo 128-255) alone. I think it is important to specify the scope > > > unambiguously. Perhaps it makes sense to restrict the usage in > this > > > particular document to FlexAlgorithms alone. If not, the draft > > probably > > > needs an update and we need to also cover algo 1 (Strict SPF) > > > applicability and update the text to refer more generically to > > > algo-specific IP routing. > > > > ##PP > > Done > > > > > > > > 2) The relationship between the algo usage for IP FlexAlgo and > other > > > data planes (e.g. FlexAlgo with SR) is not very clear. There arise > > > complications when the algo usage for IP FlexAlgo overlap with > other > > > (say SR) data planes since the FAD is shared but the node > > participation > > > is not shared. While Sec 9 suggests that we can work through these > > > complications, I question the need for such complexity. The > FlexAlgo > > > space is large enough to allow it to be shared between various > data > > > planes without overlap. My suggestion would be to neither carve > out > > > parallel algo spaces within IGPs for various types of FlexAlgo > data > > > planes nor allow the same algo to be used by both IP and SR data > > planes. > > > So that we have a single topology computation in the IGP for a > given > > > algo based on its FAD and data plane participation and then when > it > > > comes to prefix calculation, the results could involve > > programming of > > > entries in respective forwarding planes based on the signaling of > > the > > > respective prefix reachabilities. The coverage of these aspects > in a > > > dedicated section upfront will help. > > > > ##PP > > this has been discussed previously in this thread. > > > > > > > > > > 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 > > Done > > > > > > > > 4) The draft is mixing up "address" and "prefix" in some places. > IGP > > > path computation is for prefixes and not addresses. There are a > few > > > instances where "address" should be replaced by "prefix". > > References to > > > RFC791 and RFC8200 seem unnecessary. > > > > > > ##PP > > Done > > > > > > > > 5) The draft does not cover the actual deployment use-case or > > > applicability of IP FlexAlgo. The text in Sec 3 is not clear and > > > insufficient. What is the point/use of sending traffic to a > > loopback of > > > the egress router? Perhaps it makes sense in a deployment where > > IP-in-IP > > > encapsulation is used for delivering an overlay service? If so, > > would be > > > better to clarify this. The other deployment scenario is where > > > "external" or "host/leaf prefixes" are associated with a FlexAlgo > to > > > provide them a different/appropriate routing path through the > > network. > > > Yet another is the use of IP FlexAlgo along with LDP. Sec 9 does > not > > > address the topic well enough. I would suggest expanding and > > clarifying > > > this and perhaps other such deployment use cases (or > > applicability) in > > > the document in one of the earlier sections to provide a better > > context > > > to the reader. > > > > > > ##PP > > Done > > > > > > > > > > 6) It would be better to move the common (i.e. not protocol > > specific) > > > text from 5.1 and 5.2 under 5. This might also apply to some > > extent to > > > the contents of sec 6. > > > > > > ##PP > > Done. For section 6, I would prefer to keep it in the protocol > specific > > sections. > > > > > > > > 7) Most of the text with MUSTs in sec 5 doesn't really make sense > in > > > repeating - this is covered in the base FlexAlgo spec already. > > The only > > > key/important MUST is the one related to using separate algo for > IP > > > FlexAlgo over SR data planes. See my previous comment (2) above. > > > > ##PP > > I prefer to keep the MUSTs there > > > > > > > > 8) Sec 5.1, the SHOULD needs to be MUST in the text below. > > > > > > A router receiving multiple IP Algorithm > > > sub-TLVs from the same originator SHOULD select the first > > > advertisement in the lowest-numbered LSP and subsequent > > instances of > > > the IP Algorithm Sub-TLV MUST be ignored. > > > > ##PP > > Done. > > > > > > > > > > > 9) Sec 5.1, I would suggest changing the following text as > > indicated. > > > Also, perhaps add that the algo 0 MUST NOT be advertised and a > > receiver > > > MUST ignore if it receives algo 0. > > > OLD > > > > > > The IP Algorithm Sub-TLV could be used to advertise > > > support for non-zero standard algorithms, but that is outside > the > > > scope of this document. > > > > > > NEW > > > > > > The use of IP Algorithm Sub-TLV to advertise support for > > algorithms > > > > > > outside the flex-algorithm range is outside the > > > scope of this document. > > > > ##PP > > Done > > > > > > > > > > > 10) Sec 5.1, the SHOULD needs to be MUST in the text below > > > > > > The IP Algorithm TLV is optional. It SHOULD only be > > advertised once > > > in the Router Information Opaque LSA. > > > > ##PP > > Done > > > > > > > > > > > 11) Sec 6. The following text is better moved into the respective > > > protocol sub-sections. OSPFv3 is not covered anyway by it. > > > > > > Two new top-level TLVs are defined in ISIS [ISO10589 > > < > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#ref-ISO10589 > > < > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#ref-ISO10589 > >>] > > to advertise > > > prefix reachability associated with a Flex-Algorithm. > > > > > > * The IPv4 Algorithm Prefix Reachability TLV > > > > > > * The IPv6 Algorithm Prefix Reachability TLV > > > > > > New top-level TLV of OSPFv2 Extended Prefix Opaque LSA > > [RFC7684 <https://datatracker.ietf.org/doc/html/rfc7684 > > <https://datatracker.ietf.org/doc/html/rfc7684>>] is > > > defined to advertise prefix reachability associated with a > Flex- > > > Algorithm in OSPFv2. > > > > ##PP > > Done > > > > > > > > 12) Sec 6.1 & 6.2. There is no discussion regd the use of the > Prefix > > > Attribute Flags sub-TLV with the new top-level TLVs. > > > > > > I think their usage MUST (or at least SHOULD) be included as it > > helps > > > determine the route type and prefix attributes that > > > > > > have proven to be quite useful for various use cases and > deployments. > > > > ##PP > > > > Why? We have a text that says: > > > > "This new TLV shares the sub-TLV space defined for TLVs 135, 235, 236 > > and 237." > > > > Why do we need to describe the usage of the specific sub-TLV? > > > > > > > > > > > 13) Sec 6.2 what happens when the same prefix is advertised as > SRv6 > > > Locator as well as IPv6 Algo Prefix (same or conflicting algos). > > Perhaps > > > both must be ignored? > > > > > > The same applies for OSPFv3 as well. > > > > ##PP > > Done > > > > > > > > > > > 14) Sec 6.3, OSPFv2 MT-ID reference should be RFC4915. Perhaps > > the range > > > of MT should be mentioned since it is a 8 bit field here. > > > > ##PP > > Done > > > > > > > > > > > 15) Sec 6.4, the metric field in the sub-TLV has to be 32-bit. > While > > > 24-bit is ok when the FAD uses IGP metric, it will not suffice > > for other > > > IGP metric types. > > > > ##PP > > Done > > > > > > > > > > > 16) Sec 6.3 & 6.4, the conflict checking with base algo 0 prefix > > > reachability cannot be limited only to the OSPFv2/3 Extended LSAs > > but > > > should also cover the base fixed form > > > > OSPFv2/v3 LSAs. We could use a more generic term like "normal > prefix > > > reachability" advertisements perhaps to cover the different LSAs? > > > > ##PP > > Done > > > > > > > > > > > > > 17) Sec 7 and 8, suggest to not use the term "application" to > avoid > > > confusion with ASLA. My understanding is that there is a single > > FlexAlgo > > > application when it comes to ASLA. > > > > > > Perhaps the intention here is "data plane" ? > > > > ##PP > > Done > > > > > > > > > > > 18) The relationship between the BIER IPA and this draft needs > some > > > clarifications - should the BIER WG be notified if they want to > > update > > > draft-ietf-bier-bar-ipa? > > > > > > This (in some way) goes back to my comment (2) above. > > > > ##PP > > I don't see the relationship to BIER IPA here. > > > > > > > > > > > 19) Sec 8, what prevents the use of IP FlexAlgo paths programmed > > by LDP > > > as well. Or if the intention is to use them strictly for IP > > forwarding only > > > > > > then this needs to be clarified. > > > > ##PP > > nothing prevents someone to advertise LDP label for the IP > algo-prefix > > and use it with the labeled forwarding. I don't see a problem. But > this > > specification does not specify any of it. > > > > > > > > > > > 20) The following text in Sec 9 is about using the same FlexAlgo > > (with a > > > common definition) for multiple data-planes at the same time. The > > key is > > > that we only are able to use > > > > > > prefix in one algo/data-plane? I am wondering if we can improve > this > > > text to bring this out in a better way. Or altogether remove this > > if we > > > agree to not allow sharing of algo > > > > > > between different data planes to keep things simple. > > > > > > Multiple application can use the same Flex-Algorithm value at > the > > > > > > same time and and as such share the FAD for it. For example > > SR-MPLS > > > and IP can both use such common Flex-Algorithm. Traffic for > > SR-MPLS > > > will be forwarded based on Flex-algorithm specific SR SIDs. > > Traffic > > > for IP Flex-Algorithm will be forwarded based on > Flex-Algorithm > > > specific prefix reachability announcements. > > > > ##PP > > Done. > > > > thanks, > > Peter > > > > > > > > > Thanks, > > > > > > Ketan > > > > > > > > > > > > On Fri, Apr 8, 2022 at 12:38 AM Acee Lindem (acee) > > > <acee=40cisco.com@dmarc.ietf.org > > <mailto:40cisco.com@dmarc.ietf.org> > > <mailto:40cisco.com@dmarc.ietf.org > > <mailto:40cisco.com@dmarc.ietf.org>>> wrote: > > > > > > This begins a WG last call for > > draft-ietf-lsr-ip-flexalgo-04. The > > > draft had a lot of support and discussion initially and has > been > > > stable for some time. Please review and send your comments, > > support, > > > or objection to this list before 12 AM UTC on April 22^nd , > > 2022.____ > > > > > > __ __ > > > > > > Thanks, > > > Acee____ > > > > > > _______________________________________________ > > > Lsr mailing list > > > Lsr@ietf.org <mailto:Lsr@ietf.org> <mailto:Lsr@ietf.org > > <mailto:Lsr@ietf.org>> > > > https://www.ietf.org/mailman/listinfo/lsr > > <https://www.ietf.org/mailman/listinfo/lsr> > > > <https://www.ietf.org/mailman/listinfo/lsr > > <https://www.ietf.org/mailman/listinfo/lsr>> > > > > > > >
- [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