router software that doesn't break
their network when they have existing routers that do not support multi-part
TLVs. I think we are capable of providing for this in our RFC.
Thanks,
Chris.
Thanx.
Les
-Original Message-
From: Christian Hopps
Sent: Monday, September 2, 20
eal at this point if you wish to continue with this.
Chris.
>
> Best Regards
>
> Aijun Wang
> China Telecom
>
> -邮件原件-
> 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表
> Christian Hopps
> 发送时间: 2024年9月3日 11:18
> 收件人: Aiju
"Aijun Wang" writes:
I would like to emphasize that this document will lead to more chaos
for the operators network, even it solves the control of when to send
the MP-TLV problems.
Please see: https://mailarchive.ietf.org/arch/msg/lsr/
Gf4D3REVNXWO9BlIVPqnZ3f-GcM/ for more unsolved problems.
> On Sep 2, 2024, at 11:38, bruno.decra...@orange.com wrote:
>
> It is not within the purview of an RFC to mandate that an implementation
> have a particular knob.
> [Bruno]
> • According to which document /rule?
[as wg-member]
Regardless of whether we choose to add this requirement, I'm
> On Aug 20, 2024, at 19:00, Les Ginsberg (ginsberg)
> wrote:
>
> Also, we are discussing modifying the “crown jewel” of link state protocols –
> the reliable Update Process. It behooves us as a WG to do so with a great
> deal of diligence. Having separate drafts allows issues specific to ea
Aijun Wang writes:
Hi, Chris:
Aijun Wang
China Telecom
On Aug 8, 2024, at 20:53, Christian Hopps wrote:
[As WG member]
I'm neutral on whether the RFC should try and identify what the specific key
is for all the existing TLVs; however, I think the current draft does define
what a k
[As WG member]
I'm neutral on whether the RFC should try and identify what the specific key is
for all the existing TLVs; however, I think the current draft does define what
a key is. It's exactly the data which would identify multiple TLVs as being all
part of a single logical TLV. The draft
The reason I suggested just using 64 bits which then provides nanosecond
resolution (whether we need it today or not), is it seems KISS, which makes me
feel warm inside — people aren’t going to screw up the unit values; we really
aren’t going to need to revisit this anytime soon for different re
t clear the stale LSPs in advance by the proxy neighbor?
Best Regards
Aijun Wang
China Telecom
-邮件原件-
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表
Christian Hopps
发送时间: 2024年7月16日 22:24
收件人: Tony Przygienda
抄送: Aijun Wang ; Acee Lindem ;
Les Ginsberg (gins
Tony Przygienda writes:
Aijun, simply check the amount of RFCs and vendor knobs on proxy
purge origination ID, security signatures, spec implementation
deviations etc. which will give you an indication lots of bad things
happened with it to good and bad people running large networks alike
;'-
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
__
[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
[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
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.
>
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:
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
"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
[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
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
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
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
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
Christian Hopps has requested publication of
draft-ietf-lsr-ospfv3-extended-lsa-yang-23 as Proposed Standard on behalf of
the LSR working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa
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
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
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
_
> 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;
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
Christian Hopps has requested publication of draft-ietf-lsr-isis-area-proxy-09
as Experimental on behalf of the LSR working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
___
Lsr ma
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
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
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.
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
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
"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
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
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:
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
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
__
Christian Hopps has requested publication of draft-ietf-lsr-rfc8919bis-00 as
Proposed Standard on behalf of the LSR working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8919bis/
___
Lsr mailing
Christian Hopps has requested publication of draft-ietf-lsr-rfc8920bis-01 as
Proposed Standard on behalf of the LSR working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8920bis/
___
Lsr mailing
"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.
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
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
[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
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
__
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
__
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-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
__
"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
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:
> 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
Christian Hopps has requested publication of draft-ietf-lsr-ospf-terminology-03
as Proposed Standard on behalf of the LSR working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-terminology/
__
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
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
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
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
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
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
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:
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
"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
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:
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
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
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
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
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
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
"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
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:
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
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
[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
[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
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
> 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
"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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
> 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 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
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
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
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
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
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
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
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
1 - 100 of 334 matches
Mail list logo
