Yes/support
> On Jun 17, 2024, at 11:41, Christian Hopps wrote:
>
>
> 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 t
Hey Acee,
Yes/support, valuable addition.
Thanks,
Jeff
> On Feb 19, 2024, at 14:25, Acee Lindem wrote:
>
>
> This starts the Working Group Last call for
> draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm
> enhancements described in the document have been implemented.
sr-dynamic-floodingWhile I am a BGP person I feel pretty strongly that BGP is not a best fit for the vast majority of DC fabrics in use today. Cheers,RobertOn Sun, Nov 26, 2023 at 10:49 PM Jeff Tantsura <jefftant.i...@gmail.com> wrote:I agree with all aforementioned comments.
Wrt AI/ML n
I agree with all aforementioned comments.
Wrt AI/ML networking - if a controller is used, what is required is link state
exposure northbound and not link state protocol in the fabric. (I could argue
for RIFT though ;-))
I’d urge you to take a look at Meta’s deployment in their ML clusters
(pu
+1 Tony
> On Aug 29, 2023, at 7:18 AM, Tony Li wrote:
>
>
> Hi Eduard,
>
> I know several different products that use different silicon on different
> line cards, ending up with different capabilities on different interfaces.
>
> This is more of a hardware issue than a software one.
>
> Di
Yes/support
Cheers,
Jeff
> On Aug 18, 2023, at 17:27, Christian Hopps wrote:
>
>
> 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
Yes/support Cheers,JeffOn Mar 17, 2023, at 21:23, Gyan Mishra wrote:Support adoption ThanksGyanOn Fri, Mar 10, 2023 at 8:09 AM Acee Lindem wrote:
The begins the LSR WG adoption call for "IGP Flexible Algorithms Reverse Affinity Constraint" - draft-ppsenak-lsr-igp-flex-algo-r
Chris, I am not aware of any IPR related to this draft and as a co-author support its progress. Cheers,Jeff From: Christian HoppsSent: Wednesday, December 7, 2022 6:07 AMTo: lsr@ietf.orgCc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org; draft-ietf-lsr-rfc8920...@ietf.orgSubject: [Lsr] WG
Yes/support Cheers,JeffOn Nov 23, 2022, at 07:50, Tony Przygienda wrote:as co-author support adoption. draft is a derivation of well-known MANET techniques used before successfully. The twists improving it (balancing of flooding across downstream nodes in addition to reduction) has been used in R
+1 Cheers,Jeff From: Les Ginsberg (ginsberg)Sent: Friday, August 12, 2022 9:05 AMTo: 龚立艳; lsr@ietf.org; shraddhaSubject: Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo Liyan – You agree that there is an existing way to prune links from the IGP SPF.Still, you insist that an extensi
Chris,
I’m not aware of any IPR that hasn’t been disclosed and support the progress
(as co-author).
Cheers,
Jeff
> On Aug 8, 2022, at 05:57, John E Drake
> wrote:
>
> Support
>
> Yours Irrespectively,
>
> John
>
>
> Juniper Business Use Only
>
>> -Original Message-
>> From: Lsr
. Would be great to do some study around existing solutions, see what worked, what didn’t’ (and why) Cheers,Jeff From: Susan HaresSent: Saturday, July 9, 2022 1:44 PMTo: Jeff Tantsura; Robert RaszukCc: Acee Lindem (acee); lsr; i...@ietf.org; g...@ietf.org g...@ietf.orgSubject: RE: [Idr] [Lsr] IGP
Speaking as RTGWG chair:
Robert - I don’t think we’d have enough time to accommodate a good discussion
during IETF114 (we got only 1 slot), however would be happy to provide a
platform for an interim.
The topic is important and personally (being a very large BGP-LS user) I’d like
to see it prog
I’d support publishing it as Experimental.
If there’s a consensus that an additional presentation in RTGWG would be
useful, Yingzhen and I would consider it.
Cheers,
Jeff
> On Jun 13, 2022, at 12:17, Acee Lindem (acee)
> wrote:
>
> Hi Tony, Les, Tom,
>
> When the WG was focused on this pro
Yes/support
Cheers,
Jeff
> On Apr 25, 2022, at 06:51, Christian Hopps wrote:
>
> 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
Yes/support
Cheers,
Jeff
> On Jan 27, 2022, at 09:08, Acee Lindem (acee)
> wrote:
>
>
> LSR WG,
>
> This begins a two week last call for the subject draft. Please indicate your
> support or objection on this list prior to 12:00 AM UTC on February 11th,
> 20222. Also, review comments are
I’d very much support applicability draft work!
Cheers,
Jeff
> On Jan 3, 2022, at 08:05, Tony Przygienda wrote:
>
>
> AFAIS this is a "operational and deployment" or "applicability" draft and not
> part of a protocol specification. But yes, such a draft would have value
> AFAIS, especially
Acee,
I support the adoption, and would like to thank the authors for the great work.
At this point in time, it feels like experimental track is more suitable.
Cheers,
Jeff
>
>
>> On Nov 22, 2021, at 6:06 AM, Acee Lindem (acee)
>> wrote:
>>
>> We indicated the intent to adopt of
>> draft-d
Yes/support
Cheers,
Jeff
> On Nov 22, 2021, at 14:47, 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 post your comments on the draf
On Oct 13, 2021, at 12:04, Peter Psenak wrote:
>
> Hi Jeff,
>
>> On 13/10/2021 19:28, Jeff Tantsura wrote:
>> Number of BGP peers isn’t representative here, classical deployments would
>> have a number of RR’s to circumvent full mesh. What counts is the total
>
Number of BGP peers isn’t representative here, classical deployments would have
a number of RR’s to circumvent full mesh. What counts is the total number of
PEs (next-hops) that originate the prefix that is locally imported (needs to be
tracked). For further optimization, only multihomed prefixe
we are going in rounds, +1 Les!
Cheers,
Jeff
>> On Aug 18, 2021, at 1:20 PM, Les Ginsberg (ginsberg)
>> wrote:
>>
>> Ron -
>>
>> Indeed – it is long past the time when we should be focusing on the “big
>> picture”.
>> I think Acee has stated it as succinctly as anyone – let me repeat for
>
+1 Les.
Cheers,
Jeff
>
>
>> On 13/07/2021 17:39, Les Ginsberg (ginsberg) wrote:
>> Draft authors -
>> I note that the new version has altered the advertisement of the Generic
>> Metric sub-TLV so that it is no longer supported in the ASLA sub-TLV.
>> This is in direct violation of RFC 8919/892
Yes/support
Regards,
Jeff
> On May 12, 2021, at 15:14, Acee Lindem (acee)
> wrote:
>
>
> Esteemed Members of the LSR WG,
>
> This begins a 2 week WG adoption call for the following draft:
>
> https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/
>
> Please indica
+1
Cheers,
Jeff
On May 7, 2021, 9:53 AM -0700, Les Ginsberg (ginsberg)
, wrote:
> As has been mentioned in this thread, the need for the prefix-attributes
> sub-TLV to correctly process leaked advertisements is not unique to the
> Locator TLV. The reason prefix-attributes TLV was created was to
Yes/support
Regards,
Jeff
> On May 2, 2021, at 01:47, Christian Hopps wrote:
>
>
> 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.
In ol’ good RSVP-TE days we already used “severity/relevance indicator” to
decide whether changes in link attributes (BW/etc) are significant enough and
should be propagated in into TED and trigger re-optimization/rerouting, this is
no different, define your threshold for a trigger.
Note - fle
Yes/support
Cheers,
Jeff
On Feb 17, 2021, 7:30 AM -0800, Christian Hopps , wrote:
> 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,
> 2
support adoption.
Cheers,
Jeff
On Jan 5, 2021, 1:20 AM -0800, Christian Hopps , wrote:
> 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
yes/support
Cheers,
Jeff
On Jan 5, 2021, 1:17 AM -0800, Christian Hopps , wrote:
> 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, p
especially when the path is calculated distributedly?
The valid topology must consist of a set of connected routers sharing a common
Calc-Type, then loop-free calculation is done accordingly
Best Regards,
Zhenqiang Li
li_zhenqi...@hotmail.com
From: Jeff Tantsura
Date: 2020-12-04 09:18
To: Tony
gt; So that is a huge much needed gap as not all operators on the public core
> have MPLS or SR and would like an alternative.
>
> This could be used in both core and data center space as well IP based
> infrastructure.
>
> RSVP TE and SR have their niche and now IP flex alg
; Aijun Wang
> China Telecom
>
> From: lsr-boun...@ietf.org On Behalf Of Jeff Tantsura
> Sent: Friday, December 4, 2020 9:18 AM
> To: Tony Li ; Robert Raszuk
> Cc: lsr ; Acee Lindem (acee)
> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
>
Anything else than IGP metric based SPT is considered TE. Looking holistically
- topology virtualization (or similar) could have been a better name.
Cheers,
Jeff
On Dec 3, 2020, 4:25 PM -0800, Robert Raszuk , wrote:
> Hi Tony,
>
> The moment I hit "Send" I knew that this response may be coming as
yes/support
Cheers,
Jeff
On Nov 30, 2020, 10:15 AM -0800, Acee Lindem (acee)
, wrote:
> As stated as the IETF 109 LSR WG meeting, we feel the IS-IS reverse metric
> augmentation is ready for publication. This begins a two week last call for
> the subject draft. Please indicate your support or o
Yes/support - very useful work!
Cheers,
Jeff
On Dec 1, 2020, 1:13 PM -0800, Acee Lindem (acee)
, wrote:
> This IP Flex Algorithm draft generated quite a bit of discussion on use cases
> and deployment prior to IETF 109 and there was generally support for WG
> adoption. This begins a two week WG
e as suggested by Robert. It seems there is some interest here although
> I’m not convinced the IGP is the right place to solve this problem.
>
> Thanks,
> Acee
>
> From: Lsr on behalf of Gyan Mishra
>
> Date: Tuesday, November 17, 2020 at 4:02 AM
> To: Robert Ra
it is in a good
> enough state for adoption 😊
>
> Thanks,
> Ketan
>
> From: Susan Hares
> Sent: 16 November 2020 11:40
> To: 'Jeff Tantsura' ; Les Ginsberg (ginsberg)
>
> Cc: Ketan Talaulikar (ketant) ; Stephane Litkowski
> (slitkows) ; i...@ietf
+1 with Robert.
So you expect the following RIB state after PUA has been advertised:
10.0.0.1 - drop
10/24 - forward
Unless there’s a recursively discarded next-hop (ala RTBH ) - how do you
envision it?
Regards,
Jeff
> On Nov 16, 2020, at 00:25, Robert Raszuk wrote:
>
>
>> I was not brin
e IGP to flood unreachable only for the purpose
> of control plane (namely BGP paths invalidation).
>
> Cheers,
> R.
>
> > On Sun, Nov 15, 2020 at 8:29 PM Jeff Tantsura
> > wrote:
> > > As RIFT chair - I’d like to respond to Robert’ comment - the example is
&
As RIFT chair - I’d like to respond to Robert’ comment - the example is rather
unfortunate, in RIFT disaggregation is conditional and well contained within
its context, it doesn’t affect overall scalability.
Regards,
Jeff
> On Nov 15, 2020, at 08:44, Robert Raszuk wrote:
>
>
> Hi Aijun,
in all the
> protocols of interest in some future version of the draft.
> At that point we could then have a far more meaningful WG adoption call.
>
>Les
>
>
> From: Idr On Behalf Of Ketan Talaulikar (ketant)
> Sent: Friday, November 13, 2020 1:35 AM
> To: Susan
For OSPFv3 use E-LSAs (RFC8362)
Cheers,
Jeff
On Nov 4, 2020, 2:44 PM -0800, Linda Dunbar , wrote:
> Acee,
>
> Thank you very much for suggesting using the Prefix TLV for carry the Running
> Status and environment of 5G Edge Computing servers.
>
> In a nutshell, the
> https://datatracker.ietf.org
Yes/support
Regards,
Jeff
> On Oct 23, 2020, at 07:43, Acee Lindem (acee)
> wrote:
>
>
> This is simple BIS update to RFC 5316 is required to support IS-IS Inter-AS
> TE in IPv6 only networks. The authors have asked for WG adoption.
>
> This begins a two week LSR Working Group Adoption P
+1
Regards,
Jeff
> On Oct 15, 2020, at 11:33, John E Drake
> wrote:
>
> Hi,
>
> I agree with Les. This is a simple protocol extension for a specific purpose
> and there is no reason to include speculation about its use for other
> purposes, particularly when it is inherently not suited fo
Yes/support
Regards,
Jeff
> On Oct 14, 2020, at 23:16, Christian Hopps wrote:
>
> 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.or
I’m with Acee here, the presence of a passive interface in a topology is in no
way unambiguously signaling domain boundaries. You could “hack around” though,
but that would defeat the purpose of an IETF document.
Keeping it to OSPFv2 (other protocols have similar ways of doing that), I’d
say, us
rds
>
> Gyan
>
> > On Sun, Oct 11, 2020 at 1:38 PM Jeff Tantsura
> > wrote:
> > > Thanks Ron, indeed! Autocorrect works in mysterious ways ;-)
> > >
> > > Regards,
> > > Jeff
> > >
> > > >
iness Use Only
>
> -Original Message-
> From: Jeff Tantsura
> Sent: Saturday, October 10, 2020 3:14 PM
> To: Ron Bonica
> Cc: Dongjie (Jimmy) ; Peter Psenak ;
> Yingzhen Qu ; Gyan Mishra ;
> lsr@ietf.org
> Subject: Re: [Lsr] FW: New Version Notification for
&g
Hi Jimmie,
>
> Inline.
>
>Ron
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Dongjie (Jimmy)
> Sent: Friday, October 9, 2020 11:06 PM
> To: Peter Psenak ; Ron Bonica ;
> Yingzhen Qu ; Gyan Mishra
> Cc: lsr@ie
Hi Yingzhen,
Yes, that’s the case. The most important property of an algo computed path is
that is has to be consecutive, as either SID or IP address associated with a
particular topology is only known within that topology.
Looking specifically at Ron’s draft (MPLS could be more complex due to
yes/support
Cheers,
Jeff
On Oct 2, 2020, 5:03 AM -0700, Christian Hopps , wrote:
> 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, pl
Hi Ron,
the readers would benefit if the draft would state that in order for the
technology to work properly, there must be a contiguous set of connected
routers that support it between the S/D, since lookup (route installed in
context of the algo it is associated with) is done per hop.
Cheers
In general, I agree with what Ketan said, what’s important - it is the value
that is being used in forwarding, even if multiple control plane entries exist,
think about IGP migrations, or LDP to SR, where more than 1 protocol could be
distributing the labels/SIDs. I’m not sure the FIB is the rig
+1 to “Application-Specific”
Cheers,
Jeff
On Jun 18, 2020, 2:09 PM -0700, Les Ginsberg (ginsberg)
, wrote:
> John –
>
> Yes – I like “Application-Specific” better. This matches the term we use
> throughout the documents.
>
> Thanx.
>
> Les
>
> From: John E Drake
> Sent: Thursday, June 18, 2
yes/support the adoption
Cheers,
Jeff
On Jun 11, 2020, 12:04 PM -0700, Jordan Head
, wrote:
> Support.
>
> The draft identifies and addresses the problem, and quite cleanly I might add.
>
> Jordan Head
>
> On 6/10/20, 3:29 PM, "Lsr on behalf of Christian Hopps" on behalf of cho...@chopps.org> wr
Thanks Chris/Tony,
I wish we’d have more of this kind of discussions on the list, discussing
pro/cons of the solutions proposed!
Have a great weekend!
Regards,
Jeff
> On Jun 6, 2020, at 14:15, Tony Li wrote:
>
>
>
> Hi Chris,
>
> Thank you for your thoughtful comments.
>
>
>> A simplif
yes/support
Cheers,
Jeff
On Jun 4, 2020, 11:05 AM -0700, 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 flood reflection has been implemented and work
Weibin,
One could have an algo with MSD/ERLD as optimizations constrains, would be
quite similar to colored links. Note - ERLD has implemented node capabilities
only, so all links on a node will have to be pruned.
The tradeoffs are - having centralized controller with global view computing a
pa
Robert,
Assuming C and E provide access to the same set of destinations, that are
closer of further away from C and E.
B (which is fast), after it notifies A that it can’t reach C directly will
cause A to send traffic to D. D - dependent on total cost would start happily
sending some traffic to
Very well written draft, 02 has significantly improved readability and
addressed some missing details.
Would support adoption.
Cheers,
Jeff
On Apr 17, 2020, 12:55 PM -0700, Les Ginsberg (ginsberg)
, wrote:
> Folks -
>
> A new version of this draft has been uploaded.
>
> Comments welcomed.
>
> Le
+1
Please do not take my comments about link vs node capabilities, as support for
the solution, they are semantical.
Cheers,
Jeff
On Apr 6, 2020, 8:58 AM -0700, Tony Li , wrote:
>
>
> > This discussion is interesting, but please do not ignore the considerable
> > feedback from multiple folks ind
Very valid comment - When working on MSD - we had exactly same considerations,
since path computation could use different links over different line cards that
may have different capabilities, hence we decided to have per link granularity,
details in RFC 8491
Cheers,
Jeff
On Apr 4, 2020, 7:33 PM
Same here
Regards,
Jeff
> On Apr 3, 2020, at 03:38, Lou Berger wrote:
>
>
> Fwiw I used the link in the agenda without issue. I did the same for RAW
> last week. Also, as host of a different wg interim right before lsr, I
> didn't have to do anything to let people in to the session - they
gt; Aijun Wang
> China Telecom
>
>>> On Apr 3, 2020, at 08:20, Jeff Tantsura wrote:
>>>
>> Robert,
>>
>> We are deviating ;-)
>>
>> There’s no feedback loop from telemetry producers back to the TE headend.
>> The telemetry, either end2end o
Robert,
We are deviating ;-)
There’s no feedback loop from telemetry producers back to the TE headend.
The telemetry, either end2end or postcards is sent to a collector that has the
context of the data and normalizes it so it can be consumed by an external
system, being centralized or distrib
e it is strange that joining virtual LSR meeting
> is not for everyone. I was waiting and tried three times today for host
> approval to join which was not granted.
>
> > On Thu, Apr 2, 2020 at 11:00 PM Jeff Tantsura
> > wrote:
> > > Robert,
> > >
>
Robert,
This is unnecessary leakage of management plane into control plane.
The role of a routing protocol is to distribute: reachability (doh :-)) and any
additional data that could influence routing decision wrt reachability.
There are precedences of using IGP’s for different tasks, e.g. RFC 50
Agree with Acee and Les
Cheers,
Jeff
On Jan 13, 2020, 9:29 AM -0800, Les Ginsberg (ginsberg) ,
wrote:
> I agree with Acee that there is no requirement to identify an interface as
> passive – or (as suggested in this thread) as loopback or tunnel or stub…
>
> Before debating the best encoding for
yes/support
Happy New Year all!
Cheers,
Jeff
On Jan 2, 2020, 11:07 AM -0800, Christian Hopps , wrote:
> This begins a 2 week WG Last Call, ending after Jan 16th, 2020, for
> draft-ietf-lsr-isis-invalid-tlv.
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/
>
> Tony P (other a
I support the adoption, finally OSPF would catch up with IS-IS ;-)
Cheers,
Jeff
On Dec 13, 2019, 3:28 AM -0800, Christian Hopps , wrote:
> Hi LSR WG and Draft Authors,
>
> This begins a 2 week WG adoption poll for the following draft:
>
> https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-reve
I support the adoption
Cheers,
Jeff
On Dec 13, 2019, 3:54 AM -0800, Christian Hopps , wrote:
> Hi LSR WG and Draft Authors,
>
> This begins a 2 week WG adoption poll for the following draft:
>
> https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-bfd-strict-mode/
>
> Please indicate your suppor
Yes/support
Regards,
Jeff
> On Nov 25, 2019, at 21:27, Acee Lindem (acee) wrote:
>
>
> This begins a two week LSR Working Group adoption call for the subject
> document.
>
> https://datatracker.ietf.org/doc/draft-hopps-lsr-yang-isis-reverse-metric/
>
> Please indicate your support or obj
yes/support, missing pieces that need to be added
Cheers,
Jeff
On Oct 2, 2019, 2:28 PM -0700, Christian Hopps , wrote:
> Hi Folks,
>
> This begins a 2 week WG adoption poll for the following:
>
> https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-yang-augmentation-v1/
>
> Please send any comment
yes/support
Cheers,
Jeff
On Oct 2, 2019, 2:27 PM -0700, Christian Hopps , wrote:
> Hi Folks,
>
> This begins a 2 week WG adoption poll for the following:
>
> https://datatracker.ietf.org/doc/draft-acee-lsr-ospfv3-extended-lsa-yang/
>
> Please send any comments to the list by Wednesday Oct 16th, 20
Yes/support
Cheers,
Jeff
>
>
> From: Lsr On Behalf Of Acee Lindem (acee)
> Sent: Friday, August 30, 2019 12:44 PM
> To: lsr@ietf.org
> Cc: m...@ietf.org; lsr-...@ietf.org; draft-ietf-isis-mpls-...@ietf.org
> Subject: [Lsr] Working Group Last Call for "Signaling Entropy Label
> Capability and
Yes/support
Cheers,
Jeff
>
>
> From: Lsr On Behalf Of Acee Lindem (acee)
> Sent: Friday, August 30, 2019 12:42 PM
> To: lsr@ietf.org
> Cc: m...@ietf.org; lsr-...@ietf.org; draft-ietf-ospf-mpls-...@ietf.org
> Subject: [Lsr] Working Group Last Call for "Signaling Entropy Label
> Capability a
Acee,
I agree with your statement.
We (MSD DE’s) have OKed temporary allocation.
I believe WGLC would be in place.
Regards,
Jeff
> On Aug 28, 2019, at 14:30, Acee Lindem (acee) wrote:
>
> Hi Uma,
>
> The draft states that an explicit ERLD is required. I’m not a forwarding ASIC
> expert so I
Support
Regards,
Jeff
> On Aug 13, 2019, at 13:18, Jeff Tantsura wrote:
>
> +1
>
> Cheers,
> Jeff
>> On Aug 13, 2019, 8:07 AM -0700, Robert Raszuk , wrote:
>> > lsr-isis-extended-hierarchy
>>
>> Sounds great !
>>
>> __
+1
Cheers,
Jeff
On Aug 13, 2019, 8:07 AM -0700, Robert Raszuk , wrote:
> > lsr-isis-extended-hierarchy
>
> Sounds great !
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
_
+1 Ketan
Cheers,
Jeff
On Jul 25, 2019, 6:43 PM -0400, Ketan Talaulikar (ketant) ,
wrote:
> Hi Acee/All,
>
> During the LSR WG meeting on Monday, we talked about covering the BGP-LS
> aspects of the following two IGP drafts in those drafts instead of requiring
> a separate document:
>
> https://
Sue,
I support progress of this draft, it addresses real problem.
On Redback side of things we have implemented this around 2013, logic
(proprietary) kept in BFD indeed, so +1 Ketan. I’d document it as an informal
feature, that is recommended (same for YANG)
Cheers,
Jeff
On Jul 25, 2019, 4:27 P
Yes/support
Cheers,
Jeff
> On Jun 12, 2019, at 15:04, Christian Hopps wrote:
>
> This begins a 2 week WG adoption call for draft-ginsberg-lsr-isis-invalid-tlv.
>
> https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-invalid-tlv/
>
> Please express your support or non-support.
>
> Author
+1
Regards,
Jeff
> On May 10, 2019, at 05:22, Ketan Talaulikar (ketant) wrote:
>
> +1
>
> Hi Oliver,
>
> Technically Adj-SID refers to an IGP adjacency between two nodes as per
> RFC8402 semantics. I don't think a passive (stub) link falls under that
> category. It would be better to define
Acee,
Prem is not with BF anymore, I’ll contact him OOB.
I believe Hani is in the similar situation. Will ping him too.
Regards,
Jeff
> On May 9, 2019, at 07:42, Acee Lindem (acee) wrote:
>
> This poll also applies to the ten contributors…
>
> From: Acee Lindem
> Date: Thursday, May 9, 2019
Olivier,
+1 Peter.
There’s has been significant amount of discussions on the topic some time ago,
mostly with Chris Bowers. Please take a look, should provide more context.
Regards,
Jeff
> On Apr 12, 2019, at 15:27, Peter Psenak wrote:
>
> Hi Oliver,
>
> There are two major purposes served b
Acee,
I’m not aware of any IPR that applies to the draft.
Regards,
Jeff
> On Apr 11, 2019, at 18:09, Acee Lindem (acee) wrote:
>
> Authors, Contributors,
>
> Are you aware of any IPR that applies to
> draft-ietf-ospf-te-link-attr-reuse-07?
>
> If so, has this IPR been disclosed in complia
Yes/support
Regards,
Jeff
> On Apr 10, 2019, at 23:24, Acee Lindem (acee) wrote:
>
> LSR Working Group,
>
> This begins a two week WG last call for the subject document. Please enter
> your support or objection to the document before 12:00 AM (EDT) on Wednesday,
> April 25th, 2019.
>
>
+1 Les
Cheers,
Jeff
On Apr 4, 2019, 10:44 AM -0700, Les Ginsberg (ginsberg) ,
wrote:
> But the point that Peter has made needs to be heeded.
> Changing IGP flooding to be unidirectional is non-trivial and should not be
> done w/o justification.
>
> One of the things the FT draft has been very c
yes/support
Cheers,
Jeff
On Mar 19, 2019, 7:30 AM -0700, Acee Lindem (acee) , wrote:
> This begins a 3 WG last call for the subject document. The extra week is
> since the IETF is next week. Please enter your support or objection to the
> document before 12:00 AM (EDT) on Wednesday, April 3rd,
+1 Les.
In general - in ECMP cases LFA is meaningless (any ECMP member is loop-free per
definition) so commonly used technology is fast-rehash, where in case of
failure all the flows that would use the link in question are rehashed over
other links in the bundle and that is done in HW.
Regards
Yes/support
Cheers,
Jeff
On Feb 11, 2019, 2:47 AM -0800, Christian Hopps , wrote:
>
> Hi Folks,
>
> We are starting a 2 week adoption call on draft-li-lsr-dynamic-flooding-02.
>
> The aim of this document is to describe the problem space and standardize a
> way to signal dynamic flooding informat
In favor!
Regards,
Jeff
> On Feb 1, 2019, at 08:02, Les Ginsberg (ginsberg) wrote:
>
> I am in favor of this proposal.
>
> Les
>
>> -Original Message-
>> From: Lsr On Behalf Of Christian Hopps
>> Sent: Friday, February 01, 2019 4:26 AM
>> To: lsr@ietf.org
>> Cc: cho...@chopps.org
>
Yes/support
Regards,
Jeff
> On Dec 1, 2018, at 16:54, Acee Lindem (acee) wrote:
>
> This begins a two-week WG adoption call for the subject draft. As anyone who
> has been following the topic knows, there are a lot of proposal in this
> space. However, as WG co-chair, I believe this simple IS
Yes/support
Regards,
Jeff
> On Nov 19, 2018, at 14:22, Acee Lindem (acee) wrote:
>
> The begins a Working Group Last Call for the subject document. Please post
> for review comments and/or support/objection to this document before 12:00 AM
> UTC on Tuesday, December 4th, 2018.
>
> Other th
sample config consistently
> on every hop. Br.
>
> To me DSCP can be used to map packets to different routing context,
> different plane or can be used as a parameter in flex-algorithm.
>
> Thx,
> R.
>
>
>
>
>
> On Fri, Nov 16, 2018 at 8:19 AM Jeff Tantsura
a bad idea back then,
hasn’t got any better now... besides - now we have got a toolbox that
wasn’t available then.
Cheers,
Jeff
On Thu, Nov 15, 2018 at 22:56 Tony Li wrote:
>
>
> On Nov 15, 2018, at 8:47 PM, Jeff Tantsura
> wrote:
>
> The question is really - what is h
+1 Rob
I have seen number of MBH networks using DSCP to change forwarding - AKA PBR..
The question is really - what is here to standardize?
RSVP-TE use cases mentioned by Rob (CBTS/PBTS in IOS realm) are classical
examples of Policy Based Routing and as such are subject to implementation
detail
Yes/support
On Tue, Nov 13, 2018 at 16:53 Qin Wu wrote:
> I support this work as one of coauthors.
>
>
>
> -Qin
>
> *发件人:* Lsr [mailto:lsr-boun...@ietf.org] *代表 *Acee Lindem (acee)
> *发送时间:* 2018年11月14日 6:11
> *收件人:* lsr@ietf.org
> *主题:* [Lsr] WG Adoption Poll for IGP extension for PCEP security
I support publication of this draft, simple and straightforward.
Cheers,
Jeff
On Oct 23, 2018, 12:49 PM -0700, Acee Lindem (acee) , wrote:
> Speaking as a WG member:
>
> I support publication of this draft. All of my comments are already in this
> revision.
>
> Thanks,
> Acee
>
> From: Lsr on
1 - 100 of 143 matches
Mail list logo