Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
Chris Bowers <chrisbowers.ietf@gmail.com> Fri, 14 February 2020 16:29 UTC
Return-Path: <chrisbowers.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 A3FC912008A; Fri, 14 Feb 2020 08:29:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 eQdDJ0W7m2tl; Fri, 14 Feb 2020 08:29:23 -0800 (PST)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 6C62D1200E5; Fri, 14 Feb 2020 08:29:23 -0800 (PST)
Received: by mail-qt1-x82c.google.com with SMTP id d5so7366045qto.0; Fri, 14 Feb 2020 08:29:23 -0800 (PST)
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; bh=+d4AqypyZiC/mRPzlhTmCcdPK/w/tFfBc/xsw0+LN10=; b=XDWduURo1TvfiBBsQY45wnjSsSeFTLPOur9I6/u1AIjShTYxqFRYPoJhI+LrgHRWHW BQNZttoLim5wxISBAA9/LEZQJsgV00X41apunAQs+PUsPSlM13PP6Dm0h1tTbIfg9cXZ 4owMv8ZHdW1sAE7LhRdX2W54AW90wsh4OEKBXkvGG96IKXCdBMOJ8d1ePDzIf7kjFIjU o4H6eV9QMSKUBefIUJIr2KB1aG4WnZiggtHvO+sDPVTfXjkw9Dme0RZC9x4ux64MIRkh gDj61rYbKwG6+9/9alT0/uSjECVnVOe7q1fYg2zBimBQkoLtxk/z3TVJekd7Ygp/yX1Q VV7w==
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; bh=+d4AqypyZiC/mRPzlhTmCcdPK/w/tFfBc/xsw0+LN10=; b=LWXx6I9uGfD0GuTRbFNHYrqkr6QpcW/4iBWnm4NhXPNssfoLB2XlAOM+N2+O++ki6N 903cT/SsKK+tzIahmEuhzkzN54b7nqjuDFxJVnsFZ9I2qs1a1hNceAb0yiS4lQHlwYgk CoFOf53vhbNdsVLUwcvzHoS9HAEfJXt2ul8ymYHN1IVrA207XcwQKcMw1PSsaPsg9D4X L5orfAqk2hsTQcZhmeU0KKyWCJARgICWt3OT5OugyIYpuVeRGETDIXYROm3w6+U/GX5Y q19oShLax9aXN+ZhHFcivvWXCGZx3i1SJ2l91FRT6AzO69Y7c8po8ZSWmvicD3Q0Rjms 2p7w==
X-Gm-Message-State: APjAAAW1M3T0Hp5U2kCo8QC5E05I2Ax8UioN6ulbQwkl+tdS1LlwWrL3 avSsUDk1d0GnqtRhUG93JnESqx57HnDjEJkAjv0=
X-Google-Smtp-Source: APXvYqxoTSp4V7br4zd51auzcDuiJkKOXirWg7q+XKTxbBWuEXOx+zNfZP/LacKvMrDSElR3FYckHLW6tkYBapMgk1Q=
X-Received: by 2002:ac8:1306:: with SMTP id e6mr3194067qtj.267.1581697762312; Fri, 14 Feb 2020 08:29:22 -0800 (PST)
MIME-Version: 1.0
References: <122B138F-AA4F-4C7C-969C-755DF15F5744@chopps.org> <CAHzoHbtnCjqZjrxpYWhR8RTqbviOBDp1UEecXyAwu0kTZ1nLGA@mail.gmail.com> <fa7c6ef0-e6c7-3d14-41f3-0a64861e25e0@cisco.com> <CAHzoHbtVNMn1igrab-Q770v22JkdkJZXi86ZL7jfN775he3ZrA@mail.gmail.com> <86b274ad-e26b-029b-a36f-01febc03027a@cisco.com> <CAHzoHbvPp7CGtSGBnyY+G+=CYrU3hAxQ-=wUt9fyMH1AifWSWw@mail.gmail.com> <14f7392b-0139-0e88-a40a-45dbfcfa9ab0@cisco.com> <CAHzoHbv7MnuyP7T92_8Zd2JZKxy7VHjNPAKhFLPeZFsCQrRhxA@mail.gmail.com>
In-Reply-To: <CAHzoHbv7MnuyP7T92_8Zd2JZKxy7VHjNPAKhFLPeZFsCQrRhxA@mail.gmail.com>
From: Chris Bowers <chrisbowers.ietf@gmail.com>
Date: Fri, 14 Feb 2020 10:26:48 -0600
Message-ID: <CAHzoHbu1JzpZ6ByqUPt9tt=0AOdJsuxPRFN23aPXZLRRowgd3g@mail.gmail.com>
To: Peter Psenak <ppsenak@cisco.com>, lsr@ietf.org, "Acee Lindem (acee)" <acee@cisco.com>, lsr-ads@ietf.org, Christian Hopps <chopps@chopps.org>
Content-Type: multipart/alternative; boundary="00000000000043ce9a059e8bb586"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/1a5HOpzTlJtkZs2CiYXZDugCXBU>
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
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: Fri, 14 Feb 2020 16:29:30 -0000
All, I'm forwarding this question and subsequent response to the list because it looks like I accidentally sent it only to Peter before. Chris On Fri, Feb 7, 2020 at 4:15 PM Chris Bowers <chrisbowers.ietf@gmail.com> wrote: > Peter, > > Thanks for the clarification. > > Can you also clarify how a receiver should interpret a locator > advertisement that doesn't have a corresponding RFC7794 advertisement? > > Modifying the example below, suppose I receive a locator advertisement > from router R7 with locator = 7777::/64 and End-SID 7777::1, but R7 doesn't > originate an RFC7794 advertisement for 7777::/64. Can I conclude that > 7777::/64 is not Anycast, so it can be used as a Node-SID when constructing > TE paths as discussed below ? > > Thanks, > Chris > > On Wed, Feb 5, 2020 at 5:28 AM Peter Psenak <ppsenak@cisco.com> wrote: > >> Hi Chris, >> >> On 04/02/2020 23:17, Chris Bowers wrote: >> > Peter, >> > >> > Suppose I receive a locator advertisement from router R7 with >> > locator = 7777::/64 and End-SID 7777::1. I would like to be able to >> use >> > End-SID 7777::1 as >> > a Node-SID when constructing traffic engineered paths. That is, I want >> > to know that >> > the person or system that configured R7 believes that 7777::/64 >> > is NOT owned by more than one router within the same routing domain. >> >> ##PP >> sure, if the A-bit is not set, you should be fine to pick the SID from a >> locator. Please see below why. >> >> > >> > Since we are going with Interpretation I) below, a prefix can be (a) a >> > Node Prefix, (b) an Anycast Prefix, >> > or (c) neither of them. >> >> ##PP >> above is correct in general. >> >> However, given that locator is non-/128, N-bit does not apply per >> RFC7794. So for a locator you only have (b) or (c) and you would only >> want to avoid (b) for what you want to do above. >> >> >> > If I receive an RFC7794 advertisement from R7 >> > for 7777::/64 with N=0, A=0, >> > I can only conclude that 7777::/64 is either (a) a Node Prefix or (c) >> > neither a Node Prefix nor an >> > Anycast Prefix. Using the N-flag for a non-/128 would allow us to >> > unambiguously indicate that >> > 7777::/64 is a Node Prefix, so we can use the associated End-SID >> 7777::1 >> > in a manner >> > consistent with the knowledge that 7777::/64 is NOT owned by more than >> > one router >> > within the same routing domain. >> > >> > One other small point relates to the statement below that "locators are >> > never /128". >> > I don't think it would be very useful to configure a /128 locator, >> since >> > it only has >> > space for one SRv6 SID. However, the current text of >> > draft-ietf-lsr-isis-srv6-extensions explicitly >> > allows the Loc-Size to be 1-128. >> >> ##PP >> agree, but I don't believe we need to put any special text to state the >> above, it's obvious. >> >> thanks, >> Peter >> > >> > Thanks, >> > Chris >> > >> > On Tue, Feb 4, 2020 at 2:44 AM Peter Psenak <ppsenak@cisco.com >> > <mailto:ppsenak@cisco.com>> wrote: >> > >> > Hi Chris, >> > >> > On 03/02/2020 14:39, Peter Psenak wrote: >> > >> I think a reasonable solution would be to remove the restriction >> > >> >> > >> on the N-flag to allow it to be used for non-/128 >> > prefixes/locators. This >> > >> >> > >> would allow the three possible prefix-SIDs states to be easily >> > represented. >> > > ##PP >> > > right, that could be a possibility, which would allow SRv6 >> locator to >> > > have the "node" property, as locators are never /128. >> > >> > do you have a use case, where the locator would need a N-flag? >> > >> > I can not really think of any, so unless we have one, we better not >> > define an N-flag for a non-/128 locator prefix. >> > >> > thanks, >> > Peter >> > >> > On Mon, Feb 3, 2020 at 7:39 AM Peter Psenak <ppsenak@cisco.com >> > <mailto:ppsenak@cisco.com>> wrote: >> > >> > Hi Chris, >> > >> > adding to what Les has said. >> > Please see inline (##PP) >> > >> > On 31/01/2020 21:10, Chris Bowers wrote: >> > > Peter and Les, >> > > >> > > It seems to me that for the Node Flag in RFC7794 and the proposed >> > > Anycast Flag >> > > >> > > in draft-ietf-lsr-isis-srv6-extensions-04, we are ultimately >> > concerned with >> > > >> > > how to identify IGP-Node Segments and IGP-Anycast Segments, as >> > defined >> > > in RFC8402, >> > > >> > > the Segment Routing Architecture document. >> > > >> > > If this is the case, then the following text from RFC8402 is very >> > relevant. >> > > >> > > ============ >> > > >> > > 3.2. IGP-Node Segment (Node-SID) >> > > >> > > An IGP Node-SID MUST NOT be associated with a prefix that is >> > owned by >> > > >> > > more than one router within the same routing domain.. >> > > >> > > 3.3. IGP-Anycast Segment (Anycast-SID) >> > > >> > > .... >> > > >> > > An IGP-Anycast segment MUST NOT reference a particular node. >> > > >> > > ..... >> > > >> > > ============ >> > > >> > > This text can be interpreted in two different ways. >> > > >> > > Interpretation I) >> > > >> > > A prefix-SID can have the following three possible states. >> > > >> > > Ia) Node-SID >> > > >> > > Ib) Anycast-SID >> > > >> > > Ic) neither Node-SID nor Anycast-SID >> > >> > ##PP >> > Prefix can either be Node Prefix, Anycast Prefix or neither of them. >> > >> > >> > > >> > > Interpretation II) >> > > >> > > A prefix-SID can have the following two possible states. >> > > >> > > IIa) Node-SID >> > > >> > > IIb) Anycast-SID >> > > >> > > If Interpretation I) is correct, then I think that the current >> > encodings in >> > > >> > > draft-ietf-lsr-isis-srv6-extensions-04 do not allow us >> > > >> > > to unambiguously identify a Node-SID for a non-/128 >> > > >> > > prefix/locator. For example, the End-SIDs within a /64 locator >> > with the >> > > A-flag set could >> > > >> > > either be Ia) a Node-SID >> > >> > ##PP >> > rfc7794 does not allow the N-flag to be set for non-/128 prefix, so >> > above is not possible for /64 locator at the moment. >> > >> > If the A-flag is set, it is an anycast locator. >> > >> > >> > >> > >or Ic) neither Node-SID nor Anycast-SID. >> > >> > ##PP >> > if the A-flag was not set for /64 locator, above would be correct, >> but >> > given that the A-flag is set, it is clearly just Anycast locator. >> > >> > > >> > > I think a reasonable solution would be to remove the restriction >> > > >> > > on the N-flag to allow it to be used for non-/128 >> > prefixes/locators. This >> > > >> > > would allow the three possible prefix-SIDs states to be easily >> > represented. >> > >> > ##PP >> > right, that could be a possibility, which would allow SRv6 locator >> to >> > have the "node" property, as locators are never /128. >> > >> > thanks, >> > Peter >> > >> > >> > > >> > > If Interpretation II) is correct, then I think that the current >> > > encodings in >> > > >> > > draft-ietf-lsr-isis-srv6-extensions-04 need clarification with >> > respect to >> > > >> > > how to interpret a /128 prefix/locator advertisement with N=0, >> > A=0.. We >> > > >> > > have to decide between interpreting the End-SIDs within the >> locator >> > > >> > > as either Node-SIDs or Anycast-SIDs, since there is no third >> option. >> > > >> > > I think that interpreting the End-SIDs as Anycast-SIDs in the >> > N=0, A=0 >> > > >> > > case is preferable because it preserves backwards compatibility. >> > > >> > > >> > > Thanks, >> > > >> > > Chris >> > > >> > > >> > > >> > > On Thu, Jan 30, 2020 at 4:02 AM Peter Psenak <ppsenak@cisco.com >> > <mailto:ppsenak@cisco.com> >> > > <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>> wrote: >> > > >> > > Hi Chris, >> > > >> > > please see inline (##PP) >> > > >> > > On 29/01/2020 17:25, Chris Bowers wrote: >> > > > I would like to proposed the following text to make >> section 6 >> > > more clear. >> > > > >> > > > Thanks, >> > > > Chris >> > > > >> > > > ==================== >> > > > >> > > > (existing text) >> > > > >> > > > >> > > > 6. Advertising Anycast Property >> > > > >> > > > Both prefixes and SRv6 Locators may be configured as >> > anycast >> > > and as >> > > > >> > > > such the same value can be advertised by multiple >> > routers. It is >> > > > >> > > > useful for other routers to know that the >> > advertisement is for an >> > > > >> > > > anycast identifier. >> > > > >> > > > A new flag in "Bit Values for Prefix Attribute Flags >> > Sub-TLV" >> > > > >> > > > registry [RFC7794] is defined to advertise the anycast >> > property: >> > > > >> > > > Bit #: 4 (Suggested - to be assigned by IANA) >> > > > >> > > > Name: Anycast Flag (A-flag) >> > > > >> > > > When the prefix/SRv6 locator is configured as >> anycast, >> > > the A-flag >> > > > >> > > > SHOULD be set. Otherwise, this flag MUST be clear. >> > > > >> > > > The A-flag MUST be preserved when leaked between >> levels. >> > > > >> > > > The A-flag and the N-flag MUST NOT both be set. >> > > > >> > > > ==== start insert new text ======= >> > > > >> > > > >> > > > Certain use cases require prefixes/locators that uniquely >> > belong >> > > to a node. >> > > > >> > > > Since prefixes/locators which are not /128 should not have >> > the N >> > > bit set, >> > > > >> > > > this node local uniqueness is decided based on A bit for >> > non-/128 >> > > prefixes. >> > > >> > > ##PP >> > > above does not seem correct. Above seems to imply that for >> > non-/128 >> > > prefix, A-bit is replacement of N-bit. >> > > >> > > A-bit applies to both /128 and non-/128 prefixes equally. >> > > >> > > Current draft clearly states what to do when both N a A bits >> > are set. >> > > >> > > >> > > >> > > > >> > > > When a prefix/locator iscategorized as anycast, it >> > does not >> > > uniquely >> > > > belong >> > > > >> > > > to a node and cannot be used for such use cases. The >> > rules >> > > below >> > > > specify >> > > > >> > > > how to determine whether or not a prefix/locator >> should be >> > > treated >> > > > as anycast >> > > > >> > > > in various situations. >> > > > >> > > > >> > > > [RFC7794] contains the following restriction on the >> > > interpretation of the N-flag. >> > > > >> > > > "If the flag is set and the prefix length is NOT a >> > host prefix >> > > > >> > > > (/32 for IPV4, /128 forIPv6), then the flag MUST be >> > ignored." >> > > > >> > > > The current document does NOT modify this restriction >> > on the >> > > interpretation of >> > > > >> > > > the N-flag imposed by [RFC7794]. >> > > >> > > ##PP >> > > I don't think above text is needed. And I don't think above >> is >> > > completely correct, as we define a new case in which the >> N-bit >> > > should be >> > > ignored (when A-bit is set). >> > > >> > > >> > > > >> > > > For a prefix/SRv6 Locator advertisement with a /128 >> > > prefix/locator, >> > > > >> > > > if both N-flag and A-flag are set, the receiving >> > router MUST >> > > treat the >> > > > >> > > > prefix advertisement as anycast. >> > > >> > > ##PP >> > > we have following text in the draft already: >> > > >> > > "If both N-flag and A-flag are set in the prefix/SRv6 Locator >> > > advertisement, the receiving routers MUST ignore the >> > N-flag." >> > > >> > > >> > > >> > > > >> > > > For a prefix/SRv6 Locator advertisement with a /128 >> > > prefix/locator, >> > > > >> > > > if the N-flag and A-flag are NOT set, the receiving >> > routers >> > > > >> > > > MUST treat the prefix advertisement as anycast.. >> > > >> > > ##PP >> > > I don't think above statement is correct. Why a node cannot >> > advertise a >> > > /128 prefix which is not an anycast one and does not have a >> > N-bit set? >> > > >> > > >> > > >> > > > This rule ensures the >> > > > >> > > > correct interpretation of a prefix advertisement >> > originated by >> > > > >> > > > a router that is not SRv6 capable and originates a >> legacy >> > > > >> > > > Prefix Attribute Flags Sub-TLV based on [RFC7794] >> alone. >> > > > >> > > > For a prefix/SRv6 Locator advertisement with a >> > prefix/locator >> > > that >> > > > >> > > > is NOT /128, the N-flag must be ignored, so the >> > setting of the >> > > > >> > > > A-flag determines the anycast treatment of the prefix >> > > advertisement. >> > > >> > > ##PP >> > > A-flag does that regardless of the length of the prefix. >> > > >> > > >> > > > >> > > > The Prefix Attribute Flags Sub-TLV can be carried in >> > the SRv6 >> > > > Locator TLV >> > > > >> > > > as well as the Prefix Reachability TLVs. When a >> router >> > > originates >> > > > >> > > > both the Prefix Reachability TLV and the SRv6 Locator >> > TLV for >> > > a given >> > > > >> > > > prefix, and the router is originating the Prefix >> Attribute >> > > Flags Sub-TLV >> > > > >> > > > in one of the TLVs, the router SHOULD advertise >> identical >> > > versions of the >> > > > >> > > > Prefix Attribute Flags Sub-TLV in both TLVs. >> > > >> > > ##PP >> > > Above seems a good suggestion. Will add it. >> > > >> > > > >> > > > >> > > > >> > > > If a router receives one Prefix Attribute Flags >> > Sub-TLV in the >> > > > >> > > > Prefix Reachability TLV and another in the SRv6 >> > Locator TLV, >> > > the router should >> > > > >> > > > use the prefix attribute flags received in the Prefix >> > > Reachability TLV. >> > > >> > > ##PP >> > > above contradicts what you suggest in the previous paragraph, >> > where you >> > > suggest we need to advertise with both prefix and locator, >> > and here you >> > > suggest we ignore what we received in the locator. >> > > >> > > Are you talking about the case where the content of the >> Prefix >> > > Attribute >> > > Flags Sub-TLV is different in prefix vs locator? >> > > > >> > > > >> > > > >> > > > If a router receives a Prefix Attribute Flags Sub-TLV >> > in the >> > > > >> > > > Prefix Reachability TLV but not in the SRv6 Locator >> > TLV, the >> > > router should >> > > > >> > > > use the prefix attribute flags received in the Prefix >> > > Reachability TLV. >> > > >> > > ##PP >> > > do we really need this? If the originator does the right >> > thing, then we >> > > don't have the problem. Cross referencing data between >> > different TLVs >> > > complicates the implementations. >> > > >> > > >> > > > >> > > > >> > > > >> > > > If a router receives a Prefix Attribute Flags Sub-TLV >> > in the >> > > > >> > > > SRv6 Locator TLV but not in the Prefix Reachability >> TLV, >> > > > >> > > > the router should use the prefix attribute flags >> > received in >> > > the SRv6 Locator TLV. >> > > >> > > ##PP >> > > same as above. >> > > >> > > thanks, >> > > Peter >> > > >> > > > >> > > > ==== end insert new text ========= >> > > > >> > > > The same prefix/SRv6 Locator can be advertised by >> multiple >> > > routers. >> > > > >> > > > If at least one of them sets the A-Flag in its >> > advertisement, the >> > > > >> > > > prefix/SRv6 Locator SHOULD be considered as anycast.. >> > > > >> > > > >> > > > >> > > > =================== >> > > > >> > > > >> > > > On Tue, Jan 21, 2020 at 6:15 PM Christian Hopps >> > > <chopps@chopps.org <mailto:chopps@chopps.org> >> > <mailto:chopps@chopps.org <mailto:chopps@chopps.org>> >> > > > <mailto:chopps@chopps.org <mailto:chopps@chopps.org> >> > <mailto:chopps@chopps.org <mailto:chopps@chopps.org>>>> wrote: >> > > > >> > > > This begins a 2 week WG Last Call, ending after Feb 4, >> > 2020, for >> > > > draft-ietf-lsr-isis-srv6-extensions >> > > > >> > > > >> > > >> > https://datatracker.ietf. >> .org/doc/draft-ietf-lsr-isis-srv6-extensions/ >> > > > >> > > >> > < >> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/> >> > > > >> > > > Authors please indicate if you aware of any other IPR >> > beyond >> > > what is >> > > > posted: >> > > > >> > > > https://datatracker.ietf.org/ipr/3796/ >> > > > >> > > > Thanks, >> > > > Chris & Acee. >> > > > _______________________________________________ >> > > > Lsr mailing list >> > > > Lsr@ietf.org <mailto:Lsr@ietf.org> <mailto:Lsr@ietf.org >> > <mailto:Lsr@ietf.org>> <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org> >> > > <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>>> >> > > > https://www.ietf.org/mailman/listinfo/lsr >> > > > >> > > >> > >> >>
- [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-exten… Christian Hopps
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Peter Psenak
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… bruno.decraene
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Acee Lindem (acee)
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Zafar Ali (zali)
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Mankamana Mishra (mankamis)
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Paul Wells (pauwells)
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Huzhibo
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Ketan Talaulikar (ketant)
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Clarence Filsfils (cfilsfil)
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… stefano previdi
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Huaimo Chen
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Xiejingrong (Jingrong)
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… bruno.decraene
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Les Ginsberg (ginsberg)
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Les Ginsberg (ginsberg)
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… bruno.decraene
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Les Ginsberg (ginsberg)
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Yingzhen Qu
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Lizhenbin
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Zhuangshunwan
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Peter Psenak
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… bruno.decraene
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Peter Psenak
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… bruno.decraene
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Chris Bowers
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Les Ginsberg (ginsberg)
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Peter Psenak
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Chris Bowers
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Les Ginsberg (ginsberg)
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Ahmed Bashandy
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Satoru Matsushima
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Peter Psenak
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Dongjie (Jimmy)
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Peter Psenak
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Chris Bowers
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Peter Psenak
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Ahmed Bashandy
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Chris Bowers
- Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-e… Chris Bowers