I am not aware of any undisclosed IPR on this draft.
Chris
On Tue, Jul 16, 2024 at 11:21 AM Yingzhen Qu
wrote:
> Hi Authors,
>
> We can't close this WGLC yet as we are still missing responses from the
> following authors to the IPR call:
>
> Parag Kaneriya
>
> Sh
I support publication of this document, as a co-author.
Chris
On Mon, Nov 22, 2021 at 1:47 PM Acee Lindem (acee) wrote:
> This begins the WG Last for draft-ietf-lsr-isis-flood-reflection-05.
> Please post your support or objection to this list by 12:00 AM UTC on Dec 14th
> , 2021. Also please p
LSR,
I am not aware of any undisclosed IPR related to this draft.
Chris
On Mon, Nov 22, 2021 at 8:13 AM Acee Lindem (acee) wrote:
> Draft Authors and Contributors,
>
>
>
> Are you aware of any IPR that applies to
> draft-decraeneginsberg-lsr-isis-fast-flooding-00?
>
>
>
> If so, has this IPR
LSR,
I am not aware of any undisclosed IPR related to this draft.
Chris
On Mon, Nov 22, 2021 at 1:52 PM Acee Lindem (acee) wrote:
> Authors, Contributors,
>
>
>
> Are you aware of any IPR that applies to
> draft-ietf-lsr-isis-flood-reflection-05?
>
>
>
> If so, has this IPR been disclosed in c
I support WG adoption of draft-chen-isis-ttz as experimental.
Chris
On Tue, Aug 18, 2020 at 9:17 AM Acee Lindem (acee) wrote:
>
>
> Based on the discussions in the last meeting and on the mailing list
> regarding draft-chen-isis-ttz-11, the chairs feel that there are enough
> differences with d
I support WG adoption of draft-przygienda-lsr-flood-reflection. The only
IPR that I am aware of that may be related to this draft has already been
disclosed.
Chris
On Wed, Jun 10, 2020 at 2:29 PM Christian Hopps wrote:
> This begins a 2 week WG adoption call for the following draft:
>
> http
I support WG adoption of draft-przygienda-lsr-flood-reflection.
Chris
On Thu, Jun 4, 2020 at 1:05 PM Tony Przygienda wrote:
> I would like to officially call out for adoption of
> https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01 as
> WG document
>
> At this point in time flo
lue in the Loc-Size field?
Chris
On Wed, Mar 25, 2020 at 9:49 AM Peter Psenak wrote:
> Chris,
>
> please see inline:
>
>
> On 23/03/2020 17:39, Chris Bowers wrote:
> > Peter,
> >
> > The proposed SRv6 SID Structure Sub-Sub-TLV has several problems.
> >
ter Psenak wrote:
> Hi Chris,
>
> On 12/03/2020 15:58, Chris Bowers wrote:
> > Peter,
> >
> > I think that the SRv6 SID Structure Sub-Sub-TLV should be removed from
> > draft-ietf-lsr-isis-srv6-extensions. I think that we should leave the
> > ability to includ
-network-programming authors since we
> are now back to discussing the ISIS extensions.
>
>
>
> Please check inline below.
>
>
>
> *From:* Chris Bowers
> *Sent:* 05 March 2020 21:53
> *To:* Ketan Talaulikar (ketant)
> *Cc:* Ketan Talaulikar (ketant) ; lsr@iet
g. Length for an endpoint behavior that doesn't use an
argument? Are there any use cases envisioned where an ISIS speaker needs
to know the Arg. Length ?
Thanks,
>
> Ketan
>
>
>
> *From:* Chris Bowers
> *Sent:* 02 March 2020 23:39
> *To:* Ketan Talaulikar (ke
LSR,
I would like to update the implementation section of
draft-ietf-lsr-isis-srv6-extensions to read:
11.3. Juniper
Juniper's ISIS SRv6 implementation supports the following
functionalities:
Types of SID supported: End, End.X, LAN End.X
Intra/Inter area/level support:
Clarification inline [Bruno]
>
>
>
> *From**:* Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
> *Sent:* Friday, February 28, 2020 11:11 AM
> *To:* DECRAENE Bruno TGI/OLN; Ketan Talaulikar (ketant); Chris Bowers
> *Cc:* lsr@ietf.org; SPRING WG List;
> draft-ietf-spring-sr
wrote:
> Hi Chris,
>
> On 27/02/2020 17:54, Chris Bowers wrote:
> > LSR WG,
> >
> > Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the SRv6
> > SID Structure Sub-Sub-TLV. In particular, it defines encoding for the
> > locator block length and th
LSR WG,
Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the SRv6 SID
Structure Sub-Sub-TLV. In particular, it defines encoding for the locator
block length and the locator node length. The text refers to
[I-D.ietf-spring-srv6-network-programming] for the definition of these
concepts.
All,
The current text from Section 5 (below) doesn't specify if locators
associated with algorithms with values 1-126 SHOULD or SHOULD NOT be
advertised in Prefix Reachability TLVs. In particular, it seems like the
text should specify the expected behavior for locators associated with
algorithm 1
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 Sat, Feb 8, 2020 at 3:25 AM Peter Psenak wrote:
> Hi Chris,
>
> On 07/02/2020 23:15, Chris Bowers wrote:
> > Peter,
&g
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
wrote:
> Peter,
>
> Thanks for the clarification.
>
> Can you also clarify how a recei
Thanks. The proposed text below looks good to me.
Chris
On Wed, Feb 5, 2020 at 5:13 AM Peter Psenak wrote:
> Hi Chris,
>
> On 05/02/2020 00:27, Chris Bowers wrote:
> > LSR,
> >
> > I have some more feedback on draft-ietf-lsr-isis-srv6-extensions-04 that
> >
LSR,
I have some more feedback on draft-ietf-lsr-isis-srv6-extensions-04 that I
am putting in a separate thread so as not to confuse the other thread
related to N and A flags.
===
The end of Section 5 points out several issues that can result in
forwarding not working correctly. The reader m
prefix.
>
> thanks,
> Peter
>
On Mon, Feb 3, 2020 at 7:39 AM Peter Psenak 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 th
,
Chris
On Thu, Jan 30, 2020 at 4:02 AM Peter Psenak 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.
>
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
23 matches
Mail list logo
