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
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
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
. 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
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
+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
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
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 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
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
+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
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
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
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.
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
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
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
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 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
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
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
rds
>
> Gyan
>
> > On Sun, Oct 11, 2020 at 1:38 PM Jeff Tantsura
> > wrote:
> > > Thanks Ron, indeed! Autocorrect works in mysterious ways ;-)
> > >
> > > Regards,
> > > Jeff
> > >
> > > >
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
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
+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 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
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
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
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,
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
&
+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
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
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
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
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
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
; 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
>
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
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
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
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 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
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
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.
+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 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 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
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
>
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
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
>
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
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
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
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
+1
I’d think the below would work:
lsr for #2
lsr-ospf(ospfv3) / lsr-isis for #1
Cheers,
Jeff
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Wednesday, April 4, 2018 at 13:27
To: Tony Li , "Les Ginsberg (ginsberg)"
Cc: "lsr@ietf.org"
Subject: Re: [Lsr] FW: New Version Notificat
Hi Acee,
I’m aware of the IPR and it has been disclosed in compliance with IETF IPR
rules.
https://datatracker.ietf.org/ipr/3040/
Thanks!
Cheers,
Jeff
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Thursday, April 5, 2018 at 18:22
To: "draft-ietf-ospf-segment-routing-msd...@ietf.
+1
Regards,
Jeff
> On Apr 6, 2018, at 12:25, Acee Lindem (acee) wrote:
>
> I'm fine with the proposed naming conventions for new drafts. Formally:
>
>-lsr-ospf- - OSPF Specific drafts
>-lsr-isis- - IS-IS Specific drafts
>-lsr- - Drafts covering both
> protocol
Acee,
What about ospfv2 vs ospfv3 specifics?
We keep it as before - eg “ospf” covers either or ospfv2, “ospfv3” is for
ospfv3 only?
Regards,
Jeff
> On Apr 6, 2018, at 12:25, Acee Lindem (acee) wrote:
>
> I'm fine with the proposed naming conventions for new drafts. Formally:
>
>-lsr-os
ltiple
address familes).
Thanks,
Acee
On 4/6/18, 5:29 PM, "Jeff Tantsura" wrote:
Acee,
What about ospfv2 vs ospfv3 specifics?
We keep it as before - eg “ospf” covers either or ospfv2, “ospfv3” is
for ospfv3 only?
Support!
Regards,
Jeff
> On Apr 9, 2018, at 21:20, Acee Lindem (acee) wrote:
>
> This draft simply fixes a problem in RFC 7810 that resulted in an
> incompatibility issue with implementations. Given the simplicity of this
> document, I’d like to have an abbreviated WG adoption call of one wee
Hi Ketan
Thank you for your review, I’ll address the comments during this week.
Thanks!
Cheers,
Jeff
From: Lsr on behalf of "Ketan Talaulikar (ketant)"
Date: Thursday, April 12, 2018 at 05:04
To: "Acee Lindem (acee)" , "lsr@ietf.org"
Subject: Re: [Lsr] LSR WG Last Call for "Signaling
Couldn’t agree more!
Yingzhen is great at everything she does, thanks!
(Don’t forget us, at RTGWG ;-))
Regards,
Jeff
> On Apr 23, 2018, at 10:49, Les Ginsberg (ginsberg) wrote:
>
> Bravo!
> Now LSR is a world class WG.
>
> Thanx to Yingzhen for taking on this additional responsibility.
>
>
Support as co-author
Regards,
Jeff
> On Apr 23, 2018, at 07:02, Christian Hopps wrote:
>
> Hi Folks,
>
> We are starting a new 2 week WG last call on
>
> https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/
>
> as there have (*) been some changes to the document since
Hi Tal,
Many thanks for your review!
Coming week I’ll be working to address them as well as on earlier comments
provided by Ketan.
Should be done by the end of the week.
Regards,
Jeff
> On Apr 29, 2018, at 04:08, Tal Mizrahi wrote:
>
> + LSR mailing list.
>
> Cheers,
> Tal.
>
>> On Sun, Ap
Resent-From:
Resent-To: Jeff Tantsura , ,
,
Resent-Date: Sun, 29 Apr 2018 04:08:12 -0700 (PDT)
+ LSR mailing list.
Cheers,
Tal.
On Sun, Apr 29, 2018 at 2:04 PM, Tal Mizrahi wrote:
Hello
I have been selected to do a routing directorate “early” review of this draft.
https
Hi Ketan,
New version (11) should address all your comments, please check and let me know.
ISIS version is being aligned as we speak.
Many thanks!
Cheers,
Jeff
From: Lsr on behalf of "Ketan Talaulikar (ketant)"
Date: Thursday, April 12, 2018 at 05:04
To: "Acee Lindem (acee)" , "ls
Hi Ketan,
Many thanks for you thoughtful reviews, working with the authors to improve the
draft!
Cheers,
Jeff
From: "Ketan Talaulikar (ketant)"
Date: Thursday, May 10, 2018 at 08:05
To: Jeff Tantsura , "Acee Lindem (acee)"
, "lsr@ietf.org"
Subject:
M
>>> To: i-d-annou...@ietf.org
>>> Cc: lsr@ietf.org
>>> Subject: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-11.txt
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
Acee,
I’m no aware of any IPR that applies to this draft.
Regards,
Jeff
> On May 22, 2018, at 16:43, Acee Lindem (acee) wrote:
>
> Are you aware of any IPR that applies to
> draft-ietf-ospf-ospfv3-segment-routing-extensions-12.txt?
>
> If so, has this IPR been disclosed in compliance with IE
Yes/support
Regards,
Jeff
> On May 23, 2018, at 17:28, Christian Hopps wrote:
>
> Hi Folks,
>
> We're starting a 2 week WG Last Call on
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc7810bis/
>
> Please raise any objections or comments before Jun 6th, 2018.
>
> Thanks,
> Chr
Support as co-author
Regards,
Jeff
> On May 23, 2018, at 17:03, Acee Lindem (acee) wrote:
>
> This begins an LSR WG last call for the subject draft. Please send your
> comments to this list prior to 12:00 AM GMT, June 7th, 2018.
> Thanks,
> Acee and Chris
>
> _
Muthu,
LSR would be a more suitable list to post to, CCed.
Regards,
Jeff
> On May 30, 2018, at 18:06, Muthu Arul Mozhi Perumal
> wrote:
>
> Muthu
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Uma,
I’m not aware of any IPR that has not been previously disclosed.
Cheers,
Jeff
From: Lsr on behalf of Uma Chunduri
Date: Monday, June 11, 2018 at 12:18
To:
Subject: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16
(Shepherd write-up)
Dear All,
Are you awar
Uma,
Wrt number of authors, if I recall correctly (I don’t have pointers to the
discussion anymore), given the lengths and involvement of the authors currently
on the front page, as an exception - both ospf and isis sr drafts would keep
the initial number of authors.
Thanks,
Jeff
> On Jun 11,
Chris,
I'm not aware of any IPR outside of that already disclosed.
Thanks,
Jeff
Cheers,
Jeff
On 6/13/18, 06:37, "Christian Hopps" wrote:
[Sigh, I quoted the wrong email and mixed things up -- thanks Bruno!]
Authors,
The original WGLC requested the authors indicate if th
Gunter,
I have nothing to add to Les' comments, 100% agree.
Cheers,
Jeff
On 6/13/18, 08:42, "Idr on behalf of Les Ginsberg (ginsberg)"
wrote:
Gunter -
I strongly support Option #2 and strongly support Ketan's recommendation
that an MSD sub-type be used to advertise ERLD.
Thi
Robin,
Pretty much same comment as Acee - I'm not clear as to why...
Protocol YANG models developed in the last years clearly provide much better
and more scalable approach to what has been proposed in the draft, since we are
talking is-is - look at notifications in draft-ietf-isis-yang-isis-cfg
Hi,
Please see inline (MSD section).
Hope this clarifies, thanks!
Cheers,
Jeff
[jeff] both IGP drafts have identical description of the BMI-MSD:
“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS labels a
node is capable of imposing, including all service/tra
We would like to define the NMP based on the usecases. That is, a specific
> set of parameters exported by NMP can satisfy the purpose of a specific
> usecase. Thus the protocol can be deployed incrementally.
>
>
> Best Regards,
> Robin
>
>
>
> -Original Messa
e Internet-Drafts
directories.
This draft is a work item of the Link State Routing WG of the IETF.
Title : Signaling MSD (Maximum SID Depth) using IS-IS
Authors : Jeff Tantsura
Uma Chunduri
Not going to repeat all the comments made before, +1
Regards,
Jeff
> On Jul 24, 2018, at 23:08, Tony Przygienda wrote:
>
> pretty obvious +1 here
>
> --- tony
>
>> On Tue, Jul 24, 2018 at 3:41 AM Rob Shakir wrote:
>> +1 to Peter. We should not define fragile solutions within the IETF.
>>
+1
Nothing really to add to Les’ comments
Regards,
Jeff
> On Aug 3, 2018, at 09:32, Les Ginsberg (ginsberg)
> wrote:
>
> Bruno –
>
> I appreciate why you suggest per-prefix signaling for ELC, but I would prefer
> that we not employ that model.
>
> ELC is clearly a node capability – signa
Stephane,
Leaving protocol semantics aside – do you see a real use cases for
multi-area/multi-protocol scenarios?
For all practical reasons (and to repeat Gunter’s comments) – this info is
really of value for the controller, from distribution prospective,
source->BGP-LS speaker, deployment
rg" ,
Christian Hopps
Subject: RE: AD Review of draft-ietf-isis-segment-routing-msd-13
Resent-From:
Resent-To: Jeff Tantsura , ,
,
Resent-Date: Wed, 15 Aug 2018 15:51:43 -0700 (PDT)
Alvaro –
A very thorough review – thanx.
Jeff has the pen – but I think he is on holiday at the mo
Acee,
The draft is in good shape, support.
Cheers,
Jeff
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Friday, August 17, 2018 at 13:09
To: "lsr@ietf.org"
Subject: [Lsr] LSR Working Last Call for draft-ietf-ospf-yang
This begins an LSR WG last call for the subject draft. Ple
:53
To:
Cc: , , "Acee Lindem (acee)"
Subject: AD Review of draft-ietf-ospf-segment-routing-msd-15
Resent-From:
Resent-To: Jeff Tantsura , ,
,
Resent-Date: Wed, 15 Aug 2018 13:53:45 -0700 (PDT)
Dear authors:
I just finished reading this document. I have several comments an
Tom,
Many thanks, great comments (as always)!
Regards,
Jeff
> On Aug 22, 2018, at 08:41, tom petch wrote:
>
> Original Message -
> From: "Jeff Tantsura"
> Sent: Friday, August 17, 2018 9:14 PM
>
> Acee,
>
> The draft is in good shape, suppo
Acee,
I support the adoption and quick progress of this, clear and useful document..
Regards,
Jeff
> On Aug 22, 2018, at 06:42, Acee Lindem (acee)
> wrote:
>
> This draft has been presented several times and I believe there is general
> agreement that IS-IS graceful restart signaling enhance
+1 Tony
We could start with a document, similar to dc-routing requirements one we did
in RTGWG before chartering RIFT and LSVR.
Would help to disambiguate requirements from claims and have apple to apple
comparison.
Doing it on github was a good experience.
Regards,
Jeff
> On Aug 22, 2018, at
other work and be a
wg/design team effort.
Hope this clarifies.
Cheers,
Jeff
From: "Les Ginsberg (ginsberg)"
Date: Wednesday, August 22, 2018 at 13:10
To: Tony Przygienda
Cc: Jeff Tantsura , Tony Li ,
"lsr@ietf.org" , "Acee Lindem (acee)"
Subject: RE
9
To: "Les Ginsberg (ginsberg)"
Cc: Jeff Tantsura , Tony Li ,
"lsr@ietf.org" , "Acee Lindem (acee)"
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward
I do think to solve all the data centers (massive or small) requirement,
this discussio
by such a document. And to be
completely honest, the requirements are pretty straightforward for
anyone that is familiar with the protocols' operation.
my 2c,
Peter
On 22/08/18 18:42 , Jeff Tantsura wrote:
> +1 Tony
>
> We could start with a docu
Hi Tal,
Many thanks for your comments.
Updated draft has been published for your review.
Cheers,
Jeff
From: Tal Mizrahi
Date: Monday, August 20, 2018 at 23:45
To: , ,
,
Cc: , "Yemin (Amy)"
Subject: RtgDir review: draft-ietf-ospf-segment-routing-msd
Resent-From:
Resen
+1
Having actual key in the protocol - similar issues as with BGP(see recent BGP
discussion with Linda), would be a severe security risk.
Regards,
Jeff
> On Aug 25, 2018, at 10:41, Acee Lindem (acee)
> wrote:
>
> Hi Qin,
>
> I believe it is a significant security exposure to include the ac
Gents,
Thanks for the great review!
Both drafts are on the Telechat tomorrow, would be great to come to the
agreement, so ospf draft could be updated before tomorrow’s call.
Regards,
Jeff
> On Sep 26, 2018, at 13:21, Les Ginsberg (ginsberg) wrote:
>
> Julien -
>
> Thanx for the additional c
Gents,
I’m 100% with Les here, going into platform/asic specifics within this document
would inevitably create ambiguity.
Cheers,
Jeff
On Oct 2, 2018, 11:20 AM -0700, Les Ginsberg (ginsberg) ,
wrote:
> Bruno –
>
> Trimming the thread…
>
> [Les2:] Label imposition is meant to cover both the SWAP
Great stuff, long time due!
Cheers,
Jeff
On Oct 19, 2018, 12:23 PM -0700, Les Ginsberg (ginsberg) ,
wrote:
> Folks -
>
> This new draft discusses IS-IS protocol behaviors related to handling TLVs
> that are either:
>
> o Not recognized/supported by an implementation
> o Present in a PDU where th
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
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
+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
1 - 100 of 143 matches
Mail list logo