thing.
Thanks,
Chris.
[chair hat]
>
>
> Rgds
> Shraddha
>
>
> Juniper Business Use Only
>
> -----Original Message-
> From: Peter Psenak
> Sent: Thursday, September 3, 2020 1:25 PM
> To: Shraddha Hegde ; olivier.dug...@orange.com;
> tony...@tony.li; Rober
During my review and while doing the Shepherd writeup for
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ I came up
with the following comments:
4.3 - Maximum H.Encaps MSD Type:
- what is the default if not advertised?
6. Advertising Anycast Property
Should "Locator
> On Sep 22, 2020, at 1:21 AM, Donald Eastlake wrote:
>
>
> One final question: I may be confused but my understanding of IS-IS is
> that there are Level 1 links, Level 2 links, and links that are both
> Level 1 and 2. A border router between Level 1 and Level 2 is a router
> that has both typ
Thanks for the update, a couple issues remain.
[ ] 7.1 and 8.1
The reserved bits for "SRv6 Locator TLV" and "SRv6 End.X SID sub-TLV" are
defined differently (and probably incorrectly) than the other reserved bits.
Reserved bits "MUST" be set to zero, not "SHOULD", I believe.
[ ] 11. Implementat
This begins a 2 week WG adoption call for the following draft:
https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/
Please indicate your support or objection by October 16, 2020.
Authors, please respond to the list indicating whether you are aware of any IPR
that applies to this
Thanks Joel, Peter, et al.
The WG last call is now complete (it was mainly being held during the appeal on
the base document, and was ready a while ago). The document improved in the
meantime which is great.
I have completed the write-up and the document has been submitted to the IESG
for publ
This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/
The following IPR has been filed https://datatracker.ietf.org/ipr/3448/
Authors,
Please indicate to the list, your knowledge of any other IPR related
nd
> should be) focused on simple protocol extensions.
[As WG member]
I find this very compelling and so support the removal of the referred to
non-normative appendices.
Thanks,
Chris.
>
> Thanx.
>
> Les
>
>
>> -Original Message-
>> From: Aijun
t; As I known, when we want to do protocol extension, we should always convince
> other the reason/motivation/prospects to do so. On the other hand, the use
> case described in the current appendix is very prominent for operator to
> accomplish the TE task in multi-area environment.
>
(and should be) focused on simple protocol extensions.
>>
>> Thanx.
>>
>> Les
>>
>>
>>> -Original Message-
>>> From: Aijun Wang
>>> Sent: Thursday, October 15, 2020 6:51 PM
>>> To: 'Jeff Tantsura' ; 'Joh
The document is adopted.
Authors, please resubmit as draft-ietf-lsr-ospf-l2bundles-00
Thanks,
Chris.
> On Oct 2, 2020, at 8:03 AM, Christian Hopps wrote:
>
> Signed PGP part
> This begins a 2 week WG adoption call for the following draft:
>
> https://datatracker.ietf.or
The WGLC has completed. The documented was updated to address the objections
made during the WGLC. The write-up will begin and publication will be requested.
Thanks,
Chris.
> On Oct 15, 2020, at 2:15 AM, Christian Hopps wrote:
>
> Signed PGP part
> This begins a 2 week WG Last
I am not aware of any IPR that applies to
draft-ietf-lsr-yang-isis-reverse-metric-01. This draft defines a YANG model for
the base work defined in RFC8500 which does have an IPR disclosure.
Thanks,
Chris.
> On Dec 1, 2020, at 4:20 PM, Acee Lindem (acee) wrote:
>
> Chris,
>
> Are you aware
> On Dec 16, 2020, at 7:12 AM, Ladislav Lhotka via Datatracker
> wrote:
>
> Reviewer: Ladislav Lhotka
> Review result: Ready with Issues
>
> General comments
>
> - YANG module "ietf-isis-reverse-metric" is in a good shape except for
> one issue described below.
> - I appreciate the thr
This begins a 2 week WG adoption call for the following draft:
https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-admin-tags/
Please indicate your support or objection by January 19th, 2021.
Authors, please respond to the list indicating whether you are aware of any IPR
that applies to this
This begins a 2 week WG adoption call for the following draft:
https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/
Please indicate your support or objection by January 19th, 2021.
Authors, please respond to the list indicating whether you are aware of any IPR
that appli
A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>This draft is a work item of the Link State Routing WG of the IETF.
>
>Title : YANG Module for IS-IS Reverse Metric
>Author : Christian Hopp
> On Jan 5, 2021, at 11:47 AM, tom petch wrote:
>
> From: Lsr on behalf of Christian Hopps
>
> Sent: 05 January 2021 09:19
>
> This begins a 2 week WG adoption call for the following draft:
>
> https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-a
> On Jan 5, 2021, at 12:04 PM, tom petch wrote:
>
> From: Christian Hopps
> Sent: Tuesday, January 05, 2021 16:54
> > On Jan 5, 2021, at 11:47 AM, tom petch > <mailto:ie...@btconnect.com>> wrote:
> >
> > From: Lsr mailto:lsr-boun...@ietf.org>&
The document is adopted, please republish as draft-ietf-lsr-ospf-admin-tags-00.
Thanks,
Chris.
> On Jan 5, 2021, at 4:17 AM, Christian Hopps wrote:
>
> Signed PGP part
> This begins a 2 week WG adoption call for the following draft:
>
> https://datatracker.ietf.org/doc/d
Hi Folks, so far we've received only a single feedback on adopting this
document, can we get a few more responses form the WG?
Thanks,
Chris.
> On Jan 5, 2021, at 4:19 AM, Christian Hopps wrote:
>
> Signed PGP part
> This begins a 2 week WG adoption call for the following d
The document is adopted, authors please resubmit as
draft-ietf-lsr-isis-yang-augmentation-v1-00
Thanks,
Chris.
> On Jan 5, 2021, at 4:19 AM, Christian Hopps wrote:
>
> Signed PGP part
> This begins a 2 week WG adoption call for the following draft:
>
> https://datatracker.
Hi LSR and TEAS,
This begins a joint WG last call for:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/
Please discuss any issues on the LSR mailing list. The WGLC will end March 3,
2021.
Authors, please indicate wether you are aware of any IPR related to this
document to th
> On Mar 8, 2021, at 7:40 PM, Linda Dunbar wrote:
>
> Christian,
>
> You said at LSR session today that there might be concern of network
> optimizing ANYCAST traffic to better balance among multiple App Layer Load
> Balancers.
> First of all, only the Applications that need to leverage the
or the creation
> of such registries bear closer scrutiny. Just my opinion of course…
>
> Thanx (again) for listening.
>
>Les
>
>
> From: Tony Li On Behalf Of Tony Li
> Sent: Thursday, March 18, 2021 8:24 AM
> To: Les Ginsberg (ginsberg)
> Cc: Alvaro Retana ;
LSR WG,
After going through the various emails on whether and when to allocate
an IANA registry for a flags field, the chairs do not believe we have a
strong enough consensus to choose a policy as of yet; however, we feel
we do have a rough consensus that would allow us to issue guidance.
After so
mented somewhere on the WG website?
>
> Les
>
>
>> -Original Message-
>> From: Lsr On Behalf Of Christian Hopps
>> Sent: Tuesday, April 20, 2021 5:24 PM
>> To: lsr@ietf.org
>> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org
>> Subject: [Lsr
This category of flags field was never under discussion - I thought you and I
> had agreed on this explicitly early on.
>
> Les
>
>
>> -Original Message-
>> From: Tony Li
>> Sent: Wednesday, April 21, 2021 7:47 AM
>> To: Les Ginsberg (ginsberg)
&g
This begins a 2 week WG adoption call for the following draft:
https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/
Please indicate your support or objection by May 16th, 2021.
Authors, please respond to the list indicating whether you are aware of any IPR
that applies
ohn
> Scudder via Datatracker ,
> "draft-ietf-lsr-isis-srv6-extensi...@ietf.org"
> , "lsr@ietf.org"
> , "lsr-cha...@ietf.org" , The IESG
> , Christian Hopps
> *Subject: *Re: John Scudder's No Objection on
>
ent: Wednesday, May 19, 2021 6:55 AM
To: Les Ginsberg (ginsberg) ; Acee Lindem (acee)
; Peter Psenak (ppsenak) ; John
Scudder
Cc: John Scudder via Datatracker ; draft-ietf-lsr-isis-srv6-
extensi...@ietf.org; Christian Hopps ; lsr-
cha...@ietf.org; lsr@ietf.org; The IESG
Subject: RE: John Scudder&#x
The work is adopted, authors please resubmit as:
draft-ietf-lsr-ospf-transport-instance-00
Thanks,
Chris.
Christian Hopps writes:
This begins a 2 week WG adoption call for the following draft:
https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/
Please indicate
https://mailarchive.ietf.org/arch/msg/lsr/kbnwOs_K_d8fYKnae-yn3wcFlZQ/
Aijun Wang
China Telecom
On May 21, 2021, at 23:06, Christian Hopps
wrote:
The work is adopted, authors please resubmit as:
draft-ietf-lsr-ospf-transport-instance-00
Thanks,
Chris.
Christian Hop
"Acee Lindem (acee)" writes:
Hi Greg,
Additionally, in a vacuum light will only travel 300 meters in a
microsecond. So, in a nanosecond, that is less than a foot. What
transmission technology and application do you anticipate that will
require this this precision?
Off by a few magnitude;
Christian Hopps writes:
[[PGP Signed Part:Good signature from 2E1D830ED7B83025 Christian Hopps
(trust ultimate) created at 2021-05-23T21:12:09-0400 using
RSA]]
"Acee Lindem (acee)" writes:
Hi Greg,
Additionally, in a vacuum light will only travel 300 meters in a
microseco
Hi Folks,
This begins a 2 week WG Adoption Call for the following draft:
https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid/
Please indicate your support or objections by June 9th, 2021
Authors, please respond to the list indicating whether you are aware of any I
The document is adopted. We have enough support, and given the development
email on the adoption call thread clearly people willing to work on the
document.
Authors please resubmit as draft-ietf-lsr-algorithm-related-adjacency-sid-00
Thanks,
Acee & Chris.
Christian Hopps writes:
> On Jul 9, 2021, at 11:00 AM, Les Ginsberg (ginsberg)
> wrote:
>
> I agree with Bruno that the time available in the WG meeting will likely be
> inadequate to present full updates for both drafts. In addition, I think it
> is important that the WG have
> an opportunity to discuss publicly i
s.
Right-o, captain.
Thanks,
Chris.
Thanx.
Les
From: Lsr On Behalf Of Christian Hopps
Sent: Monday, July 12, 2021 9:53 AM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org; bruno.decra...@orange.com; lsr-cha...@ietf.org
Subject: Re: [Lsr] draft-decraene-lsr-isis-flooding-speed
The WGLC has ended.
I may have missed it but I do not see any feedback from Xiaodong Duan for IPR.
That is still required to the list.
Thanks,
Chris.
> On Feb 17, 2021, at 10:30 AM, Christian Hopps wrote:
>
> Hi LSR and TEAS,
>
> This begins a joint WG last call f
Hi Folks,
This begins a 3 week WG Adoption Call for the following related YANG drafts:
https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/
https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/
Please indicate your support or objections by August 12th, 2021
Authors, please respon
Still waiting on this mail to the list.
Thanks,
Chris.
> On Jul 21, 2021, at 6:18 PM, Christian Hopps wrote:
>
> The WGLC has ended.
>
> I may have missed it but I do not see any feedback from Xiaodong Duan for
> IPR. That is still required to the list.
>
> Thanks,
> On Aug 19, 2021, at 4:53 PM, Yaron Sheffer wrote:
>
> I guess in Security we are not as liberal with folks' permissions...
Yaron, But it’s your own review :)
Acee, I had the same answer for a tsv review a while ago on an ipsec document.
Would be nice if there was some way for a reviewer to
> On Oct 14, 2021, at 1:25 AM, Les Ginsberg (ginsberg)
> wrote:
>
>
> The rest of your argument seems to be that we should move forward w the PUA
> solution just because the draft has been around for a long time. Sorry, that
> isn’t a valid argument.
I sort of got this feeling as well.
>
Does it junk the mail if the one true and proper form is used: "IS-IS" (i.e.,
with the hyphen)? :)
Thanks,
Chris.
> On Oct 14, 2021, at 7:15 AM, tom petch wrote:
>
> Top posting for a different topic
>
> My ESP, one of the larger ones in the world, is classifying most of the LSR
> e-mails as
John Scudder writes:
Dear Chris,
Here’s my review of this document. I only have a few nits, that should be
easily addressed.
Thanks for the review. The new version incorporates your suggested changes.
https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metric/
The ISO refer
> On Nov 16, 2021, at 10:36 PM, Aijun Wang wrote:
>
> Hi,
>
> The followings are the responses for the comments on PUAM
> draft(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08)
>
> Les: The comment I want to make, I think the discussion on the
>
ld happen on the list.
Thanks,
Chris.
> If there is no such information, it is doubt whether your judgment is correct
> or not, it is also unconvincing. Welcome also Tony gives the explanation
> before making the assertions, as we done for PUAM solution.
>
>
> Aijun Wa
> On Nov 21, 2021, at 3:09 AM, Aijun Wang wrote:
>
> Hi, Tony:
>
> Aijun Wang
> China Telecom
>
>> On Nov 21, 2021, at 15:17, Tony Li wrote:
>>
>>
>> Hi Aijun,
>>
>>> The ABR should do the summary work based on the liveness, right?
>>
>>
>> No. ABRs advertised statically configured pre
Gyan Mishra writes:
+1
As I mentioned the requirements for E2E LSP with seamless MPLS or
SR-MPLS requires domain wide flooding of host routes.
For large operators with a thousands of routes per area you can image
if you total that all up can equate to hundreds of thousands of host
routes.
Aijun Wang writes:
Hi, Robert:
Aijun Wang
China Telecom
On Nov 23, 2021, at 20:00, Robert Raszuk
wrote:
Dear Aijun,
[WAJ] Once there is a link/node failure, upon receiving the
updated LSA, the ABR
That node failure will need to be detected fast.
tems where they enable services and the mgmt system then
automatically generates configuration files as complex as they need to be which
the system then loads onto the devices.
Thanks,
Chris.
[wg member hat]
Aijun Wang
China Telecom
On Nov 23, 2021, at 20:44, Christian Hopps wrote:
Aij
Benjamin Kaduk via Datatracker writes:
Benjamin Kaduk has entered the following ballot position for
draft-ietf-lsr-yang-isis-reverse-metric-04: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut
Alvaro Retana via Datatracker writes:
Alvaro Retana has entered the following ballot position for
draft-ietf-lsr-yang-isis-reverse-metric-04: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut t
Hi Robert,
tl;dr all comments addressed :)
new version published:
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-yang-isis-reverse-metric-06
URL:
https://www.ietf.org/archive/id/draft-ietf-lsr-yang-isis-reverse-metric-06.txt
Comments inline as well...
Robert Wilton via Datatracke
On a lighter note..
Forklift upgrades imply a requirement to replace hardware i.e., "get the forklift
out to swap in/out huge heavy router chassis".. I think it's recently been somewhat
misused to refer to software upgrades. SW upgrades do not require forklifts. :)
"a Flag Day", would probab
Tony Przygienda writes:
One thing Les is missing here is that proxy & reflection present in
terms of deployment requirements and ultimate properties very
different engineering & operational trade-offs. Different customers
follow different philosophies here IME
So we are not strictly standardi
> On Nov 29, 2021, at 7:39 PM, Les Ginsberg (ginsberg)
> wrote:
>
> Tony –
>
> Let me try one example – see if it helps.
>
> Summarization is used in the network.
> But customer identifies a modest number of key nodes where it wants to detect
> loss of reachability ASAP. Unfortunately, cu
Peter Psenak writes:
On 03/01/2022 16:21, Christian Hopps wrote:
On Nov 29, 2021, at 7:39 PM, Les Ginsberg (ginsberg)
wrote:
Tony –
Let me try one example – see if it helps.
Summarization is used in the network.
But customer identifies a modest number of key nodes where it wants to
Peter Psenak writes:
Chris,
On 03/01/2022 17:18, Christian Hopps wrote:
Peter Psenak writes:
On 03/01/2022 16:21, Christian Hopps wrote:
On Nov 29, 2021, at 7:39 PM, Les Ginsberg (ginsberg)
wrote:
Tony –
Let me try one example – see if it helps.
Summarization is used in the
2022, at 05:09, Tony Li wrote:
>>
>>
>>
>>> On Jan 3, 2022, at 11:23 AM, Christian Hopps wrote:
>>>
>>> And I'm saying if a prefix is important enough to merit a bunch of new
>>> protocol extensions and state, then it's important
Hi Folks,
This begins a 2 week WG Adoption Call for the following draft:
https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
Please indicate your support or objections by January 18th, 2022.
Authors, please respond to the list indicating whether you are aware of any IPR
that
like Good Design (KISS) to me.
Thanks,
Chris.
[as wg member]
Best Regards
Aijun Wang
China Telecom
-----Original Message-
From: Christian Hopps
Sent: Tuesday, January 4, 2022 2:31 PM
To: Aijun Wang
Cc: Christian Hopps ; Tony Li ; Robert
Raszuk ; Shraddha Hegde ; Hannes
Gredler ; Les Gins
I think the point is that just saying:
>> And if customers could do what he suggested then they would not have an
>> issue.
>>
>> But there are deployments where what he suggested is not possible – largely
>> I think because the set of “prefixes of interest” is in itself large.
maybe isn't s
Peter Psenak writes:
Aijun,
On 05/01/2022 16:20, Aijun Wang wrote:
[WAJ] The above remote information must be configured manually on the local
device. It is paired by manual. Thinking there are many links among the ASBRs,
would you like to configure them manually for every remote ends on eac
ncerns for
> unnumbered interface and sub-TLV hierarchy that raised by Peter and Les.
> Please review it if there exists any other concerns.
>
> Thanks.
>
>
> Aijun Wang
> China Telecom
>
>> On Jan 11, 2022, at 20:55, Christian Hopps wrote:
>>
>>
> On Jan 12, 2022, at 5:35 PM, Aijun Wang wrote:
>
> Hi, Christian:
>
> Aijun Wang
> China Telecom
>
>> On Jan 13, 2022, at 04:19, Christian Hopps wrote:
>>
>> Doesn't this reduce to: "The operator configures one of their routers with
&g
> On Jan 12, 2022, at 6:53 PM, Tony Li wrote:
>
>
>
>> On Jan 12, 2022, at 3:10 PM, Christian Hopps wrote:
>>
>> m having a little trouble fully understanding what you're saying here.
>>
>> However, I think what is being done is the user co
> On Jan 12, 2022, at 9:03 PM, Tony Li wrote:
>
>
> Chris,
>
>> This isn't the same as TE information which can be/is based dynamic values
>> on the router.
>
>
> Are you sure? First, much of the TE information that we have distributed is
> static (administrative group, SRLG, etc.). The
is
complex.
Thanks,
Acee
From: Tony Przygienda
Date: Monday, January 10, 2022 at 2:36 PM
To: Acee Lindem
Cc: Aijun Wang , Christian Hopps <
cho...@chopps.org>, "Les Ginsberg (ginsberg)" , "lsr@ietf.org"
Subject: Re:
WG Member Hat: I think the un-adopted 5G draft should be left out of any
justification for adopting the stub link draft.
Chair Hat: One un-adopted draft using another un-adopted draft cannot serve as
the justification to adopt the referenced draft. If that worked then 2 drafts
could refer to ea
> On Jan 14, 2022, at 6:39 PM, Aijun Wang wrote:
>
> Hi, Robert:
>
> I would say some people are likely to hear other’s explanations, some are
> reluctant.
> Anyway, I am eager to hear the independent technical analysis.
>
> For the current scenarios and solutions, we have analyzed that RFC
gt;
> John
>
>
> Juniper Business Use Only
> From: Aijun Wang
> Sent: Friday, January 14, 2022 7:40 PM
> To: John E Drake
> Cc: Les Ginsberg (ginsberg) ; Robert Raszuk
> ; Christian Hopps ; Shraddha Hegde
> ; Tony Li ; Hannes Gredler
> ; lsr ; P
gt; all influence or break the path to their connected service if their
> forwarding function is failed.
>
> Aijun Wang
> China Telecom
>
>> On Jan 15, 2022, at 08:56, Christian Hopps wrote:
>>
>> Indeed, and in fact the IGP should only be dealing with the re
> On Jan 14, 2022, at 8:25 PM, Christian Hopps wrote:
>
> I understand the proposal. As I've stated elsewhere, I do not believe there
> is a problem here that needs solving. The "problem" was created by the user
> by summarizing prefixes that should not have
ill
> be backhole for some time until the service/application find this abnormal
> phenomenon.
> PUA/PULSE are just the mechanism to reduce the abnormal durations, it is one
> kind of FRR technique.
>
> Aijun Wang
> China Telecom
>
>> On Jan 15, 2022, at 09:
how about we forward them also into experimental track, and let the
implementation and market to select/determine?
With the experimental deployment experiences, we can get the most suitable
solutions.
Best Regards
Aijun Wang
China Telecom
-Original Message-
From: lsr-boun...@ietf.org On Behal
domain-wide distribution of prefixes
has no effect whatsoever on the first aspect of scalability, namely
the existence of areas and the limitation of the distribution of the
link state database.
Gyan
On Fri, Jan 14, 2022 at 9:07 PM Christian Hopps
wrote:
Yes, having worked intimat
these prefixes you
want to modify the summarization process because summarization doens't work for them"
Again KISS applies here:
If the summarization process *doesn't work* for a given prefix P, then
*don't use summarization* for prefix P!
Thanks,
Chris.
[As wg member]
give them higher priority for insertion in
their FIB, etc..
Thanks,
Chris.
Thx,
R.
On Mon, Jan 24, 2022 at 10:40 AM Christian Hopps
wrote:
"Aijun Wang" writes:
> Hi, Chris:
> We should notice here that it is not "a prefix", it&
Peter Psenak writes:
Chris,
On 24/01/2022 10:29, Christian Hopps wrote:
Again KISS applies here:
If the summarization process *doesn't work* for a given prefix P, then
*don't use summarization* for prefix P!
above simply does not work.
1. so far nobody summarizes
Peter Psenak writes:
On 24/01/2022 16:19, Christian Hopps wrote:
Peter Psenak writes:
Chris,
On 24/01/2022 10:29, Christian Hopps wrote:
Again KISS applies here:
If the summarization process *doesn't work* for a given prefix P, then
*don't use summarization* fo
Regards
Aijun Wang
China Telecom
-Original Message-
From: lsr-boun...@ietf.org On Behalf Of Tony Li
Sent: Tuesday, January 25, 2022 3:25 PM
To: Aijun Wang
Cc: Les Ginsberg (ginsberg) ; Gyan Mishra
; Peter Psenak ;
Christian Hopps ; Robert Raszuk ; lsr
Subject: Re: [Lsr] BGP vs PUA/PULSE
Peter Psenak writes:
On 24/01/2022 21:27, Christian Hopps wrote:
Peter Psenak writes:
On 24/01/2022 16:19, Christian Hopps wrote:
Peter Psenak writes:
Chris,
On 24/01/2022 10:29, Christian Hopps wrote:
Again KISS applies here:
If the summarization process *doesn't
Robert Raszuk writes:
Peter,
If a given PE needs to get all notifications from all other PEs it is
sufficient that it sends to local ABRs a single registration in a
form of 0.0.0.0/0 and be done.
But realistically speaking the case where services offered by a PE
also exist on all 100K other
"Les Ginsberg (ginsberg)" writes:
Greg –
With 100K PE scale, we are talking about 100K BFD sessions/PE and
close to 5 million BFD sessions network-wide.
Eliminating one of the options we are discussing is admittedly a
small step, but still worthwhile.
Hang on a sec. :)
We are starting off
"Aijun Wang" writes:
Hi, Greg:
Yes. I think so. If we select the “OOB solution“ category, RFC 5883
is one existing option, and has no new connection states introduced
within the network devices.
The reason that we prefer to the IGP solution is that we want just to
relieve from the configu
agree - or - as Greg has done - say we don’t really have to consider
this scale. I am not going to try to convince you otherwise.
But if so you aren’t solving the problem we have been asked to solve.
Les
-Original Message-
From: Christian Hopps
Sent: Wednesday, January 26, 2022 2:15
Robert Raszuk writes:
Hi Les,
There is nothing in RFC 5880 (nor in, what I consider to be even
more relevant, RFC 5882) that requires a BFD implementation to
signal UP state to a BFD client within a specific time following
transition of the BFD state machine to UP . An impl
[As WG Chair]
Hi LSR-WG,
As my co-chair has joined the draft as a co-author making the call on whether
we have rough consensus to adopt draft-wang-lsr-stub-link-attributes-02 now
falls to me alone.
I've reread the numerous emails on this adoption call and I see some support,
and a few object
as "out of process" or does the -03 revision also still fail on this point?
Thanks,
Chris.
thanks,
Peter
On 18/02/2022 05:45, Christian Hopps wrote:
[As WG Chair]
Hi LSR-WG,
As my co-chair has joined the draft as a co-author making the call on whether
we have rough consensus to
Robert Raszuk writes:
Hi Chris,
Tony Li (at least) seemed to think that it was useful to be able
to attach TE attributes to a link, not just to prefixes. Perhaps
I've missed this in the thread but what current mechanism (rfc?)
are you referring to, to identify a link and atta
Robert Raszuk writes:
I didn't see any client/app data in this proposal.. There are
other drafts out there that seem to be talking about that, which
I also don't like (as wg member )
The way I look at them and seeing authors referencing directly those
drafts is that this draft
t whether it has
warts or not.
Thanks,
Chris.
[as wg chair]
thanks,
Peter
On 18/02/2022 13:14, Christian Hopps wrote:
Peter Psenak writes:
Chris,
the draft attempt to use the local subnet information for identifying two
endpoints of the same link. That seems wrong in itself. In addition:
The -
"Les Ginsberg (ginsberg)" writes:
Chris -
[... trimmed out the restated points ...]
I also strongly object to your statement below:
" I've asked for cases that this draft would break things, not whether it has warts
or not."
This suggests (intentionally or not) that so long as a draft
Hi Alvaro, et al.
I support these changes, and thanks for taking this up.
I guess it makes sense to not go full-in and re-spin the base docs if there
literally are no other changes (although one wonders if it will actually change
things like CLIs if we don't).
That said, quite a few errata ex
Alvaro Retana writes:
On February 23, 2022 at 8:35:03 PM, Christian Hopps wrote:
Chris:
Hi!
I support these changes, and thanks for taking this up.
:-)
I guess it makes sense to not go full-in and re-spin the base docs if there
literally are no other changes (although one wonders
2, at 01:58, Christian Hopps wrote:
>
> Hi Folks,
>
> This begins a 2 week WG Adoption Call for the following draft:
>
> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
>
> Please indicate your support or objections by January 18th, 2022.
>
&g
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 well ahead
of enabling such application in a network.
So requesting operator to always advertise tuple of app +
Peter Psenak writes:
On 26/01/2022 10:40, Robert Raszuk wrote:
> The pulse solution does not suffer from the scale issues.
It shifts that "suffering" to flood the entire domain with information which
is not needed on P routers and selectively useful on the remote PEs.
yes, but how much da
101 - 200 of 334 matches
Mail list logo
