If they are new leaf values why not use the correct no-zone variant, what's the
harm in doing it right? It has a nice side effect of basically restricting the
base spec zone values to no-zone only. :)
Thanks,
Chris.
[wg member]
> On Apr 4, 2022, at 12:30, Acee Lindem (acee)
> wrote:
>
> In t
with a large blast radius (not saying
it's wrong), and perhaps most importantly is also outside of LSR WG control. :)
Thanks,
Chris.
[wg-member]
> Thanks,
> Acee
>
> On 4/5/22, 9:33 AM, "Christian Hopps" wrote:
>
>If they are new leaf values why not us
t, Mar 26, 2022 at 6:42 AM Christian Hopps
wrote:
Robert Raszuk writes:
> Les,
>
> I don't think this is noise.
>
> Your examples are missing key operational consideration .. Link
> attribute applicable to ANY application may be advertised
Randy Presuhn writes:
Hi -
Let me get this straight. WG A standardized types X and Y years ago,
and support for these has presumably been implemented in some number
of tools, which in turn have been used to develop some unknowable
number of products, whose deployment is even more unknowable
Randy Presuhn writes:
30+ years of tradition (and BCP) not permitting types to be changed
after they've been published, I suppose, motivated by our total lack
of control over unpublished usage of these types after their definitions
have been published.
If there were actually something wrong w
Nice. I think this a fine way forward with or without step 2. I say leave out
the 2 years (or any) deadline, and let people argue over how and when to do
step 2 for however long it takes.
Given the questions already raised on this thread, we should probably add
explicit guidance to RFC6991-b
Hi Folks,
This begins a 2 week WG Adoption Call for the following draft:
https://datatracker.ietf.org/doc/draft-fox-lsr-ospf-terminology/
Please indicate your support or objections by May 9th, 2022.
Authors, please respond to the list indicating whether you are aware of any IPR
that applies t
Speaking as someone who at one point worked for an operator trying to use YANG to actuall
configure a large network (services and devices), and also having interacted with the
openconfig folks over the years. I find your perspective, if I understand it, that being
too "loose" with things will
The document has been adopted.
Authors, please republish this version of the document as:
draft-ietf-lsr-ospf-terminology-00
Thanks,
Chris.
Christian Hopps writes:
Hi Folks,
This begins a 2 week WG Adoption Call for the following draft:
https://datatracker.ietf.org/doc/draft-fox
Given the simplicity of this document and having received no objections or
edits prior to or during the adoption call we'll be moving it immediately to
WGLC...
This begins a 2 week WG Last Call, ending Jun 19th, 2022, for:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-terminology/
Aut
> On Jun 13, 2022, at 14:29, Tony Li wrote:
>
> It used to be that the path to publication was brief. We’ve now ossified to
> the point where a technology can go through an entire life-cycle before we
> act.
Yes, but we also seemed to publish everything as Informational then too. :-D
Than
> On Jun 14, 2022, at 08:41, Christian Hopps wrote:
>
>
>
>> On Jun 13, 2022, at 14:29, Tony Li wrote:
>>
>> It used to be that the path to publication was brief. We’ve now ossified to
>> the point where a technology can go through an entire life-cycle
> On Jun 14, 2022, at 04:59, Van De Velde, Gunter (Nokia - BE/Antwerp)
> wrote:
>
> What is wrong with simply not doing summaries and forget about these PUAs to
> pinch holes in the summary prefixes? this worked very well during last two
> decennia. Are we not over-engineering with PUAs?
1
I think Experimental is a good way to go with this as well.
Thanks,
Chris.
[as wg-member]
"Les Ginsberg (ginsberg)" writes:
John -
Thanx for the information.
I think what is relevant as regards the dynamic-flooding draft is that we may
be prematurely burying it.
It is true, as Tony has sta
Huzhibo writes:
Hi 6man and LSR:
This email was only sent to LSR.
Thanks,
Chris.
We submitted a draft of the DataPlane extension Topo ID: https://
tools.ietf.org/id/draft-li-6man-topology-id-00.txt
https://tools.ietf.org/id/draft-hu-lsr-igp-ca-flex-algorithm-00.txt
This draft sloves th
Robert Raszuk writes:
Btw this independent attempt by two WG groups to normalize link state
data is a clear proof that the YANG model has failed here.
I'm not sure which "YANG model" you are referring to here (perhaps you just
mean YANG in general?), but I don't think YANG itself has failed
Robert Raszuk writes:
Peter,
In the scenario described there is really nothing to be tuned as you
are limited by the quality of local telco carriers.
Apparently you are not willing to consider it. Thank you.
First, I don't like any of these unreachable things, and so I don't want my
com
single hop BFD.
Thanx.
Les
From: Lsr On Behalf Of Robert Raszuk
Sent: Sunday, July 17, 2022 4:49 AM
To: Christian Hopps
Cc: Peter Psenak (ppsenak) ; lsr
Subject: Re: [Lsr] UPA
Hi Christian,
> It seems you saying
have fever and those ABRs in turn issue
a UPA or SPA (suspicious) messages to remote guys.
I am not seeing it as local area trigger must be IGP native even if
further flooding would be.
On Sun, Jul 17, 2022 at 11:18 PM Christian Hopps
wrote:
I feel like this is so obvious that I must stil
FWIW, even if you can point to a real example of this bad network
design/operation we should absolutely not feel compelled to design protocols or
solutions to support it.
Thanks,
Chris.
[as wg-member, all my replies were but felt like I should be explicit here]
Christian Hopps writes
Hi Folks,
This begins a 2 week WG Adoption Call for the following draft:
https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/
Please indicate your support or objections by August 22nd, 2022.
Authors, please respond to the list indicating whether you are aware of any IPR
that appl
Hi Folks,
This begins a 2 week WG Adoption Call for the following draft:
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-rfc8920bis/
Please indicate your support or objections by August 22nd, 2022.
Authors, please respond to the list indicating whether you are aware of any IPR
that appli
s using RFC8919.
Peter
Best Regards
Aijun Wang
China Telecom
-Original Message-
From: lsr-boun...@ietf.org On Behalf Of Christian
Hopps
Sent: Monday, August 8, 2022 6:17 PM
To: lsr@ietf.org
Cc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org
Subject: [Lsr] WG adoption call for dra
solution will obsolete RFC8919 and RFC8920 together.
The bis draft are just repeating its precedent, and will be replaced also
accordingly, unless it solves the issues that I mentioned.
Aijun Wang
China Telecom
On Aug 9, 2022, at 21:50, Christian Hopps wrote:
We were asked by the AD to process
Christian Hopps writes:
[[PGP Signed Part:Good signature from 2E1D830ED7B83025 Christian Hopps
(trust ultimate) created at 2022-08-09T20:50:17-0400 using
RSA]]
Aijun Wang writes:
Hi, Chris:
If so, let’s adopt them directly then, why seek the opinions from the WG?
This is a valid
"Sabrina Tanamal via RT" writes:
Chris and Hannes (cc: lsr WG),
Reviewed new addition, looks OK.
Thanks,
Chris.
As the designated experts for the Sub-TLVs for TLVs Advertising Neighbor
Information registry, can you review the proposed registration in
draft-ietf-lsr-isis-rfc5316bis for
> On Sep 7, 2022, at 17:05, Acee Lindem (acee)
> wrote:
>
> Hi Renato,
>
> Thanks for you comments. However, at this point in the cycle, we’re not going
> to make any additions to the model since it is has already been through the
> complete review cycle. We will however fix things that a
I also approve the registration of the X-bit.
"Les Ginsberg (ginsberg)" writes:
Sabrina -
I approve the registration for the X-bit as defined in Section 18.4.9 in the
draft.
Les
-Original Message-
From: Sabrina Tanamal via RT
Sent: Friday, September 16, 2022 1:57 PM
Cc: Les
[As wg-member]
I think the draft should include a table of all top level TLVS as rows and for
columns we have
- "Implicit Single TLV Only" (e.g., no key info)
- "Implicit Multi-TLV Only"
- "Explicit Single TLV Only"
- "Explicit Multi-TLV-Allowed"
This draft then would *explicitly* cover the e
[As wg-member] --- inline...
"Les Ginsberg (ginsberg)" writes:
Chris -
-Original Message-
From: Christian Hopps
Sent: Monday, October 3, 2022 8:37 AM
To: Les Ginsberg (ginsberg)
Cc: Robert Raszuk ; Tony Li ; Henk Smit
; lsr@ietf.org
Subject: Re: [Lsr] New Version No
berg (ginsberg)" writes:
Chris -
Inline.
-Original Message-
From: Christian Hopps
Sent: Monday, October 3, 2022 5:52 PM
To: Les Ginsberg (ginsberg)
Cc: Christian Hopps ; Robert Raszuk
; Tony Li ; Henk Smit
; lsr@ietf.org
Subject: Re: [Lsr] New Version Notifi
"Les Ginsberg (ginsberg)" writes:
Chris -
Please see inline.
[...]
> MP-TLVs are not sent just because an implementation supports them.
> They are sent because the current configuration requires them.
The SW also has the option to alert the operator that their configuration is
not suppo
Tony Li writes:
Hi all,
On Oct 3, 2022, at 8:37 AM, Christian Hopps wrote:
[As wg-member]
I think the draft should include a table of all top level TLVS as rows and for
columns we have
- "Implicit Single TLV Only" (e.g., no key info)
- "Implicit Multi-TLV Only"
-
"Les Ginsberg (ginsberg)" writes:
RFC3787 which was published 1 month prior to RFC3784 which RFC5305
replaced.
"5. Migration from Narrow Metrics to Wide . . ."
[LES:] Indeed - RFC 3787 - quite a useful document.
Note this section was based on input from actual implementations. So folks i
Peter Psenak writes:
Tony, Les,
I believe we can all agree that we do not want to change the behavior of
existing implementations that support MP-TLVs based on the advertisements of the
MP-capability from other routers - it would break existing networks. Even the
text in the MP-TLV draft does
Peter Psenak writes:
Chris,
On 06/10/2022 18:34, Christian Hopps wrote:
Peter Psenak writes:
Tony, Les,
I believe we can all agree that we do not want to change the behavior of
existing implementations that support MP-TLVs based on the advertisements of the
MP-capability from other
there).
Tony I think you may have interpreted these differently?
Thanks,
Chris.
Les
-Original Message-
From: Christian Hopps
Sent: Thursday, October 6, 2022 9:34 AM
To: Peter Psenak (ppsenak)
Cc: Tony Li ; Les Ginsberg (ginsberg)
;
Christian Hopps ; Robert R
It sounds like you're talking about networks defined to work by SE not by
standards. I don't want to argue about this, so perhaps we can agree to
disagree.
Thanks,
Chris.
[as wg-member]
"Les Ginsberg (ginsberg)" writes:
Chris -
-Original Message-----
From: C
otocol extensions
in order to send MP-TLVs.
As regards deployment controls, I have no problem with recommending that
implementations provide ways to control the enablement of the sending of
MP-TLVs.
Les
-Original Message-
From: Christian Hopps
Sent: Thursday, October 6, 2022 3
"Les Ginsberg (ginsberg)" writes:
Tony -
Your summarization is incorrect.
The proposal is to advertise a advisory message that indicates that a node is
ready to receive MP-TLVs. It prohibits nothing.
[LES:] That is what you are proposing - but others in the thread have proposed
other i
that should continue - but it MUST NOT alter the format of TLVs or
the rules as to when TLVs can be advertised.
Les
-Original Message-
From: Lsr On Behalf Of Christian Hopps
Sent: Friday, October 7, 2022 4:17 PM
To: Les Ginsberg (ginsberg)
Cc: Tony Li ; Christian Hopps ; Peter
"Les Ginsberg (ginsberg)" writes:
Chris -
I am a bit concerned that this is degenerating into a
non-constructive argument. We can disagee but hopefully each post
helps move the discussion along in some way.
Please see inline.
-Original Message-
From: Chris
Christian Hopps writes:
I simply turned your question around and asked: should conforming
implementations be penalized?
[LES:] Are you claiming that the absence of an explicit statement
regarding support of MP for a given TLV is equivalent to a
prohibition against sending them (which
Christian Hopps writes:
Why did we explicitly define multi-part TLVs?
I offer this as an answer to my own question:
We have the standard (RFC5303) which defined sub-tlvs in IS-IS, and says this in "3.
The Extended IS Reachability TLV"
"There is no defined mechanism fo
Christian Hopps writes:
Christian Hopps writes:
Why did we explicitly define multi-part TLVs?
I offer this as an answer to my own question:
We have the standard (RFC5303) which defined sub-tlvs in IS-IS, and says this in "3.
The Extended IS Reachability TLV"
That should
riginal Message-
From: Lsr On Behalf Of Christian Hopps
Sent: Monday, August 8, 2022 3:17 AM
To: lsr@ietf.org
Cc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org
Subject: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02
Hi Folks,
This begins a 2 week WG Adoption Call fo
The document is adopted. Pleas resubmit as:
draft-ietf-lsr-rfc8919bis-00
Thanks,
Chris.
Christian Hopps writes:
[[PGP Signed Part:Good signature from 2E1D830ED7B83025 Christian Hopps
(trust ultimate) created at 2022-08-08T06:20:51-0400 using
RSA]]
Hi Folks,
This begins a 2 week WG
The document is adopted. Pleas resubmit as:
draft-ietf-lsr-rfc8920bis-00
Thanks,
Chris.
Christian Hopps writes:
[[PGP Signed Part:Good signature from 2E1D830ED7B83025 Christian Hopps
(trust ultimate) created at 2022-08-08T06:21:54-0400 using
RSA]]
Hi Folks,
This begins a 2 week WG
sage-
From: bruno.decra...@orange.com
Sent: Monday, October 24, 2022 6:22 AM
To: Les Ginsberg (ginsberg) ; Christian Hopps
Cc: Peter Psenak (ppsenak) ; Tony Li
; Robert Raszuk ; Henk Smit
; lsr@ietf.org
Subject: RE: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi
rd productively.
Thanks,
Chris.
Les
-Original Message-
From: Christian Hopps
Sent: Tuesday, October 25, 2022 2:29 PM
To: Les Ginsberg (ginsberg)
Cc: bruno.decra...@orange.com; Christian Hopps ;
Peter Psenak (ppsenak) ; Tony Li ;
Robert Raszuk ; Henk Smit ;
lsr@ietf.org
Subject: Re: [L
> On Nov 9, 2022, at 2:13 PM, Peter Psenak
> wrote:
>
> On 09/11/2022 14:56, David Lamparter wrote:
>> On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
>>> I guess I'd like to understand what one would accomplish with further
>>> specification of prefix reachable? What requi
d for other purposes then building a
reachability table.
Thx,
R.
On Sat, Nov 12, 2022 at 6:47 AM Christian Hopps
wrote:
> On Nov 9, 2022, at 2:13 PM, Peter Psenak wrote:
>
> On 09/11/2022 14:56, David Lamparter wrote:
>> On Wed, Nov 09, 2022 at 01:27:
"Les Ginsberg (ginsberg)" writes:
Chris/David -
I was replying to Peter saying that implementations are using the max metric
announcements to avoid sending traffic to overload routers.
[LES:] Are you claiming this because you know this to be true - or are you just
speculating that an imp
This begins a 2 week WG Last Call, ending Dec 21, 2022, for:
https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/
Authors,
Please indicate to the list, your knowledge of any IPR related to this work.
Thanks,
Chris.
signature.asc
Description: PGP signature
__
NOTE Please disregard this email the next one will include the correct WG
document. :)
Thanks,
Chris.
> On Dec 7, 2022, at 08:20, Christian Hopps wrote:
>
>
> This begins a 2 week WG Last Call, ending Dec 21, 2022, for:
>
> https://datatracker.ietf.org/doc/draft-ginsb
This begins a 2 week WG Last Call, ending Dec 21, 2022, for:
https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8919bis/
Authors,
Please indicate to the list, your knowledge of any IPR related to this work.
Thanks,
Chris.
signature.asc
Description: PGP signature
__
This begins a 2 week WG Last Call, ending Dec 21, 2022, for:
https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8920bis/
Authors,
Please indicate to the list, your knowledge of any IPR related to this work.
Thanks,
Chris.
signature.asc
Description: PGP signature
__
[as wg-member]
I've finally gotten a chance to review this.. Sorry for taking so long.
(1) I may be outside rough consensus on wanting to mandate a upgrade path, which is
unfortunate. I think we could advertise an "MP-TLV accepted" capability and not
process implicit MP-TLVS locally unless eve
Hi Chris,
Just want to note one mis-undertanding below..
Chris Parker writes:
Even if we were to talk about level 1, it is possible for an L1
router to be in two IS-IS areas at once, which is a way of creating a
single L1 topology, a single LSP flooding domain.
An IS-IS router instance can
anual area addresses" which starts:
7.1.5 Manual area addresses:
Within a routeing domain, it is often convenient to associate
more than one area address with an area.
Thanks,
Chris.
[as wg-member]
All the best
Chris
On Wed, Feb 15, 2023 at 10:16 AM Christian Hopps
wr
"Les Ginsberg (ginsberg)" writes:
Chris P -
Chris H and I are saying the same thing.
However, regarding the network diagram you shared...
Comment 1:
Node Chianti L1 only Area Address 49.0001
Node Cabernet L1 only Area Address 49.0003
There is no connectivity directly between these nodes.
This begins a 2 week WG Last Call, ending Mar 26, 2023, for:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
Authors,
Please indicate to the list, your knowledge of any IPR related to this work.
Thanks,
Chris.
signature.asc
Description: PGP signature
__
Hi,
So I agree that using this new container TLV along with old TLVs doesn't help.
However, it is worth nothing that if *only* the container TLV was used (i.e., once a TLV
became too large it would be removed and placed inside container TLVs) then it would
actually represent a safer way to de
against html I typically just load these email
into chrome when I need to read them..
-Original Message-
From: Christian Hopps
Sent: Tuesday, March 28, 2023 7:27 AM
To: Les Ginsberg (ginsberg)
Cc: Huaimo Chen ; draft-chen-lsr-isis-big-
tlv.auth...@ietf.org; lsr@ietf.org
Subject: Re:
d on the local configuration, needs to be able to receive
>> > sub-TLVs 1,3,5,7,9 from A.
>> >
>> > Node C, based on local configuration, needs to be able to receive
>> > sub-TLVs 2,4,6,8,10 from A.
>> >
>> >
>> >
>> > The
"Les Ginsberg (ginsberg)" writes:
Chris -
-Original Message-----
From: Christian Hopps
Sent: Tuesday, March 28, 2023 11:40 PM
To: Les Ginsberg (ginsberg)
Cc: Christian Hopps ; Huaimo Chen
; draft-chen-lsr-isis-big-tlv.auth...@ietf.org;
lsr@ietf.org
Subject: Re: [Lsr] Comment
Peter Psenak writes:
Liyan,
On 13/04/2023 06:50, Liyan Gong wrote:
Hi All，
Thanks for your discussion, here are some informations to help understanding
better.
1. About the application scenario, please refer to the following draft.
https://datatracker.ietf.org/doc/draft-gong-teas-hierarchica
using SRGB
(especially in different range) plus index is indeed, by nature, similar to
offset approach.
Rgds
louis
-Original Message-----
From: Christian Hopps
Sent: Monday, April 17, 2023 8:25 PM
To: Peter Psenak
Cc: Liyan Gong ; Louis Chan ;
Ketan Talaulikar ; Krzysztof Szarkowicz
; Rob
Sorry forgot to add this was "as wg-member".
Thanks,
Chris.
[as wg-member]
Christian Hopps writes:
Louis Chan writes:
Hi Christian,
Three comments on flooding enhancement
- It is discussed in IS-IS domain. How about OSPF?
- The proposed offset solution works for both.
Louis Chan writes:
Hi All,
Here is an email I would like to address multiple comments and
issues.
My comment starts with [lc]
/Louis
1. About the weakest control plane
From Chris. H
Operators with 1000s of routers and routers with 1000s of interfaces
don't create flooding choke-points
silly network design, operators will not do this, and we do not modify or design
our routing protocols to support silly network designs.
Thanks,
Chris.
[as wg-member]
/Louis
-Original Message-----
From: Christian Hopps
Sent: Friday, April 21, 2023 5:08 AM
To: Louis Chan
Cc: Les Ginsberg (gi
The WGLC has concluded. The document will be forwarded to IESG for publication.
Thanks,
Chris.
Christian Hopps writes:
[[PGP Signed Part:Good signature from 2E1D830ED7B83025 Christian Hopps
(trust ultimate) created at 2023-03-12T14:36:41-0400 using
RSA]]
This begins a 2 week WG Last
> On Jul 13, 2023, at 17:23, Acee Lindem wrote:
>
> Hi Renato,
>
>>
>> Lastly, this might just be a small nitpick of mine, but I don't think
>> having a "length" leaf for all TLVs and Sub-TLVs adds much value. In
>> my opinion, it's only relevant for unknown TLVs that couldn't be
>> decoded;
This begins a 2 week WG Last Call, ending Sep 1, 2023, for:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
Authors,
Please indicate to the list, your knowledge of any IPR related to this work.
Thanks,
Chris.
signature.asc
Description: PGP signature
_
Hi Sharmila,
Can you please reply to this thread indicating your knowledge of any IPR
related to this work?
Thanks,
Chris.
Christian Hopps writes:
[[PGP Signed Part:Good signature from 2E1D830ED7B83025 Christian Hopps
(trust ultimate) created at 2023-08-18T20:27:22-0400 using
RSA
The WGLC has ended successfully, and the document will be submitted to the IESG.
Thanks,
Chris.
Christian Hopps writes:
[[PGP Signed Part:Good signature from 2E1D830ED7B83025 Christian Hopps
(trust ultimate) created at 2023-08-18T20:27:22-0400 using
RSA]]
This begins a 2 week WG Last
My point is that people are not using the same definition of backward compatibility. This
is why this argument over it is going in circles. I'm suggesting that when you consider
each persons definition of backward compatibility, then neither side is wrong. So saying
things like "No. You are wr
Huaimo Chen writes:
[HC]: It seems that the implementation of an idea/solution in a draft
is not required by LSR WG for the draft to be adopted, or even for
the draft to become RFC.
[Chair hat on]
It is true that we don't need implementations in order to adopt drafts;
however, there (norm
Tony Przygienda writes:
On Thu, Dec 7, 2023 at 7:52 AM Gyan Mishra
wrote:
...
Gyan> What Bruno is trying to provide I think strengthens the
draft with the MUST normative language for enable/disable
configuration controls. As this is pre standard implementation
if the
The adoption call for has ended.
The document is adopted, and with a strong consensus.
Authors please resubmit as draft-ietf-lsr-multi-tlv-00.
There have been other solutions presented during the adoption call as well as
previously, but as is clear from this adoption call the other solutions
[As WG Co-Chair]
Hi Folks,
Before posting support reasons please read and considerl
*all* the email in the archive covering the first failed
adoption call.
https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/
https://www.mail-archive.com/search?l=lsr%40ietf.org&q=stub+link
"duzongp...@foxmail.com" writes:
Hi, all
I support the adoption. I agree with the idea:
Considering there are many links and complex interconnections
among the ASBRs that located in different AS domains, the proposed
protocol extension can certainly ease the recovery and management of
Liyan Gong writes:
Hi WG,
I Support its adoption.
Currently there is no automatic and error-proof way to get the
related information of the other ends for inter-as links, it is
difficult for operator to rebuild the complex inter-as topology.
The proposed protocol extension in this draft ca
that there exists inter-AS TE
> solutions(RFC9346/RFC5392), but how many operators have deployed them in the
> network? Are anyone considering the reason that hinders their deployments?
>
> Aijun Wang
> China Telecom
>
>> On Jan 15, 2024, at 17:35, Christian Hopps wrote:
I am not aware of any "inherited" requirement. We link documents (X replaces Y)
in the datatracker by choosing whatever document we want as "replaces". You can
post the document with whatever name changes you want and the chairs can either
accept it and it gets posted or not.
Thanks,
Chris.
>
[as wg-member]
Hi Jie,
If different topologies need to use different members of a link bundle, then
the link bundle has been incorrectly defined. You should re-bundle your links
according to their expected topological use and then everything just works w/o
any new tech needed. "KISS" seems to
[as wg-member]
Any reason not to use Expert Review? FWIW, this is the only registry for IS-IS
that doesn't.
Thanks,
Chris.
Tony Li writes:
Hi folks,
This is a proposal to change the registration procedure on the IS-IS
Neighbor Link-Attribute Bit Values registry.
It’s currently “Standards
This begins a 2 week WG Last Call, ending Monday July 1st, 2024, for:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags
Authors,
Please indicate to the list, your knowledge of any IPR related to this work.
Thanks,
Chris.
signature.asc
Description: PGP signature
__
> On Jun 30, 2020, at 2:33 AM, tony...@tony.li wrote:
>
>
> Hi all,
>
> The authors are on-board with this round of suggestions from Les. Could I
> get a review by one more of our Designated Experts before we update the draft?
So:
- Top Level Area Proxy TLV
- can be used to communicate a
Hi Huaimo,
Can you speak to the differences of this with Area Proxy? They are similar
solutions, right?
There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i
found it confusing to have this document also talking about TTZ for OSPF; is it
redefining it, updating it, jus
> On Jul 7, 2020, at 12:00 PM, Huaimo Chen wrote:
>
> Hi Chris,
>
> Thank you very much for your questions.
> My answers/explanations are inline below with prefix [HC].
>
> Best Regards,
> Huaimo
> From: Christian Hopps
> Sent: Tuesday, July 7, 20
roxy are similar to
> the above 1). 2). 3). and 5) between OSPF TTZ and OSPF Area Proxy.
>
> Best Regards,
> Huaimo
> From: Acee Lindem (acee)
> Sent: Tuesday, July 7, 2020 3:41 PM
> To: Huaimo Chen ; Christian Hopps
>
> Cc: lsr@ietf.org ; lsr-cha...@ietf.org
>
> On Jul 10, 2020, at 4:39 PM, Linda Dunbar wrote:
>
> I also support the adoption of TTZ draft.
>
> The Virtual Zone concept would be very useful for the Overlay networks. The
> proposed TTZ can group a set of nodes not geographically together into one
> virtual area to scale virtual overla
> On Jul 10, 2020, at 7:07 PM, Uma Chunduri wrote:
>
> I would support the IS-IS TTZ solution for WG adoption.
>
> Of course, obviously not with OSPF encodings or concepts only relevant to
> OSPF (thx for the updated version).
> Thanks for the good work which was started way back on TTZs wit
My comments about what the WG should be doing are "As WGChair", I'm not
commenting directly on TTZ, but on the broader comments/questions below.
> On Jul 16, 2020, at 6:19 AM, Tianran Zhou wrote:
>
> Hi Henk,
>
> Thanks very much for your long email.
> I fully agree with what you said on the c
Anyway, I respect the tradition of this WG.
> I just want to know if the WG request for interop and implementation report
> for every draft?
[chair hat] We always prefer to have this. We do not always get it,
unfortunately.
Thanks,
Chris.
>
> Thanks,
> Tianran
>
> -Ori
> visibility of on-path OAM data.
> 3. updated Acknowledgements sections, in which, the authors would like to
> thank Acee Lindem, Christian Hopps, Robert Raszuk, Les Ginsberg, Jeff
> Tantsura, Rakesh Gandhi, Tony Li and Greg Mirsky for the comments.
> 4. adding China Tel
Hi,
If anyone would like to have a post meeting hallway chat now that our meeting
slot has ended, I'll be hanging out in the IETF gather.town for the next 20
minutes or so.
Thanks,
Chris.
signature.asc
Description: Message signed with OpenPGP
___
Ls
For the curious
To join gather.town goto the IETF 108 page:
https://www.ietf.org/how/meetings/108/ <https://www.ietf.org/how/meetings/108/>
and click "Join Gather".
Thanks,
Chris.
> On Jul 30, 2020, at 12:09 PM, Christian Hopps wrote:
>
> Hi,
>
> If anyone wo
This begins a 2 week WG Last Call, ending after September 1st, 2020, for
draft-ietf-lsr-flex-algo
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/
All authors, please indicate by sending an email to the list, whether you aware
of any other IPR beyond what is already posted:
[From
1 - 100 of 334 matches
Mail list logo
