[Lsr] Re: WG Last Call for draft-ietf-lsr-ospf-admin-tags

[Jeff Tantsura]

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 this work.
> 
> Thanks,
> Chris.
> ___
> Lsr mailing list -- lsr@ietf.org
> To unsubscribe send an email to lsr-le...@ietf.org

___
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org

Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[Jeff Tantsura]

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. 
> 
> Please send your support or objection to this before March 5th, 2024. 
> 
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

[Jeff Tantsura]

Robert,In context of LLM (10% of that for DLRM) training clusters, towards 2024/25 we would be looking to up to 8K end-points in a 3 stage leaf-spine fabric and up to 64-256K in 5 stages.Virtualization and how it is instantiated might significantly change amount/distribution of state in underlay/overlay.Obviously, these are hyperscale size deployments, many will be running 10-30 switches fabrics, where anything could work. BGP seems to work just fine, some data plane signaling could be used as a near real time augmentation to “slow but stable” control plane.Cheers,JeffOn Nov 26, 2023, at 14:30, Robert Raszuk  wrote:Hey Jeff, Could you be so kind and defined term: "scaled-out leaf-spine fabrics" ?Specifically folks watching us here would highly appreciate if we state max target nodes with vanilla ISIS and max target nodes when your ISIS implementation supports draft-ietf-lsr-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 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 (publicly available) - they use BGP as the routing protocol to exchange reachability (and build ECMP sets) and provide a backup if controller computed next hop goes away/before new one has been computed.
Open R is used northbound to expose the topology (in exactly same way - BGP-LS could be used).

To summarize: an LS protocol brings no additional value in scaled-out leaf-spine fabrics, without significant modifications -  it doesn’t work in irregular topologies such as DF, etc.
Existing proposals - there are shipping implementations and experience in operating it, have proven their relative value in suitable deployments.

Cheers,
Jeff

> On Nov 26, 2023, at 12:20, Acee Lindem <acee.i...@gmail.com> wrote:
> 
> Speaking as WG member:
> 
> I agree. The whole Data Center IGP flooding discussion went on years ago and the simplistic enhancement proposed in the subject draft is neither relevant or useful now.
> 
> Thanks,
> Acee
> 
>> On Nov 24, 2023, at 11:55 PM, Les Ginsberg (ginsberg) 40cisco@dmarc.ietf.org> wrote:
>> 
>> Xiaohu –
>> I also point out that there are at least two existing drafts which specifically address IS-IS flooding reduction in CLOS networks and do so in greater detail and with more robustness than what is in your draft:
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-distoptflood/
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-spine-leaf-ext/
>> I do not see a need for yet another draft specifically aimed at CLOS networks.
>> Note that work on draft-ietf-lsr-isis-spine-leaf-ext was suspended due to lack of interest in deploying an IGP solution in CLOS networks.
>> You are suggesting in draft-xu-lsr-fare that AI is going to change this. Well, maybe, but if so I think we should return to the solutions already available and prioritize work on them.
>>    Les
>>  From: Lsr <lsr-boun...@ietf.org> On Behalf Of Tony Li
>> Sent: Thursday, November 23, 2023 8:39 AM
>> To: xuxiaohu_i...@hotmail.com
>> Cc: lsr@ietf.org
>> Subject: Re: [Lsr] New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt
>> Hi,
>> What you’re proposing is already described in IS-IS Mesh Groups (https://www.rfc-editor.org/rfc/rfc2973.html) and improved upon in Dynamic Flooding (https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding).
>> Regards,
>> Tony
>> 
>> 
>> On Nov 23, 2023, at 8:29 AM, xuxiaohu_i...@hotmail.com wrote:
>> Hi all,
>> Any comments or suggestions are welcome.
>> Best regards,
>> Xiaohu
>> 发件人: internet-dra...@ietf.org <internet-dra...@ietf.org>
>> 日期: 星期三, 2023年11月22日 11:37
>> 收件人: Xiaohu Xu <xuxiaohu_i...@hotmail.com>
>> 主题: New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt
>> A new version of Internet-Draft draft-xu-lsr-flooding-reduction-in-clos-01.txt
>> has been successfully submitted by Xiaohu Xu and posted to the
>> IETF repository.
>> 
>> Name:     draft-xu-lsr-flooding-reduction-in-clos
>> Revision: 01
>> Title:    Flooding Reduction in CLOS Networks
>> Date:     2023-11-22
>> Group:    Individual Submission
>> Pages:    6
>> URL:      https://www.ietf.org/archive/id/draft-xu-lsr-flooding-reduction-in-clos-01.txt
>> Status:   https://datatracker.ietf.org/doc/draft-xu-lsr-flooding-reduction-in-clos/
>> HTMLized:

Re: [Lsr] New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

[Jeff Tantsura]

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 
(publicly available) - they use BGP as the routing protocol to exchange 
reachability (and build ECMP sets) and provide a backup if controller computed 
next hop goes away/before new one has been computed.
Open R is used northbound to expose the topology (in exactly same way - BGP-LS 
could be used).

To summarize: an LS protocol brings no additional value in scaled-out 
leaf-spine fabrics, without significant modifications -  it doesn’t work in 
irregular topologies such as DF, etc.
Existing proposals - there are shipping implementations and experience in 
operating it, have proven their relative value in suitable deployments.

Cheers,
Jeff

> On Nov 26, 2023, at 12:20, Acee Lindem  wrote:
> 
> Speaking as WG member:
> 
> I agree. The whole Data Center IGP flooding discussion went on years ago and 
> the simplistic enhancement proposed in the subject draft is neither relevant 
> or useful now.
> 
> Thanks,
> Acee
> 
>> On Nov 24, 2023, at 11:55 PM, Les Ginsberg (ginsberg) 
>>  wrote:
>> 
>> Xiaohu –
>> I also point out that there are at least two existing drafts which 
>> specifically address IS-IS flooding reduction in CLOS networks and do so in 
>> greater detail and with more robustness than what is in your draft:
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-distoptflood/
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-spine-leaf-ext/
>> I do not see a need for yet another draft specifically aimed at CLOS 
>> networks.
>> Note that work on draft-ietf-lsr-isis-spine-leaf-ext was suspended due to 
>> lack of interest in deploying an IGP solution in CLOS networks.
>> You are suggesting in draft-xu-lsr-fare that AI is going to change this. 
>> Well, maybe, but if so I think we should return to the solutions already 
>> available and prioritize work on them.
>>Les
>>  From: Lsr  On Behalf Of Tony Li
>> Sent: Thursday, November 23, 2023 8:39 AM
>> To: xuxiaohu_i...@hotmail.com
>> Cc: lsr@ietf.org
>> Subject: Re: [Lsr] New Version Notification for 
>> draft-xu-lsr-flooding-reduction-in-clos-01.txt
>> Hi,
>> What you’re proposing is already described in IS-IS Mesh Groups 
>> (https://www.rfc-editor.org/rfc/rfc2973.html) and improved upon in Dynamic 
>> Flooding 
>> (https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding).
>> Regards,
>> Tony
>> 
>> 
>> On Nov 23, 2023, at 8:29 AM, xuxiaohu_i...@hotmail.com wrote:
>> Hi all,
>> Any comments or suggestions are welcome.
>> Best regards,
>> Xiaohu
>> 发件人: internet-dra...@ietf.org 
>> 日期: 星期三, 2023年11月22日 11:37
>> 收件人: Xiaohu Xu 
>> 主题: New Version Notification for 
>> draft-xu-lsr-flooding-reduction-in-clos-01.txt
>> A new version of Internet-Draft 
>> draft-xu-lsr-flooding-reduction-in-clos-01.txt
>> has been successfully submitted by Xiaohu Xu and posted to the
>> IETF repository.
>> 
>> Name: draft-xu-lsr-flooding-reduction-in-clos
>> Revision: 01
>> Title:Flooding Reduction in CLOS Networks
>> Date: 2023-11-22
>> Group:Individual Submission
>> Pages:6
>> URL:  
>> https://www.ietf.org/archive/id/draft-xu-lsr-flooding-reduction-in-clos-01.txt
>> Status:   
>> https://datatracker.ietf.org/doc/draft-xu-lsr-flooding-reduction-in-clos/
>> HTMLized: 
>> https://datatracker.ietf.org/doc/html/draft-xu-lsr-flooding-reduction-in-clos
>> Diff: 
>> https://author-tools.ietf.org/iddiff?url2=draft-xu-lsr-flooding-reduction-in-clos-01
>> 
>> Abstract:
>> 
>>   In a CLOS topology, an OSPF (or ISIS) router may receive identical
>>   copies of an LSA (or LSP) from multiple OSPF (or ISIS) neighbors.
>>   Moreover, two OSPF (or ISIS) neighbors may exchange the same LSA (or
>>   LSP) simultaneously.  This results in unnecessary flooding of link-
>>   state information, which wastes the precious resources of OSPF (or
>>   ISIS) routers.  Therefore, this document proposes extensions to OSPF
>>   (or ISIS) to reduce this flooding within CLOS networks.  The
>>   reduction of OSPF (or ISIS) flooding is highly beneficial for
>>   improving the scalability of CLOS networks.
>> 
>> 
>> 
>> The IETF Secretariat
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> 
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-liu-lsr-mpls-inspection-msd-01.txt

[Jeff Tantsura]

+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.
> 
> Different chips will necessarily have different low layer micro-code. That 
> already exists today, across vendors.
> 
> Tony
> 
> 
>> On Aug 28, 2023, at 11:44 PM, Vasilenko Eduard 
>>  wrote:
>> 
>> Hi Tony,
>> Do you know any product that supports different label (or SID) stacks on 
>> different PFEs? (Not mandatory to disclose the vendor)
>> I remember many major upgrades for many vendors and all the time the whole 
>> router supported the “common denominator”.
>> Of course, it is possible to develop code and micro-code to support 
>> different label stacks on different PFEs but looks like no one vendor has 
>> found a business case for such a big development program.
>> PS: I am not sure, I may missed a good example.
>> Eduard
>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Tony Li
>> Sent: Tuesday, August 29, 2023 5:36 AM
>> To: liu.ya...@zte.com.cn
>> Cc: Les Ginsberg ; mpls ; lsr@ietf.org
>> Subject: Re: [Lsr] New Version Notification for 
>> draft-liu-lsr-mpls-inspection-msd-01.txt
>>  
>>  
>> Hi Yao,
>>  
>> Please consider the case of a modular node with a number of different line 
>> cards, where the line cards are based on different forwarding engines.
>>  
>> RLD needs to be link specific.
>>  
>> Regards,
>> Tony
>>  
>> 
>> 
>> On Aug 28, 2023, at 6:55 PM, > > > > wrote:
>>  
>> Hi Les,
>> 
>> Thanks a lot for your review and comments.
>> 
>> This new MSD is a per-node capability just like ERLD-MSD, mainly because it 
>> represents how many MPLS labels the node can read, and it is not related 
>> with the links.
>> 
>> And the description in this draft you mentioned is written taking example by 
>> RFC9088(section 4. Advertising ERLD Using IS-IS).
>> 
>> I'll explicitly state the scope of the new MSD in the next version. 
>> 
>>  
>> 
>> Best Regards,
>> 
>> Yao
>> 
>> Original
>> From: LesGinsberg(ginsberg) mailto:ginsb...@cisco.com>>
>> To: 刘尧00165286;m...@ietf.org > >;lsr@ietf.org mailto:lsr@ietf.org>>;
>> Date: 2023年08月28日 20:57
>> Subject: RE: [Lsr] Fw: New Version Notification for 
>> draft-liu-lsr-mpls-inspection-msd-01.txt
>> Yao –
>>  
>> Both RFC 8476(OSPF) and RFC 8491(IS-IS) define MSD advertisements with 
>> per-link scope and per-node scope.
>>  
>> Your draft only states: 
>>  
>> “If a router has multiple interfaces with different capabilities of
>>reading the maximum label stack depth, the router MUST advertise the
>>smallest value found across all its interfaces.”
>>  
>> This suggests that you intend only to advertise a per-node capability – but 
>> as you don’t explicitly state that – and you don’t provide a reason why a 
>> per link capability isn’t applicable, I am unclear as to what your 
>> intentions are here.
>>  
>> Could you clarify whether you intend to support both per link and per node 
>> capability – and if not why not?
>>  
>> Thanx.
>>  
>>Les
>>  
>>  
>> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
>> liu.ya...@zte.com.cn 
>> Sent: Monday, August 28, 2023 12:33 AM
>> To: m...@ietf.org ; lsr@ietf.org 
>> Subject: [Lsr] Fw: New Version Notification for 
>> draft-liu-lsr-mpls-inspection-msd-01.txt
>>  
>> Hi All,
>> 
>> A new version of draft-liu-lsr-mpls-inspection-msd has just been uploaded.
>> 
>> In this document, a new type of MSD is defined to reflect the Readable Label 
>> Depth(RLD), which helps in the MPLS MNA solution.
>> 
>> In this version, the main update is that some description is added to 
>> explain why a new MSD is preferred instead of the ERLD-MSD.
>> 
>> Currently this new MSD is called Base MPLS Inspection MSD, it may be changed 
>> to a more straightforward name like RLD-MSD based on the description in the 
>> MNA architecture/solution document. 
>> 
>> Your comments and suggestions are more than welcome!
>> 
>>  
>> 
>> Thanks,
>> 
>> Yao
>> 
>> Original
>> From: internet-dra...@ietf.org  
>> mailto:internet-dra...@ietf.org>>
>> Date: 2023年08月28日 14:55
>> Subject: New Version Notification for 
>> draft-liu-lsr-mpls-inspection-msd-01.txt
>> A new version of Internet-Draft draft-liu-lsr-mpls-inspection-msd-01.txt has
>> been successfully submitted by Yao Liu and posted to the
>> IETF repository.
>> 
>> Name: draft-liu-lsr-mpls-inspection-msd
>> Revision: 01
>> Title:Signaling Base MPLS Inspection MSD
>> Date: 2023-08-27
>> Group:Individual Submission
>> Pages:7
>> URL:  
>> https://www.ietf.org/archive/id/draft-liu-lsr-mpls-inspection-msd-01.txt
>> Status:   https://datatracker.ietf.org/doc/draft-liu-lsr-mpls-i

Re: [Lsr] WG Last Call for draft-ietf-lsr-ospfv3-extended-lsa-yang

[Jeff Tantsura]

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 IPR related to this work.
> 
> Thanks,
> Chris.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Call for "IGP Flexible Algorithms Reverse Affinity Constraint" - draft-ppsenak-lsr-igp-flex-algo-reverse-affinity-01

[Jeff Tantsura]

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-reverse-affinity-01. Please express your support or objection on this list prior to Saturday, March 25th, 2023. 

We now have RFC 9350 (IGP Flex Also) and have deployed implementations as well as several other LSR WG documents with IGP Flex Algorithm extensions. It makes sense adi to adoption this simple extension as well that has been at a previous IETF.  


Thanks,
Acee 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
-- Gyan MishraNetwork Solutions Architect Email gyan.s.mis...@verizon.comM 301 502-1347
___Lsr mailing listLsr@ietf.orghttps://www.ietf.org/mailman/listinfo/lsr___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call for draft-ietf-lsr-rfc8920bis-00

[Jeff Tantsura]

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 Last Call for draft-ietf-lsr-rfc8920bis-00  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.  
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for "IS-IS Optimal Distributed Flooding for Dense Topologies" - draft-white-lsr-distoptflood-03

[Jeff Tantsura]

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 RIFT already as well, implemented and works "fine" [without further defining "fine" except obvious property of maintaining consistent databases with less flooding and no choke-points]. Completely distributed algorithm without any signalling and flexible deployment property (can be mixed in any fashion with nodes not supporting the feature) should allow us to introduce it without significant risk into existing networks. --- tony On Tue, Nov 22, 2022 at 9:02 PM Acee Lindem (acee) 40cisco@dmarc.ietf.org> wrote:







LSR WG, 
 
This begins a 2 week WG adoption call for the following draft:
 
https://datatracker.ietf.org/doc/draft-white-lsr-distoptflood/
 
The draft would be adopted on the Informational or Experimental track.

 
Please indicate your support or objection by December 7th, 2022.

Also indicate whether you believe it should be Informational or Experimental track.

 
Thanks,
Acee
 
 



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___Lsr mailing listLsr@ietf.orghttps://www.ietf.org/mailman/listinfo/lsr___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo

[Jeff Tantsura]

+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 extension that requires ALL routers – whether they support flex algo or not – to utilize a new advertisement when computing algo 0 SPF is necessary.Your rationale for this is that this allows you to use IGP Metric for flex algo in cases where the IGP metric would have been set to maximum.But we already have the ability to define metrics specific to flex algo – and this is greatly enhanced by the generic metric defined in https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/ Requiring a non backwards compatible extension to be used in base protocol operation in order to support a new feature is exactly what we MUST NOT do when introducing protocol extensions. My opinion is unchanged – this is a bad idea – and completely unnecessary.    Les  From: 龚立艳  Sent: Friday, August 12, 2022 2:16 AMTo: lsr@ietf.org; Les Ginsberg (ginsberg) ; shraddha Subject: Re:Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo  Hi Shraddha and Les, Sorry for late reply and thanks for your comments.  Yes, the maximum link metric mechanism is an option as described in section 4 of the draft.  But, it has two defects which we also wanted to discuss in ietf 114 meeting. Firstly, it restricts the Flex-Algorithm from using IGP-Cost as its metric-type.Secondly, it does not work with OSPF. For OSPF,the links with maximummetric value(65535) are also included in the SPF calculation,even if not preferred. If there are no other preferred paths,the Flex-Algoritnm links will still affect the result of thenormal SPF calculation. Due to the time constraints,The presentation has been moved to the interim meeting on 2022-09-21. For more detail, please refer to the slides.https://datatracker.ietf.org/meeting/114/materials/slides-114-lsr-13-exclusive-link-for-flex-algo-00.In view of these two cases, new protocol extension becomes necessary.  As for the backward incompatible issues, we think it can be avoided by deployment.  For example, the new extension should be deployed in sync with the Flex-Algo feature, so that all the routers in one IGP domain will run the same software version.  Looking forward to your reply. Best Regards,Liyan  邮件原文发件人："Les Ginsberg \\(ginsberg\\)" 收件人：Shraddha Hegde  ,"lsr@ietf.org" 抄　送: (无)发送时间：2022-07-29 21:14:08主题：Re: [Lsr] Comments on draft-gong-lsr-exclusive-link-for-flex-algo    I fully agree with Shraddha. In fact Section 4 of the draft makes clear why no protocol extensions are needed.    Les From: Lsr  On Behalf Of Shraddha HegdeSent: Friday, July 29, 2022 2:18 AMTo: lsr@ietf.orgSubject: [Lsr] Comments on draft-gong-lsr-exclusive-link-for-flex-algo Authors,  I suggest that the usecase can be satisfied using the backward compatibleMaximum link metric mechanism defined in the draft.I don’t see any need to define protocol extensions,that are backward incompatible and can cause serious issues in the networkin the presence of older implementations. RgdsShraddha Juniper Business Use Only  
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-ppsenak-lsr-rfc8920bis-02

[Jeff Tantsura]

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  On Behalf Of Christian Hopps
>> Sent: Monday, August 8, 2022 6:17 AM
>> To: lsr@ietf.org
>> Cc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org
>> Subject: [Lsr] WG adoption call for draft-ppsenak-lsr-rfc8920bis-02
>> 
>> [External Email. Be cautious of content]
>> 
>> 
>> 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 applies to these drafts.
>> 
>> Thanks,
>> Chris.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Idr] IGP Monitoring Protocol

[Jeff Tantsura]

Thanks Sue!We don’t have to always reinvent the wheel (at least not every time 😊)I’m aware of at least 1 implementation streaming LSDB for TE consumers (gRPC)There are most probably some other vendor specific encodings/methods to steam to do that I believe – there has been some work around Kafka. 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 Monitoring Protocol Jeff: An interim sounds like a good plan.   [IDR-chair hat] Alvaro has indicated that since all of the proposal received on the IDR list are new protocol proposals, Capturing IDR’s input on BGP-LS problems and potential solutions is appropriate for IDR as BGP-LS home. Refining any potential non-BGP solutions is outside of the scope of IDR.  [IDR-chair hat off] [rtgwg WG member] I’d love to attend an interim on this topic.  Sue Hares  From: Jeff Tantsura  Sent: Saturday, July 9, 2022 3:40 PMTo: Robert Raszuk Cc: Acee Lindem (acee) ; lsr ; i...@ietf.org; Susan Hares ; g...@ietf.org g...@ietf.org Subject: Re: [Idr] [Lsr] IGP Monitoring Protocol  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 progressing.Cheers,Jeff On Jul 8, 2022, at 14:44, Robert Raszuk <rob...@raszuk.net> wrote:Hi Acee,  Yes, by all means input from the operator's community is needed. It can be collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute. We have already seen input from some operators and their opinion on adding and distributing more and more link state protocol and topology data in BGP. More such input is very welcome.  And to your point about RFC9086 - I see nothing wrong in keeping BGP information in BGP. So IGP Monitoring Protocol does not target to shut down BGP-LS. It only aims to remove 100% of non BGP sourced information from it.  Controllers which today listen to BGP-LS need a number of information sources and that spread will only keep increasing as more inputs are becoming necessary for its computations.  Regards,Robert.  On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee) <a...@cisco.com> wrote:Hi Robert, From: Robert Raszuk <rob...@raszuk.net>Date: Friday, July 8, 2022 at 4:36 PMTo: Acee Lindem <a...@cisco.com>Cc: lsr <lsr@ietf.org>, IDR List <i...@ietf.org>, Susan Hares <sha...@ndzh.com>Subject: Re: [Lsr] IGP Monitoring Protocol Hi Acee, Thank you. I was not planning to present it in the upcoming IETF.  > Let’s see how many stakeholders actually want to this protocol - then we can talk about a WG home.   An alternative approach could be to see how many stakeholders do not want to further (for no good reason) to trash BGP. That to me would be in this specific case a much better gauge.   In that case, it seems to me that this discussion should be relegated to IDR. Note that there is already non-IGP information transported in BGP-LS, e.g., Egress Peer Engineering (https://datatracker.ietf.org/doc/rfc9086/). I implemented this on our data center routers (NXOS) years and it is solely BGP specific.  Thanks,Acee Kind regards,Robert  On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee) <a...@cisco.com> wrote:Speaking as WG chair:  From: Lsr <lsr-boun...@ietf.org> on behalf of Robert Raszuk <rob...@raszuk.net>Date: Friday, July 8, 2022 at 3:21 PMTo: lsr <lsr@ietf.org>Cc: IDR List <i...@ietf.org>, Susan Hares <sha...@ndzh.com>Subject: [Lsr] IGP Monitoring Protocol Dear LSR WG, Based on ongoing discussion in respect to the future of BGP-LS I committed myself to put together an alternate proposal.  The main goal is not to just publish a -00 version of the draft using different encapsulation. The goal is to make a useful tool which can help to export link state information from network elements as well as assist in network observability.  The IGP Monitoring Protocol (IMP) draft has been posted and should be available at: https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/ One of the key points I wanted to accomplish was full backwards compatibility with TLVs defined for BGP-LS. In parallel other formats (optional) are also supported.  The PUB-SUB nature or FILTERING capabilities are in the spec however as noted in the deployment section there is no expectation that this should be supported directly on routers. Concept of Producer's Proxies has been introduced to support this added functionality as well as provide fan-out (analogy to BGP route reflectors).  I encourage everyone interested to take a look and provide comments. At this point this document is nothing more than my 

Re: [Lsr] [Idr] IGP Monitoring Protocol

[Jeff Tantsura]

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 progressing.

Cheers,
Jeff

> On Jul 8, 2022, at 14:44, Robert Raszuk  wrote:
> 
> 
> Hi Acee, 
> 
> Yes, by all means input from the operator's community is needed. It can be 
> collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute. We 
> have already seen input from some operators and their opinion on adding and 
> distributing more and more link state protocol and topology data in BGP. More 
> such input is very welcome. 
> 
> And to your point about RFC9086 - I see nothing wrong in keeping BGP 
> information in BGP. So IGP Monitoring Protocol does not target to shut down 
> BGP-LS. It only aims to remove 100% of non BGP sourced information from it. 
> 
> Controllers which today listen to BGP-LS need a number of information sources 
> and that spread will only keep increasing as more inputs are becoming 
> necessary for its computations. 
> 
> Regards,
> Robert.
> 
> 
>> On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee)  wrote:
>> Hi Robert,
>> 
>>  
>> 
>> From: Robert Raszuk 
>> Date: Friday, July 8, 2022 at 4:36 PM
>> To: Acee Lindem 
>> Cc: lsr , IDR List , Susan Hares 
>> 
>> Subject: Re: [Lsr] IGP Monitoring Protocol
>> 
>>  
>> 
>> Hi Acee,
>> 
>>  
>> 
>> Thank you. I was not planning to present it in the upcoming IETF. 
>> 
>>  
>> 
>> > Let’s see how many stakeholders actually want to this protocol - then we 
>> > can talk about a WG home.  
>> 
>>  
>> 
>> An alternative approach could be to see how many stakeholders do not want to 
>> further (for no good reason) to trash BGP. That to me would be in this 
>> specific case a much better gauge.  
>> 
>>  
>> 
>> In that case, it seems to me that this discussion should be relegated to 
>> IDR. Note that there is already non-IGP information transported in BGP-LS, 
>> e.g., Egress Peer Engineering (https://datatracker.ietf.org/doc/rfc9086/). I 
>> implemented this on our data center routers (NXOS) years and it is solely 
>> BGP specific.
>> 
>>  
>> 
>> Thanks,
>> 
>> Acee
>> 
>>  
>> 
>> Kind regards,
>> 
>> Robert
>> 
>>  
>> 
>>  
>> 
>> On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee)  wrote:
>> 
>> Speaking as WG chair:
>> 
>>  
>> 
>> From: Lsr  on behalf of Robert Raszuk 
>> 
>> Date: Friday, July 8, 2022 at 3:21 PM
>> To: lsr 
>> Cc: IDR List , Susan Hares 
>> Subject: [Lsr] IGP Monitoring Protocol
>> 
>>  
>> 
>> Dear LSR WG,
>> 
>>  
>> 
>> Based on ongoing discussion in respect to the future of BGP-LS I committed 
>> myself to put together an alternate proposal. 
>> 
>>  
>> 
>> The main goal is not to just publish a -00 version of the draft using 
>> different encapsulation. The goal is to make a useful tool which can help to 
>> export link state information from network elements as well as assist in 
>> network observability. 
>> 
>>  
>> 
>> The IGP Monitoring Protocol (IMP) draft has been posted and should be 
>> available at:
>> 
>>  
>> 
>> https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/
>> 
>>  
>> 
>> One of the key points I wanted to accomplish was full backwards 
>> compatibility with TLVs defined for BGP-LS. In parallel other formats 
>> (optional) are also supported. 
>> 
>>  
>> 
>> The PUB-SUB nature or FILTERING capabilities are in the spec however as 
>> noted in the deployment section there is no expectation that this should be 
>> supported directly on routers. Concept of Producer's Proxies has been 
>> introduced to support this added functionality as well as provide fan-out 
>> (analogy to BGP route reflectors). 
>> 
>>  
>> 
>> I encourage everyone interested to take a look and provide comments. At this 
>> point this document is nothing more than my individual submission. Offline I 
>> have had few conversations with both operators and vendors expressing some 
>> level of interest in this work. How we proceed further (if at all :) depends 
>> on WG feedback. 
>> 
>>  
>> 
>> Kind regards,
>> 
>> Robert.
>> 
>>  
>> 
>> PS, I do believe this work belongs in LSR WG pretty squerly. 
>> 
>>  
>> 
>> Let’s see how many stakeholders actually want to this protocol - then we can 
>> talk about a WG home.  By stakeholders, I mean operators and vendors who are 
>> committed to implementing and deploying it - not simply those who you are 
>> able to enlist as co-authors. Note that our IETF 114 LSR agenda is full 
>> (with multiple agenda items not making the cut). 
>> 
>>  
>> 
>> Thanks,
>> 
>> Acee 
>> 
>>  
>> 
>>  
>> 
>>  
>> 
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Jeff Tantsura]

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 problem space, there was a lot of good work 
> done by the authors, as well as, a lot of WG energy. We had general consensus 
> on a solution that supported both distributed and centralized flooding 
> algorithms. There was also prototyping and implementation done in IS-IS by 
> multiple parties and codepoints were allocated through the early allocation 
> process. 
> 
> At this point, it seems the energy has waned. In my opinion, this draft 
> represents a fairly significant protocol enhancement and it wouldn't make 
> sense to publish a "Standards Track" without more support and implementation 
> momentum. Additionally, while prototyping and implementation has been done 
> for IS-IS, none of this has been done for OSPF (at least not to my 
> knowledge). Hence, if we are going to move forward, it seems that the 
> "Experimental" is the right document status. "Historic" wouldn't be the right 
> status unless we were going for a short draft that just reserved the early 
> allocation code points. 
> 
> Thanks,
> Acee
> 
> On 6/13/22, 2:12 PM, "Lsr on behalf of Tony Li"  behalf of tony...@tony.li> wrote:
> 
> 
>Les,
> 
>The market looked at the technology and decided that it was not 
> interested.  If that’s not the definition of ‘obsolete’, I don’t know what is.
> 
>Tony
> 
> 
>> On Jun 13, 2022, at 10:27 AM, Les Ginsberg (ginsberg) 
>>  wrote:
>> 
>> Tony -
>> 
>> "Historic" is for 
>> 
>> " A specification that has been superseded by a more recent
>>  specification or is for any other reason considered to be obsolete..."
>> 
>> Hard to see how that applies here.
>> 
>> Although I appreciate Tom's concern, the fact that we may not be clear on 
>> how to transition from Experimental to Standard (for example) seems to me to 
>> be a problem to be solved outside of the context of this specific draft - 
>> not something that should prevent us from using Experimental.
>> 
>> In regards to the state of the draft, here is my summary:
>> 
>> 1)There are multiple implementations of the draft
>> 2)I am not aware that interoperability of the implementations has been 
>> demonstrated 
>> 3)To the extent that interoperability could be demonstrated, I think only 
>> centralized mode could be validated at this time
>> 4)Interoperability of distributed mode requires standardization of one or 
>> more algorithms - which means the drafts defining those algorithms first 
>> have to progress
>> 
>> To me, that makes "Experimental" the right track as further work is required 
>> before we can say that all aspects of the draft are mature enough to 
>> consider Standards track.
>> 
>>  Les
>> 
>> 
>>> -Original Message-
>>> From: Lsr  On Behalf Of Tony Li
>>> Sent: Monday, June 13, 2022 10:12 AM
>>> To: tom petch 
>>> Cc: Acee Lindem (acee) ; lsr@ietf.org
>>> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - 
>>> draft-ietf-lsr-dynamic-
>>> flooding
>>> 
>>> 
>>> Tom,
>>> 
>>> In this particular case, I believe the choices are Experimental or 
>>> Historic.  I’m
>>> fine with either.
>>> 
>>> T
>>> 
>>> 
> On Jun 13, 2022, at 8:43 AM, tom petch  wrote:
> 
> From: Lsr  on behalf of Acee Lindem (acee)
>>> 
 Sent: 10 June 2022 15:10
 
 Initially, there was a lot interest and energy in reducing the flooding
>>> overhead in dense drafts. Now, it seems the interest and energy has waned.
>>> IMO, this draft contains some very valuable extensions to the IGPs. I
>>> discussed this with the editors and one suggestion was to go ahead and
>>> publish the draft as “Experimental”. However, before doing this I’d like to 
>>> get
>>> the WG’s opinion on making it experimental rather standards track.
>>> Additionally, I know there were some prototype implementations. Have any
>>> of those been productized?
 
 
 The trouble with experimental is what happens next?  Does it stay
>>> experimental for ever or is there some assessment at some point when it
>>> becomes Standards Track?  What are the criteria?  I am not aware of an RFC
>>> describing such a process and the IPPM WG seemed uncertain what to do
>>> with RFC8321 and RFC8889 when such an issue arose.
 
 The shepherd report for 8321 said
 'the measurement utility of this extension still is to be demonstrated at a
>>> variety of scales
 in a plurality of network conditions'
 as the justification for experimental but did not state how that might 
 later
>>> be demonstrated.
 
 Tom Petch
 
 Thanks,
 Acee
 
 
 ___
 Lsr mailing list
 Lsr@ietf.org
 https://www.ietf.org/mailman/listinfo/lsr
>>> 
>>> _

Re: [Lsr] WG adoption call for draft-fox-lsr-ospf-terminology-01

[Jeff Tantsura]

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.
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to these drafts.
> 
> Thanks,
> Chris.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

[Jeff Tantsura]

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 certainly welcome.
> Thanks,
> Acee
>  
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Jeff Tantsura]

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 if it deals with both abstract node & reflection in one as 
> available  solutions. More than happy to attack that once the specs have 
> moved to publication. 
> 
> -- tony 
> 
>> On Mon, Jan 3, 2022 at 1:05 PM Christian Hopps  wrote:
>> 
>> 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 standardizing here 2 solutions for the same
>> > thing, we are standardizing two solutions that meet very different
>> > deployment and operational requirements albeit from 20K feet view all
>> > that stuff looks the same of course as any other thing does ... 
>> 
>> Have we captured these "different deployment and operational requirements" 
>> anywhere? I think might be very useful...
>> 
>> Thanks,
>> Chris.
>> [as wg member]
>> 
>> 
>> > -- tony
>> >
>> > On Tue, Dec 7, 2021 at 7:17 PM Les Ginsberg (ginsberg) > > 40cisco@dmarc.ietf.org> wrote:
>> >
>> >
>> > When I look at this request, I see it in a larger context.
>> >
>> >  
>> >
>> > There are two drafts which attempt to address the same problem in
>> > very different ways:
>> >
>> >  
>> >
>> > https://datatracker.ietf.org/doc/
>> > draft-ietf-lsr-isis-flood-reflection/
>> >
>> >  
>> >
>> > and
>> >
>> >  
>> >
>> > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
>> >
>> >  
>> >
>> > Both of them discuss in their respective introductions the
>> > motivation – which is to address scaling issues in deployment
>> > scenarios where the existing IS-IS hierarchy is being asked to
>> > “stand on its head” i.e., interconnection between different L1
>> > areas is not to be achieved by utilizing an L2 backbone – rather
>> > it is the L1 areas themselves which are required to be used for
>> > interconnection of sites (e.g., two datacenters) and the scaling
>> > properties of the existing protocol hierarchy when used in this
>> > way are not attractive.
>> >
>> >  
>> >
>> > I find no technical basis on which to choose between the two
>> > proposed solutions – so in my mind a last call for
>> > “Flood-Reflection” presupposes a last call for “Area Proxy” – and
>> > therein lies my angst.
>> >
>> > The end result will be that multiple incompatible solutions to
>> > the same problem will be defined. It will then be left to
>> > customers to try to determine which of the solutions seems best
>> > to them – which in turn will put the onus on vendors to support
>> > both solutions (depending on the set of customers each vendor
>> > supports).
>> >
>> > This – to me – represents an utter failure of the standards
>> > process. We are reduced to a set of constituencies which never
>> > find common ground – the end result being sub-optimal for the
>> > industry as a whole.
>> >
>> >  
>> >
>> > It seems to me that the proper role of the WG is to address the
>> > big questions first:
>> >
>> >  
>> >
>> > 1)Is this a problem which needs to be solved by link-state
>> > protocols?
>> >
>> > We certainly have folks who are clever enough to define solutions
>> > – the two drafts are a proof of that.
>> >
>> > But whether this is a wise use of the IGPs I think has never been
>> > fully discussed/answered.
>> >
>> > Relevant to this point is past experience with virtual links in
>> > OSPF – use of which was problematic and which has largely fallen
>> > out of use.
>> >
>> > Also, many datacenters use BGP (w or w/o IGP) and therefore have
>> > other ways to address such issues.
>> >
>> > Although I am familiar with the “one protocol is simpler”
>> > argument, whether that justifies altering the IGPs in any of the
>> > proposed ways is still an important question to discuss.
>> >
>> >  
>> >
>> > 2)If link state protocols do need to solve this problem, what is
>> > the preferred way to do that?
>> >
>> > This requires meaningful dialogue and a willingness to engage on
>> > complex technical issues.
>> >
>> >  
>> >
>> > The alternative is to do what we seem to be doing – allowing
>> > multiple solutions to move forward largely without comment. In
>> > which case I see no basis on which to object – anyone who can
>> > demonstrate a deployment case should then be allowed to move a
>> > draft forward – and there are then no standardized solutions.
>> >
>> >   

Re: [Lsr] WG Adoption Call for "IS-IS Fast Flooding" - draft-decraeneginsberg-lsr-isis-fast-flooding-00

[Jeff Tantsura]

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-decraeneginsberg-lsr-isis-fast-flooding-00 as an LSR WG document at 
>> the IETF 112 LSR WG meeting.
>> We are now confirming WG consensus on this action. Please indicate your 
>> support or objection on this list by 12:00 AM UTC on December 7th, 2021.
>>  
>> Another question that came to light is whether the document should be 
>> standards track or experimental. If you have an opinion on this matter, 
>> please chime in along with your arguments for one track or the other. We 
>> probably won’t make a final decision on this now but let’s get the 
>> discussion started.
>>  
>> Here is a link for your convenience:
>>  
>> https://datatracker.ietf.org/doc/draft-decraeneginsberg-lsr-isis-fast-flooding/
>>  
>> Thanks,
>> Acee 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Jeff Tantsura]

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 draft. I’m allowing as extra week 
> as I like to get some additional reviews – although my comments have been 
> addressed. 
>  
> Thanks,
> Acee
>  
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

[Jeff Tantsura]

Peter,

Not “ALL” but these that share a service (import each other routes).

I agree that this is a brute force solution that isn’t necessarily to win a 
beauty contest. However this is deployable and implementable.

Back to LSR scoop ;-) in general i agree with Les’ points

Cheers,
Jeff

> 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 PEs (next-hops) that originate the prefix that is locally imported 
>> (needs to be tracked). For further optimization, only multihomed prefixes 
>> are of interest (if a PE that has a CE that is single-homed to goes away, 
>> there’s no convergence).
>> A possible solution (discussed a number of times here) is to extract 
>> next-hop from an UPDATE, compare to the list of next-hops already learnt and 
>> establish multi-hop BFD session according to the business logic.
>> Modern mid-high end platforms can easily run a 1000 MH BFD session @1sec
> 
> sure, but do you really want to maintain a full mesh of MH BFD sessions 
> between all PEs? I guess no.
> 
> thanks,
> Peter
> 
>> Cheers,
>> Jeff
>>>> On Oct 13, 2021, at 10:16, Robert Raszuk  wrote:
>>> 
>>> 
>>> > How many other PEs does a BGP edge PE maximally peer with?
>>> 
>>> Typically on IBGP side you will see 2-4 peers. Those are RRs.
>>> 
>>> Due to no autodiscovery of BGP sessions no many people do iBGP full mesh 
>>> between PEs.
>>> 
>>> Best,
>>> R.
>>> 
>>>> On Wed, Oct 13, 2021 at 6:48 PM Acee Lindem (acee) 
>>>> mailto:40cisco@dmarc.ietf.org>> 
>>>> wrote:
>>> 
>>>Hi Peter,
>>> 
>>>See inline.
>>> 
>>>On 10/13/21, 4:42 AM, "Peter Psenak"
>>>>><mailto:40cisco@dmarc.ietf.org>> wrote:
>>> 
>>>Hi Acee,
>>> 
>>>>On 12/10/2021 21:05, Acee Lindem (acee) wrote:
>>>> Speaking as WG Chairs:
>>>>
>>>> The authors of “Prefix Unreachable Announcement” have
>>>requested an
>>>> adoption. The crux of the draft is to signal unreachability
>>>of a prefix
>>>> across OSPF or IS-IS areas when area summarization is
>>>employed and
>>>> prefix is summarised. We also have “IS-IS and OSPF Extension
>>>for Event
>>>> Notification” which can be used to address the same use
>>>case. The drafts
>>>> take radically different approaches to the problem and the
>>>authors of
>>>> both drafts do not wish to converge on the other draft’s
>>>method so it is
>>>> understandable that merging the drafts really isn’t an option.
>>> 
>>>just for the record, I offered authors of "Prefix Unreachable
>>>Announcement" co-authorship on "Event notification" draft,
>>>arguing the
>>>the event base solution addresses their use case in a more
>>>elegant and
>>>scalable way. They decided to push their idea regardless.
>>> 
>>>One solution to this problem would have definitely been better.
>>> 
>>>> Before an adoption call for either draft, I’d like to ask
>>>the WG:
>>>>
>>>>  1. Is this a problem that needs to be solved in the IGPs?
>>>The use case
>>>> offered in both drafts is signaling unreachability of a
>>>BGP peer.
>>>> Could this better solved with a different mechanism (e.g., 
>>> BFD)
>>>> rather than flooding this negative reachability
>>>information across
>>>> the entire IGP domain?
>>> 
>>>we have looked at the various options. None of the existing
>>>ones would
>>>fit the large scale deployment with summarization in place.
>>>Using BFD
>>>end to end to track reachability between PEs simply does not
>>>scale.
>>> 
>>>It seems to me that scaling of BFD should be "roughly"
>>>proportional to BGP session scaling but I seem to be in the
>>>minority. My opinion is based on SDW

Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

[Jeff Tantsura]

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 prefixes are of interest 
(if a PE that has a CE that is single-homed to goes away, there’s no 
convergence).
A possible solution (discussed a number of times here) is to extract next-hop 
from an UPDATE, compare to the list of next-hops already learnt and establish 
multi-hop BFD session according to the business logic.
Modern mid-high end platforms can easily run a 1000 MH BFD session @1sec

Cheers,
Jeff

> On Oct 13, 2021, at 10:16, Robert Raszuk  wrote:
> 
> 
> 
> > How many other PEs does a BGP edge PE maximally peer with?
> 
> Typically on IBGP side you will see 2-4 peers. Those are RRs. 
> 
> Due to no autodiscovery of BGP sessions no many people do iBGP full mesh 
> between PEs. 
> 
> Best,
> R.
> 
>> On Wed, Oct 13, 2021 at 6:48 PM Acee Lindem (acee) 
>>  wrote:
>> Hi Peter, 
>> 
>> See inline. 
>> 
>> On 10/13/21, 4:42 AM, "Peter Psenak"  
>> wrote:
>> 
>> Hi Acee,
>> 
>> On 12/10/2021 21:05, Acee Lindem (acee) wrote:
>> > Speaking as WG Chairs:
>> > 
>> > The authors of “Prefix Unreachable Announcement” have requested an 
>> > adoption. The crux of the draft is to signal unreachability of a 
>> prefix 
>> > across OSPF or IS-IS areas when area summarization is employed and 
>> > prefix is summarised. We also have “IS-IS and OSPF Extension for Event 
>> > Notification” which can be used to address the same use case. The 
>> drafts 
>> > take radically different approaches to the problem and the authors of 
>> > both drafts do not wish to converge on the other draft’s method so it 
>> is 
>> > understandable that merging the drafts really isn’t an option.
>> 
>> just for the record, I offered authors of "Prefix Unreachable 
>> Announcement" co-authorship on "Event notification" draft, arguing the 
>> the event base solution addresses their use case in a more elegant and 
>> scalable way. They decided to push their idea regardless.
>> 
>> One solution to this problem would have definitely been better. 
>> 
>> > Before an adoption call for either draft, I’d like to ask the WG:
>> > 
>> >  1. Is this a problem that needs to be solved in the IGPs? The use case
>> > offered in both drafts is signaling unreachability of a BGP peer.
>> > Could this better solved with a different mechanism  (e.g., BFD)
>> > rather than flooding this negative reachability information across
>> > the entire IGP domain?
>> 
>> we have looked at the various options. None of the existing ones would 
>> fit the large scale deployment with summarization in place. Using BFD 
>> end to end to track reachability between PEs simply does not scale.
>> 
>> It seems to me that scaling of BFD should be "roughly" proportional to BGP 
>> session scaling but I seem to be in the minority. My opinion is based on 
>> SDWAN tunnel scaling, where BFD is used implicitly in our solution. How many 
>> other PEs does a BGP edge PE maximally peer with? 
>> Thanks,
>> Acee
>> 
>> 
>> Some people believe this should be solved by BGP, but it is important to 
>> realize that while the problem statement at the moment is primarily 
>> targeted for egress PE reachability loss detection for BGP, the 
>> mechanism proposed is generic enough and can be used to track the peer 
>> reachablity loss for other cases (e.g GRE endpoint, etc) that do not 
>> involve BGP.
>> 
>> We went even further and explored the option to use completely out of 
>> band mechanism that do not involve any existing protocols.
>> 
>> Simply, the advantage of using IGP is that it follows the existing MPLS 
>> model, where the endpoint reachability is provided by IGPs. Operators 
>> are familiar with IGPs and know how to operate them.
>> 
>> On top of the above, IGP event notification can find other use cases in 
>> the future, the mechanism defined in draft is generic enough.
>> 
>> 
>> >  2. Assuming we do want to take on negative advertisement in the IGP,
>> > what are the technical merits and/or detriments of the two 
>> approaches? 
>> 
>> we have listed some requirements at:
>> 
>> 
>> https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-event-notification-00#section-3
>> 
>>  From my perspective the solution should be optimal in terms of amount 
>> of data and state that needs to be maintained, ideally separated from 
>> the traditional LS data. I also believe that having a generic mechanism 
>> to distribute events has it own merits.
>> 
>> thanks,
>> Peter
>> 
>> > 
>> > We’ll reserve any further discussion to “WG member” comments on the 
>> two 
>> > approach

Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[Jeff Tantsura]

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 
>> emphasis:
>>  
>> “The LSR WG developed ASLAs to cover usage of the link attributes (including 
>> metrics) for different applications and mitigate all the vagaries of the 
>> original TE link attribute specifications. ASLAs are implemented and 
>> deployed. I believe it would be a mistake to bifurcate the IGP standards 
>> with yet another way of encoding link attributes for different applications.”
>>  
>> ASLA is an architecture – one designed to assure that we can explicitly 
>> identify the set of applications using any link attribute . It is designed 
>> to be extensible both to new applications and to new attributes. It was long 
>> debated in the WG and underwent extensive review and is now standardized in 
>> RFCs 8919, 8920. It has been implemented and deployed and forms the basis of 
>> interoperable implementations.
>>  
>> Now you (and others) decide to invent a new attribute. The attribute 
>> certainly can be advertised using ASLA, but instead of acknowledging the 
>> existence of the ASLA architecture and defining the new attribute to use 
>> ASLA, you decide that maybe if we advertise this attribute in some new way 
>> there might be some modest advantages. This ignores the consequences of 
>> having to implement attribute specific encoding rules in order to map 
>> attributes to applications. These consequences include greater code 
>> complexity and higher probability of interoperability issues.
>>  
>> And, based on your list of attributes below, what have we to look forward 
>> to? More attribute specific encoding rules leading to even greater code 
>> complexity and greater chance of interoperability problems it would seem.
>>  
>> Look, you haven’t convinced me that your alternative proposals are “better”. 
>> But even if they were, it would require a much greater benefit than you are 
>> claiming to justify discarding the architecture that is designed to fully 
>> address the association of link attributes and the applications which use 
>> them.
>>  
>> I don’t expect to convince you – and you have not convinced me – and we 
>> probably never will agree. But since it is clear that ASLA does work for all 
>> the cases that have been mentioned in this and related threads, I think this 
>> discussion is a waste of WG time.
>>  
>> It is time to close this discussion.
>>  
>>Les
>>  
>>  
>> From: Lsr  On Behalf Of Ron Bonica
>> Sent: Tuesday, August 17, 2021 11:21 AM
>> To: Acee Lindem (acee) ; lsr@ietf.org
>> Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW 
>> Constraints
>>  
>> Acee,
>>  
>> So, let us discuss whether there is a good reason for 
>> draft-ietf-lsr-flex-algo-con to specify ASLA !
>>  
>> Link attributes are different from application configuration information. 
>> Link attributes are properties of a link.  They are independent of the 
>> applications that use them. The following are examples:
>>  
>> Total physical bandwidth
>> Number of LAG elements
>> Bandwidth of smallest lag member
>> Latency
>>  
>> Link attributes do not benefit from ASLA encoding because they are not 
>> application specific.
>>  
>> Application configuration information constrains the behavior of an 
>> application. It can apply to:
>>  
>> The application and a link
>> The application only
>>  
>> Bandwidth reservation applies to an application and a link. For example, a 
>> link may advertise that it has:
>>  
>> X Gbps available for RSVP-TE reservations
>> Y Gbps available for SR Policy reservations
>> Z Gbps available for TI-LFA reservations
>>  
>> This class of configuration information clearly benefits from ASLA encoding, 
>> because it is applicable to both the application and the link.
>>  
>> Some applications (e.g., Flexalgo) can be configured to use a variety of 
>> link attributes in SPF calculation. No matter how they acquire this 
>> configuration information, it MUST be the same at each node. Otherwise, 
>> routing loops may result. Configuration options are:
>>  
>> Configure this information on each link and advertise link attributes with 
>> ASLA
>> Configure this information on each node that runs the application
>> Configure this information in a few central places and advertise it to all 
>> other nodes. The advertisement is not associated with a link. Flexalgo uses 
>> the FAD in this manner.
>>  
>> Neither Option 1 nor Option 2 is very appealing, because it requires 
>> configuration on each node. Option 3 is better because:
>>  
>> It requires configuration on only a few nodes
>> It maintains separation between link attributes and application 
>> configuration information
>> It can support applications like Flexalgo, where each algorithm may use 
>>

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Jeff Tantsura]

+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/8920.
>> For example, https://www.rfc-editor.org/rfc/rfc8919.html#section-6.1 states:
>> "New applications that future documents define to make use of the 
>> advertisements defined in this document MUST NOT make use of legacy 
>> advertisements."
>> Flex-algo is a "new application" in the scope of these RFCs.
>> Please correct this error.
>> Thanx.
>>Les
>>> -Original Message-
>>> From: Lsr  On Behalf Of internet-dra...@ietf.org
>>> Sent: Monday, July 12, 2021 9:12 AM
>>> To: i-d-annou...@ietf.org
>>> Cc: lsr@ietf.org
>>> Subject: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
>>> 
>>> 
>>> 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   : Flexible Algorithms: Bandwidth, Delay, Metrics and
>>> Constraints
>>> Authors : Shraddha Hegde
>>>   William Britto A J
>>>   Rajesh Shetty
>>>   Bruno Decraene
>>>   Peter Psenak
>>>   Tony Li
>>>Filename: draft-ietf-lsr-flex-algo-bw-con-01.txt
>>>Pages   : 27
>>>Date: 2021-07-12
>>> 
>>> Abstract:
>>>Many networks configure the link metric relative to the link
>>>capacity.  High bandwidth traffic gets routed as per the link
>>>capacity.  Flexible algorithms provides mechanisms to create
>>>constraint based paths in IGP.  This draft documents a generic metric
>>>type and set of bandwidth related constraints to be used in Flexible
>>>Algorithms.
>>> 
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/
>>> 
>>> There is also an htmlized version available at:
>>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-flex-algo-bw-con-01
>>> 
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> 
>>> ___
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Jeff Tantsura]

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 indicate your support or objection by May 27th, 2021.
>  
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.
>  
> Thanks,
> Chris and Acee
>  
>  
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

[Jeff Tantsura]

+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 address the 
> same gap with IP/IPv6 reachability advertisements.
> And I think by now implementations (certainly ones that support newer 
> functionality like SRv6) should have added support for prefix-attributes 
> sub-TLV .
>
> In the case of the Locator TLV  – since this is new functionality – we have 
> the option of mandating prefix-attributes sub-TLV – something we could not do 
> with IP/IPv6 Reachability since that has been deployed for many years.
>
> But,  please recognize two consequences of the MUST option:
>
> 1)Implementations may have to deal w  backwards compatibility w early 
> deployments of SRv6. This would only be an issue if there are implementations 
> that currently do NOT send prefix-attributes sub-TLV w Locator TLV.
> Are there any such implementations??
>
> 2)In the case where the deployment is a single level, it could be argued that 
> prefix-attributes sub-TLV isn’t needed.
> I personally would NOT make such an argument, but we should understand that 
> MUST applies to this case as well.
>
> If everyone is OK with these consequences (personally I am OK) then I think 
> it is fine to go with MUST.
>
>    Les
>
>
> From: Lsr  On Behalf Of Ketan Talaulikar (ketant)
> Sent: Friday, May 07, 2021 7:00 AM
> To: Alvaro Retana ; Peter Psenak (ppsenak) 
> ; lsr@ietf.org
> Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De 
> Velde, Gunter (Nokia - BE/Antwerp) 
> Subject: Re: [Lsr] Last Call:  
> (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
> Standard
>
> Hi Peter,
>
> I agree that the support for the Prefix Attribute Flags TLV is required in 
> the Locator TLV.
>
> Thanks,
> Ketan
>
> From: Lsr  On Behalf Of Alvaro Retana
> Sent: 07 May 2021 19:23
> To: Peter Psenak (ppsenak) ; lsr@ietf.org
> Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De 
> Velde, Gunter (Nokia - BE/Antwerp) 
> Subject: Re: [Lsr] Last Call:  
> (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
> Standard
>
> On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote:
>
> > Technically I agree with you and if everybody agrees, I'm fine to
> > enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.
>
> So...what does everyone else think?
>
> We need to close on this point before the IESG evaluates the document.  I'm 
> requesting it to be put on the May/20 telechat, which means that we should 
> have a resolution and updated draft by the end of next week.
>
>
> Thanks!
>
> Alvaro.
>
>
> On May 3, 2021 at 5:17:58 AM, Peter Psenak (ppse...@cisco.com) wrote:
> > Hi Gunter,
> >
> > Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV.
> > The problem you describe is not specific to Locator TLV, same applies to
> > regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix
> > Attribute Flags TLV is not included, one can not tell whether the prefix
> > has been propagated (L1->L2) or generated as a result of the local
> > interface attached on the originator. Same applies to redistribution and
> > R-flag for IPv4 prefix TLVs.
> >
> > SRv6 Locator TLV has been defined a while back and the Prefix Attribute
> > Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we
> > can start to mandate the Prefix Attribute Flags TLV at this point.
> >
> > Technically I agree with you and if everybody agrees, I'm fine to
> > enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.
> >
> > thanks,
> > Peter
> >
> >
> > On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> > > Hi Peter, All,
> > >
> > > Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the 
> > > prefix-attribute tlv is mandatory when a locator is redistributed?
> > >
> > > Why?
> > > *When calculating a LFA for an SRv6 End.SID we better know if the locator 
> > > has been redistributed or not for a correct operation.
> > >
> > > Reasoning:
> > > * A locator has the D bit. This one is set when we redistribute from L2 
> > > to L1.
> > > ** So this end-sid will not be used as we know that it is redistributed.
> > >
> > > * In the other direction (L1-L2), we only know that a locator is 
> > > redistributed from L1 to L2 if the prefix-attribute sub-tlv is advertised.
> > > ** This means if the operator does not configure advertisement of the 
> > > prefix-attribute tlv, ISIS could potentially use an end-sid which does 
> > > not terminate on the expected node.
> > >
> > > * Compared to sr-mpls, a prefix-sid has the R flag indicating it is 
> > > redistributed.
> > > * We don't have that for locator end-sids.
> > >
> > > Relevant snip from " draft-ietf-lsr-isis-srv6-extensi

Re: [Lsr] WG adoption call for draft-acee-lsr-ospf-transport-instance-02

[Jeff Tantsura]

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.
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.
> 
> Historical Note: The original OSPF transport instance document was adopted by 
> the OSPF WG back in 2009, it was last updated in 2014, and then revived as an 
> individual submission to LSR in Sep 2020. :)
> 
> Thanks,
> Chris.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Jeff Tantsura]

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 - flex-also requires contiguous topology to work, self isolation as the 
result of (dynamic) topology re-computation would not be a great thing.

Cheers,
Jeff
On Mar 1, 2021, 12:48 PM -0800, Tony Li , wrote:
>
> Robert,
>
> > Constructing arbitrary topologies with bw constrain is useful work. For 
> > example I want to create a topology without links of the capacity less then 
> > 1 Gbps. All cool. Of course if I have a case where two nodes have 10 L3 
> > 1Gbps links nicely doing ECMP I will not include those which may be a 
> > problem.
>
>
> I agree that it may be a problem. Maybe it’s not the right tool for the job 
> at hand. That doesn’t make it a bad tool, just the wrong one. I try not to 
> turn screws with a hammer. And I try not to drive nails with a screwdriver.
>
> I will happily stipulate that we need more tools and that these are not 
> enough. We should not reject a tool simply because it doesn’t solve all 
> problems. Let’s work towards the right set of tools. Linear algebra tells us 
> that we want an orthogonal set of basis vectors. What are they? Adding them 
> one at a time is not horrible progress.
>
>
> > However my observation is precisely related to your last sentence.
> >
> > Is this extension to be used with static or dynamic data ? If static all 
> > fine. But as William replied to me earlier link delay may be dynamically 
> > computed and may include queue wait time. That to me means something much 
> > different if Flex-Algo topologies will become dynamically adjustable. And I 
> > am not saying this is not great idea .. My interest here is just to 
> > understand the current scope.
>
>
> Link delay was dynamic before this draft. As William mentioned, TWAMP can 
> already be used to provide a dynamic measurement of link delay. That, coupled 
> with the link delay metric already gave us dynamic path computation 
> requirements and the possibilities of oscillation and instability. We have 
> chosen to charge ahead, without addressing those concerns already.
>
> Regards,
> Tony
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Jeff Tantsura]

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, 
> 2021.
>
> Authors, please indicate wether you are aware of any IPR related to this 
> document to the list.
>
> Thanks,
> Chris, Acee, (Lou and Pavan).
>
> ___
> Teas mailing list
> t...@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-acee-lsr-isis-yang-augmentation-v1-03

[Jeff Tantsura]

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.
>
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.
>
> Thanks,
> Chris.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-acee-lsr-ospf-admin-tags-07

[Jeff Tantsura]

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, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.
>
> Thanks,
> Chris.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Jeff Tantsura]

Zhenqiang,

please see inline

Cheers,
Jeff


4. I want to know the path for a specific IP Flex-Algorithm is calculated 
distributedly by each nodes paticipating this Flex-Algorithm or calculated 
centralized by an controller? I wonder we can guarantee the loop free  path 
with IP Flex-Algorithm 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 Li; Robert Raszuk
CC: lsr; Acee Lindem \(acee\)
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
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 it really 
depends what is one's definition of TE.

If indeed IGP TE is anything more then SPF - then sure we can call it a TE 
feature.

However, while a very useful and really cool proposal, my point is to make sure 
this is not oversold - that's all.

Best,
R.


> On Fri, Dec 4, 2020 at 1:13 AM Tony Li  wrote:
> >
> > Hi Robert,
> >
> >
> > > However I really do not think that what Flexible Algorithm offers can be 
> > > compared or even called as Traffic Engineering (MPLS or SR).
> > >
> > > Sure Flex Algo can accomplish in a very elegant way with little cost 
> > > multi topology routing but this is not full TE. It can also direct 
> > > traffic based on static or dynamic network preferences (link colors, rtt 
> > > drops etc ... ),  but again it is not taking into account load of the 
> > > entire network and IMHO has no way of accomplish TE level traffic 
> > > distribution.
> > >
> > > Just to make sure the message here is proper.
> >
> >
> > It’s absolutely true that FlexAlgo (IP or SR) has limitations. There’s no 
> > bandwidth reservation. There’s no dynamic load balancing. No, it’s not a 
> > drop in replacement for RSVP. No, it does not supplant SR-TE and a good 
> > controller. Etc., etc., etc….
> >
> > However I don’t feel that it’s fair to say that FlexAlgo can’t be called 
> > Traffic Engineering.  After all TE is a very broad topic. Everything that 
> > we’ve done that’s more sophisticated than simple SPF falls in the area of 
> > Traffic Engineering.  Link coloring and SRLG alone clearly fall into that 
> > bucket.
> >
> > I’ll grant you that it may not have the right TE features for your 
> > application, but that doesn’t mean that it’s not sufficient for some.  
> > Please don’t mislead people by saying that it’s not Traffic Engineering.
> >
> > Regards,
> > Tony
> >
> >
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Jeff Tantsura]

I’m very much in favor of being able to provide a number of technologies that 
help operators with different requirements and constraints to provide their 
services in a most optimized way, hence my support for flex-algo, either 
labeled or not as a technology on the dynamic spectrum of the solution space.
One can achieve similar results on a single topology with a centralized 
controller, there are trade-offs in either, extremities on either side are 
counterproductive . 

Regards,
Jeff

> On Dec 3, 2020, at 17:47, Gyan Mishra  wrote:
> 
> 
> 
> 
> In fact the concept of traffic engineering has been around for a long time 
> using simple IGP metric manipulation to steer traffic using the IGP.  
> 
> I had designed in my past life a costing algorithm where you use highest 
> bandwidth links and lowest latency as the crow flies point A to point B such 
> that you take the highest bandwidth lowest latency path based on a formula 
> for path instantiation.  This is the essence of flex algo basically an 
> engineered algorithm algo xyz for a sub routing instance instantiation.  
> 
> This concept works well for global table or single routing instance, however 
> if you have multiple VPNs and you want to realize per VPN coloring 
> capabilities it is much different then use of flex algo with a single IGP 
> global table routing following a single algo or multiple sub set algo’s.
> 
> That’s where RSVP TE PCALC path computation and bandwidth and link attributes 
> came into play in an MPLS context.
> 
> However, now trying to expand traditional RSVP TE to provide per VRF VPN 
> mapping and coloring is now a daunting painful and non scalable solution.  
> Now requires with RSVP static routes and VRF next hop rewrite to map each VPN 
> to a different color steered statically to a different loopback egress PE 
> iBGP next hop then the default iBGP global table next hop.  
> 
> That’s where the advent of SR with SR-TE now fills that much needed gap of 
> per VRF coloring to build the same as we had in the RSVP world loose path 
> prefix sid or strict path adjacency sid path instantiation now done via 
> centralized controller.
> 
> The gap where flex algo comes into play is unique but I think is a tool on 
> the operator toolbox which prior to IP flex algo provided additional steering 
> granularity and path instantiation control used in conjunction with SR-TE.
> 
> The gap IP flex algo fills is internet providers global table routing being 
> able to create logical traffic steering constructs where MPLS or SR does not 
> exist.  
> 
> 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 algo fills yet another 
> somewhat mutually exclusive niche.
> 
> Kind Regards 
> 
> Gyan
> 
>> On Thu, Dec 3, 2020 at 8:18 PM Jeff Tantsura  wrote:
>> 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 it 
>>> really depends what is one's definition of TE. 
>>> 
>>> If indeed IGP TE is anything more then SPF - then sure we can call it a TE 
>>> feature. 
>>> 
>>> However, while a very useful and really cool proposal, my point is to make 
>>> sure this is not oversold - that's all. 
>>> 
>>> Best,
>>> R.
>>> 
>>> 
>>>> On Fri, Dec 4, 2020 at 1:13 AM Tony Li  wrote:
>>>> 
>>>> Hi Robert,
>>>> 
>>>> 
>>>> > However I really do not think that what Flexible Algorithm offers can be 
>>>> > compared or even called as Traffic Engineering (MPLS or SR).
>>>> >
>>>> > Sure Flex Algo can accomplish in a very elegant way with little cost 
>>>> > multi topology routing but this is not full TE. It can also direct 
>>>> > traffic based on static or dynamic network preferences (link colors, rtt 
>>>> > drops etc ... ),  but again it is not taking into account load of the 
>>>> > entire network and IMHO has no way of accomplish TE level traffic 
>>>> > distribution.
>>>> >
>>>> > Just to make sure the message here is proper.
>>>> 
>>>> 
>>>> I

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Jeff Tantsura]

Hi Aijun,

How’s my response triggered yours?
Where do you see my talking about static vs dynamic TE?
It you are looking for a philosophical angle - perhaps we could talk about 
centralized vs distributed TE and complexity of each one.

Regards,
Jeff

> On Dec 3, 2020, at 19:13, Aijun Wang  wrote:
> 
> 
> Hi, Jeff:
>  
> Static TE can’t meet the requirement of real world.
> If the LFA mechanism can only be achieved within each IP-FLEX algorithm, is 
> it just another static resource allocation and prefix assignment method?
>  
>  
> Best Regards
>  
> 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 
> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>  
> 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 it really 
> depends what is one's definition of TE. 
>  
> If indeed IGP TE is anything more then SPF - then sure we can call it a TE 
> feature. 
>  
> However, while a very useful and really cool proposal, my point is to make 
> sure this is not oversold - that's all. 
>  
> Best,
> R.
>  
>  
> On Fri, Dec 4, 2020 at 1:13 AM Tony Li  wrote:
> 
> Hi Robert,
> 
> 
> > However I really do not think that what Flexible Algorithm offers can be 
> > compared or even called as Traffic Engineering (MPLS or SR).
> >
> > Sure Flex Algo can accomplish in a very elegant way with little cost multi 
> > topology routing but this is not full TE. It can also direct traffic based 
> > on static or dynamic network preferences (link colors, rtt drops etc ... ), 
> >  but again it is not taking into account load of the entire network and 
> > IMHO has no way of accomplish TE level traffic distribution.
> >
> > Just to make sure the message here is proper.
> 
> 
> It’s absolutely true that FlexAlgo (IP or SR) has limitations. There’s no 
> bandwidth reservation. There’s no dynamic load balancing. No, it’s not a drop 
> in replacement for RSVP. No, it does not supplant SR-TE and a good 
> controller. Etc., etc., etc….
> 
> However I don’t feel that it’s fair to say that FlexAlgo can’t be called 
> Traffic Engineering.  After all TE is a very broad topic. Everything that 
> we’ve done that’s more sophisticated than simple SPF falls in the area of 
> Traffic Engineering.  Link coloring and SRLG alone clearly fall into that 
> bucket.
> 
> I’ll grant you that it may not have the right TE features for your 
> application, but that doesn’t mean that it’s not sufficient for some.  Please 
> don’t mislead people by saying that it’s not Traffic Engineering.
> 
> Regards,
> Tony
> 
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Jeff Tantsura]

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 it really 
> depends what is one's definition of TE.
>
> If indeed IGP TE is anything more then SPF - then sure we can call it a TE 
> feature.
>
> However, while a very useful and really cool proposal, my point is to make 
> sure this is not oversold - that's all.
>
> Best,
> R.
>
>
> > On Fri, Dec 4, 2020 at 1:13 AM Tony Li  wrote:
> > >
> > > Hi Robert,
> > >
> > >
> > > > However I really do not think that what Flexible Algorithm offers can 
> > > > be compared or even called as Traffic Engineering (MPLS or SR).
> > > >
> > > > Sure Flex Algo can accomplish in a very elegant way with little cost 
> > > > multi topology routing but this is not full TE. It can also direct 
> > > > traffic based on static or dynamic network preferences (link colors, 
> > > > rtt drops etc ... ),  but again it is not taking into account load of 
> > > > the entire network and IMHO has no way of accomplish TE level traffic 
> > > > distribution.
> > > >
> > > > Just to make sure the message here is proper.
> > >
> > >
> > > It’s absolutely true that FlexAlgo (IP or SR) has limitations. There’s no 
> > > bandwidth reservation. There’s no dynamic load balancing. No, it’s not a 
> > > drop in replacement for RSVP. No, it does not supplant SR-TE and a good 
> > > controller. Etc., etc., etc….
> > >
> > > However I don’t feel that it’s fair to say that FlexAlgo can’t be called 
> > > Traffic Engineering.  After all TE is a very broad topic. Everything that 
> > > we’ve done that’s more sophisticated than simple SPF falls in the area of 
> > > Traffic Engineering.  Link coloring and SRLG alone clearly fall into that 
> > > bucket.
> > >
> > > I’ll grant you that it may not have the right TE features for your 
> > > application, but that doesn’t mean that it’s not sufficient for some.  
> > > Please don’t mislead people by saying that it’s not Traffic Engineering.
> > >
> > > Regards,
> > > Tony
> > >
> > >
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01

[Jeff Tantsura]

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 objection on this list 
> prior to 12:00 AM UTC on December 15th, 2020. Also, review comments are 
> certainly welcome.
> Thanks,
> Acee
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Jeff Tantsura]

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 adoption call. Please indicate your 
> support or objection to WG adoption on this list prior to 12:00 AM UTC on 
> December 16th, 2020. Also, review comments are certainly welcome.
> Thanks,
> Acee
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Jeff Tantsura]

We have been discussing for quite some time and in different wg's (there’s IX 
with RS use case) BFD verification based on next-hop extraction, Robert - you 
should know. (also built a well working prototype in previous life).

Very simple logic:

Upon route import (BGP update received and imported), extract next-hop, walk 
BFD session table, if no match (no existing session) - establish (S)BFD session 
(Discriminators distribution is a solved problem) to the next-hop, associate 
fate of all routes received from it, keep timers reasonable to prevent false 
positives.

State is limited to PE’s importing each others routes (sharing a service) only
High degree of automation
No IGP pollution

Cheers,
Jeff
On Nov 17, 2020, 6:43 AM -0800, Acee Lindem (acee) , wrote:
> Speaking as WG member:
>
> I think it would be good to hone in on the BGP PE failure convergence use 
> case 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 Raszuk 
> Cc: lsr , Jeff Tantsura , Aijun Wang 
> , "Acee Lindem (acee)" 
> 
> Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases
>
>
>
> On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk  wrote:
> > quote_type
> >
> >
> > > quote_type
> > >    Robert, I believe the original intention was related to having the 
> > > data plane converge quickly when summarization is used and flip so 
> > > traffic converges from the Active ABR to the Backup ABR.
> >
> > I do not buy this use case. Flooding within the area is fast such that both 
> > ABRs will get the same info. As mentioned before there is no practical use 
> > of PUA for making any routing or fwd decision on which ABR to use. If your 
> > ABRs are not connected with min redundancy this draft is a worst patch ever 
> > to work around such a design.
>
>    Gyan> Agreed.  The point of PUA in ABR use case is the ability to track 
> the component prefixes and in case where component is down and traffic is 
> still forwarded to the ABR and dropped.  The other more important use case is 
> when links are down within the area and the area is partitioned and so one 
> ABR has all component prefixes however other ABR is missing half the 
> component prefixes.  So since the ABR will by default advertise the summary 
> as long as their is one component UP the summary is still advertised.  So 
> this use case is severely impacting as now you have an ECMP path to the other 
> area for the summary via the two ABRs and you drop half your traffic.  So now 
> with PUA the problem is fixed and the PUA is sent and now traffic is only 
> sent to the ABR that has the component prefixes.
> > quote_type
> >
> > Please present us a picture indicating before and after ABRs behaviour.
>
>      Gyan> will do
> > quote_type
> >
> > > quote_type
> > >    However PUA can be used in the absence of area segmentation within a 
> > > single area when a link or node fails to converge the data plane quickly 
> > > by sending PUA for the backup path so the active path.
> >
> > If there is no area segmentation then there is no summaries. So what are we 
> > missing in the first place ?
>
>     Gyan> Sorry I am stating that PUA feature can also be used intra area 
> where if a link or node goes down to improve data plane convergence.
> > quote_type
> >
> >
> > > quote_type
> > > With the IGP tuned with BFD fast detection on ISIS or OSPF links and LFA 
> > > & RLFA for MPLS or TI-LFA for SR local protection - with those tweaks the 
> > > convergence is well into sub second.  So for Intra area convergence with 
> > > all the optimizations mentioned I am not sure how much faster the data 
> > > plane will converge with PUA.
> >
> > Even without any of the above listed chain of acronymous things will 
> > generally work well intra-area without PUAs.
>
>     Gyan> Agreed which is why I mentioned the BGP next hop self use case if I 
> could figure out how PUA could help there that would be a major benefit of 
> PUA.
> > quote_type
> >
> > Thx,
> > R.
> >
> >
> --
> <>
> Gyan Mishra
> Network Solutions Architect
> M 301 502-1347
> 13101 Columbia Pike
> Silver Spring, MD
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Jeff Tantsura]

Sue,

Ketan’s draft would be a great starting point.

Regards,
Jeff

> On Nov 16, 2020, at 00:04, Ketan Talaulikar (ketant)  wrote:
> 
> 
> Hi Sue,
>  
> I was referring to 
> https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/
>  
> Seeing the interest in the WG to progress BGP-LS advertisements in BGP-only 
> networks, I would request for the WG to consider adoption of the above draft. 
> I believe the problem statement of the draft is clear and acknowledge that it 
> needs updates. So I will leave it to the chairs’ judgement if 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.org; Acee Lindem (acee) 
> ; lsr@ietf.org
> Subject: RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 
> to 11/16/2020)
>  
> Jeff:
>  
> I agree your BGP-LS only deployment in the MSD document were not well 
> defined.
>  
> Starting a new set of work to define BGP-LS use in BGP-only is important.  If 
> this document start the process to refine how BGP-only works, this will help 
> defined this usage.   I stand by the agreement that the BGP-LS that exposes 
> the OSPF/ISIS Link MTU proposal can be adopted in LSR.  However, this 
> discussion has confirmed that the BGP-LS support for BGP-only needs some BGP 
> focus.
>  
> If there are other drafts on this topic, it would be good to suggest this 
> drafts on the list.   Ketan suggested he had one.
>  
> Cheers, Sue
>  
>  
> From: Jeff Tantsura [mailto:jefftant.i...@gmail.com] 
> Sent: Friday, November 13, 2020 8:52 PM
> To: Les Ginsberg (ginsberg)
> Cc: Ketan Talaulikar (ketant); Susan Hares; Stephane Litkowski (slitkows); 
> i...@ietf.org; Acee Lindem (acee); lsr@ietf.org
> Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 
> to 11/16/2020)
>  
> To add to Les’s point of BGP only scenario, during MSD IESG reviews, BGP-LS 
> only deployment was found not well characterized and had been removed from 
> the draft. It will require much better discussion to have it included.
> 
> Regards,
> Jeff
>  
> 
> On Nov 13, 2020, at 15:57, Les Ginsberg (ginsberg)  wrote:
> 
> 
> The points which Ketan has made regarding the use of MTU advertisements 
> defined in RFC 7176 are very valid. Indeed, the contents of the sub-TLV 
> defined in https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend 
> upon the TRILL specific MTU-probe/MTU-ack procedures defined in 
> https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures are 
> not currently applicable to non-TRILL environments.
>  
> So, there are no existing IGP advertisements defined which can support the 
> goals of this draft.
>  
> As Ketan has also indicated, there is no discussion in the draft of how a BGP 
> only network (for example) could provide the information of interest.
>  
> From my perspective, WG adoption of this draft in ANY WG is premature.
> This might be a useful functionality to have – but at the moment we simply 
> have an idea with no definition of how to implement/deploy it.
>  
> So I therefore oppose WG adoption of this draft by IDR.
>  
> Continuing the discussion is certainly useful – and I would encourage the 
> current authors to investigate and propose relevant mechanisms 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 Hares ; 'Jeff Tantsura' ; 
> 'Stephane Litkowski (slitkows)' ; 
> i...@ietf.org; 'Acee Lindem (acee)' 
> Cc: lsr@ietf.org
> Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 
> to 11/16/2020)
>  
> Hi Authors,
>  
> I believe this work is useful and should be taken up. It has value in 
> providing the link MTU as part of the topology information via BGP-LS. 
> However, as pointed out by others on this thread, the draft should remain 
> scoped to just that – i.e. providing link MTU information. The discussion 
> related to Path MTU and applicability to SR networks are best left outside 
> the scope of this standards track draft.
>  
> Hi Sue,
>  
> I would support the points made by Acee for not taking up this draft in IDR 
> WG and instead doing this in LSR.
>  
> Besides the missing coverage for OSPFv2/v3, there are also issues with how 
> this would work with ISIS. The 

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Jeff Tantsura]

+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 bringing RIFT's negative routies example as something inherently 
>> negative. I was just pointing it out to illustrate that today's data plane 
>> lookup does not really support "if does not match" checks.
>> 
>> [WAJ] In data plane, the device do still the “match” check, not “does not 
>> match” check.  When the router receives the PUA information, it will install 
>> one black hole route for a short time.
>> 
> 
> So your idea is that you install route for unreachable prefix to /dev/null ? 
> 
> And how would that help connectivity restoration ? 
> 
> Moreover it seems that it will just also prevent any local protection to 
> locally bypass the failed destination. 
> 
> Bottom line is that I agree with one problem statement. However IMHO 
> described actions upon reception of PUA are questionable at best. 
> 
> Cheers,
> R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Jeff Tantsura]

Thanks for clarification Robert, makes sense.

Cheers,
Jeff
On Nov 15, 2020, 12:03 PM -0800, Robert Raszuk , wrote:
> Jeff,
>
> I was not bringing RIFT's negative routies example as something inherently 
> negative. I was just pointing it out to illustrate that today's data plane 
> lookup does not really support "if does not match" checks.
>
> So if you intend to use unreachable prefixes in data plane as result you need 
> to break summary into as atomic prefixes as your unreachable advertisement 
> mask.
>
> Hence my recommendation to use 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 
> > > 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,
> > > > >
> > > > > I would in fact only propose that the presented mechanism is narrowed 
> > > > > down to invalidate BGP (service) routes - in fact their next hops.
> > > > >
> > > > > The reason being that the moment you make the solution generic, 
> > > > > moreover the moment you want it to be used in RIB and data plane I am 
> > > > > afraid you are running into similar (even if local) deaggregation 
> > > > > mechanism like recently described in RIFT. That would kill all the 
> > > > > scalability of advertising summary routes in the first place and I 
> > > > > bet would face lots of opposition.
> > > > >
> > > > > Thx,
> > > > > R.
> > > > >
> > > > > > > > I would actually trim most use cases leaving just one - to 
> > > > > > > > signal remote service node (ex: PE) going down in the presence 
> > > > > > > > of summary route being advertised from remote area or pop.
> > > > >  [WAJ] Yes, this may be the most useful use case, but the PUA 
> > > > > mechanism can also apply to other scenarios. We want to make it one 
> > > > > general solution.
> > > > ___
> > > > Lsr mailing list
> > > > Lsr@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Jeff Tantsura]

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,
> 
> I would in fact only propose that the presented mechanism is narrowed down to 
> invalidate BGP (service) routes - in fact their next hops. 
> 
> The reason being that the moment you make the solution generic, moreover the 
> moment you want it to be used in RIB and data plane I am afraid you are 
> running into similar (even if local) deaggregation mechanism like recently 
> described in RIFT. That would kill all the scalability of advertising summary 
> routes in the first place and I bet would face lots of opposition. 
> 
> Thx,
> R.
>  
>>> I would actually trim most use cases leaving just one - to signal remote 
>>> service node (ex: PE) going down in the presence of summary route being 
>>> advertised from remote area or pop. 
>  [WAJ] Yes, this may be the most useful use case, but the PUA mechanism can 
> also apply to other scenarios. We want to make it one general solution.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Jeff Tantsura]

To add to Les’s point of BGP only scenario, during MSD IESG reviews, BGP-LS 
only deployment was found not well characterized and had been removed from the 
draft. It will require much better discussion to have it included.

Regards,
Jeff

> On Nov 13, 2020, at 15:57, Les Ginsberg (ginsberg)  wrote:
> 
> 
> The points which Ketan has made regarding the use of MTU advertisements 
> defined in RFC 7176 are very valid. Indeed, the contents of the sub-TLV 
> defined in https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend 
> upon the TRILL specific MTU-probe/MTU-ack procedures defined in 
> https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures are 
> not currently applicable to non-TRILL environments.
>  
> So, there are no existing IGP advertisements defined which can support the 
> goals of this draft.
>  
> As Ketan has also indicated, there is no discussion in the draft of how a BGP 
> only network (for example) could provide the information of interest.
>  
> From my perspective, WG adoption of this draft in ANY WG is premature.
> This might be a useful functionality to have – but at the moment we simply 
> have an idea with no definition of how to implement/deploy it.
>  
> So I therefore oppose WG adoption of this draft by IDR.
>  
> Continuing the discussion is certainly useful – and I would encourage the 
> current authors to investigate and propose relevant mechanisms 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 Hares ; 'Jeff Tantsura' ; 
> 'Stephane Litkowski (slitkows)' ; 
> i...@ietf.org; 'Acee Lindem (acee)' 
> Cc: lsr@ietf.org
> Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 
> to 11/16/2020)
>  
> Hi Authors,
>  
> I believe this work is useful and should be taken up. It has value in 
> providing the link MTU as part of the topology information via BGP-LS. 
> However, as pointed out by others on this thread, the draft should remain 
> scoped to just that – i.e. providing link MTU information. The discussion 
> related to Path MTU and applicability to SR networks are best left outside 
> the scope of this standards track draft.
>  
> Hi Sue,
>  
> I would support the points made by Acee for not taking up this draft in IDR 
> WG and instead doing this in LSR.
>  
> Besides the missing coverage for OSPFv2/v3, there are also issues with how 
> this would work with ISIS. The reference to the ISIS Trill specification 
> points to this TLV https://tools.ietf.org/html/rfc7176#section-2.4 – if you 
> see, there is more here than just the MTU value. What is more critical is the 
> ISIS procedures (in non-Trill deployments) on how this value is determined. 
> Please do not mix the following :
>  
> The MTU sub-TLV is used to optionally announce the MTU of a link as
>specified in [RFC6325], Section 4.2.4.4.
>  
> Are the authors trying to specify that these Trill procedures for testing MTU 
> need to be adopted for regular ISIS deployments.
>  
> My take is that while the ISIS TLV defined for Trill may be re-used in normal 
> ISIS deployments, its usage and procedures need to be specified. Copying the 
> LSR WG so that I may be corrected if I am wrong here.
>  
> Coming to the point of BGP-only networks, the draft has zero text related to 
> that scenario. Moreover, the procedures for BGP-LS advertisements in BGP only 
> fabric need to be specified as a base. The 
> https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/ was 
> my attempt to specify those procedures and it would be great if the IDR WG 
> could review and provide feedback to this document and consider for adoption 
> so we can cover the BGP-only networks.
>  
> I would also like to offer support/help to the authors in adding the 
> necessary OSPFv2/v3 support for the same in an LSR draft where we could 
> tackle both the IGPs and BGP-LS encoding and procedures together.
>  
> Thanks,
> Ketan
>  
> From: Idr  On Behalf Of Susan Hares
> Sent: 13 November 2020 00:20
> To: 'Jeff Tantsura' ; 'Stephane Litkowski 
> (slitkows)' ; i...@ietf.org; 'Acee 
> Lindem (acee)' 
> Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 
> to 11/16/2020)
>  
> Jeff and Authors of draft-zhu-idr-bgp-ls-path-mtu:
>  
> I do believe the authors agreed to renaming the draft.   
>  
> Does the name:   draft-xxx-idr-bgp-ls-link-mtu work for
> the authors and interested IDR participants.

Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

[Jeff Tantsura]

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/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/ 
> proposes the extension to LSA that can carry the three SubTLVs that are used 
> to represent the Running Status and Environment information of the 5G Edge 
> Computing Servers attached to the router:
>
>  • Load measurement sub-TLV
>  • Capacity Index  Sub-TLV
>  • Preference Index  Sub-TLV
>
> Several sections of the draft are devoted to describe what those measurement 
> are and why need them for 5G Edge Computing, which may have made it not so 
> straightforward when reading in a rush.
>
> The Goal of the OSPF extension is to carry those Sub-TLVs in the router’s LSA 
> to be advertised to other routers in the 5G Local Data Network.
>
> If using your suggested RFC7684 OSPFv2 Extended Prefix TLV, the extension 
> does seem easier and cleaner:
>
> We can have:
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type                          | Length                        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Route Type    | Prefix Length | AF            | Flags         |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Address Prefix (variable)                                     |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Load Measurement Sub-TLV                                      |
> ~                                                               ~
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | capacity Index Sub-TLV                                        |
> ~                                                               ~
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Site Preference Sub-TLV                                       |
> ~                                                               ~
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> RFC7684 only has the Extended Prefix TLV for IPv4. If the App Server 
> addresses are in IPv6, should we specify the extension to RFC8362 in the same 
> draft? Or define a new AF type for the same extension to RFC7684?
>
> Your guidance is greatly appreciated.
>
> Thank you very much.
>
> Linda Dunbar
>
>
> From: Acee Lindem (acee) 
> Sent: Tuesday, November 3, 2020 1:38 PM
> To: Linda Dunbar ; Yingzhen Qu 
> ; lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: Need 10 minute slot to discuss OSPF extension for 5G Edge 
> Computing (was RE: [Lsr] IETF 109 LSR Presentation Slot Requests
>
> We have a pretty full schedule and we add you as optional. I took a look at 
> the draft and it is all over the place right now with standardization 
> requested for one solution but 3 separate solutions partially specified. It 
> could benefit from some WG mailing list discussion prior to a 10 minute 
> presentation where we wouldn’t have time to discuss the many issues.
>
> One major issue is that you should be extending RFC 7684 rather than RFC 3630 
> and it seems you these app-server selection metrics should be associated with 
> a prefix and NOT a stub link (i.e., the application server address).
>
> I’ll try to read it in more depth before IETF 109.
>
> Thanks,
> Acee
>
> From: Linda Dunbar 
> Date: Monday, November 2, 2020 at 10:12 PM
> To: Yingzhen Qu , "lsr@ietf.org" , 
> "lsr-cha...@ietf.org" 
> Subject: Need 10 minute slot to discuss OSPF extension for 5G Edge Computing 
> (was RE: [Lsr] IETF 109 LSR Presentation Slot Requests
> Resent-From: 
> Resent-To: Yingzhen Qu , Acee Lindem 
> , Christian Hopps 
> Resent-Date: Monday, November 2, 2020 at 10:12 PM
>
> LSR Chairs, YingZhen,
>
> Can you give us 10 minute slot to present this new draft:
> https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/
>
> This draft describes an OSPF extension that can distribute the 5G Edge 
> Computing App running status and environment, so that other routers in the 5G 
> Local Data Network can make intelligent decision on optimizing forwarding of 
> flows from UEs. The goal is to improve latency and performance for 5G Edge 
> Computing services.
>
> Thank you very much,
>
> Linda Dunbar
>
> From: Lsr  On Behalf Of Yingzhen Qu
> Sent: Monday, October 19, 2020 3:52 PM
> To: lsr@ietf.org; lsr-cha...@ietf.org
> Subject: [Lsr] IETF 109 LSR Presentation Slot Requests
>
> Hi all,
>
> We're now accepting agenda requests for the LSR Working Grouping meeting IETF 
> 109. Please send your requests to lsr-cha...@ietf.org indicating draft name, 
> speaker, and desired duration (covering presentation and discussion).
>
> LSR session is scheduled on Monday, Nov 16, 12:00-14:00 ICT.
>
> Th

Re: [Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02

[Jeff Tantsura]

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 Poll for “ISIS Extensions 
> in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic 
> Engineering” - draft-chen-lsr-isis-rfc5316bis-02. The poll will end at 12:00 
> AM UTC on November 7th, 2020. Please indicate your support of objection on 
> this list prior to the end of the adoption poll.
>  
> Thanks,
> Acee
>  
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Jeff Tantsura]

+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 for them.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
>> -Original Message-
>> From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
>> Sent: Thursday, October 15, 2020 12:33 PM
>> To: Christian Hopps ; lsr@ietf.org
>> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; draft-ietf-lsr-ospf-prefix-
>> origina...@ietf.org
>> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>> 
>> [External Email. Be cautious of content]
>> 
>> 
>> I support moving this document forward.
>> Similar functionality in IS-IS has proved useful.
>> 
>> I would however like to repeat comments I made earlier in the review of this
>> document.
>> The content of the Appendices should be removed.
>> The Appendices define and discuss deriving topology information from prefix
>> advertisements - which is flawed and should not be done.
>> Perhaps more relevant, the purpose of the document is to define  protocol
>> extensions supporting advertisement of the originators of a prefix
>> advertisement. There is no need to discuss how this mechanism might be used 
>> to
>> build topology information.
>> This document should confine itself to defining the protocol extensions - 
>> similar
>> the RFC 7794.
>> 
>> If the authors do not agree to do this, I would encourage this point to be
>> discussed during IESG review.
>> 
>>   Les
>> 
>>> -Original Message-
>>> From: Lsr  On Behalf Of Christian Hopps
>>> Sent: Wednesday, October 14, 2020 11:15 PM
>>> To: lsr@ietf.org
>>> Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org;
>>> lsr-cha...@ietf.org; lsr- a...@ietf.org; Christian Hopps
>>> 
>>> Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>>> 
>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:
>>> 
>>> 
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet
>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO-gk!TaSzQThghtCFOuYPS2VjLqhK
>>> 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$
>>> 
>>> The following IPR has been filed
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;!
>>> !NEt6yMaO-
>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz
>>> 5KtUHQ$
>>> 
>>> Authors,
>>> 
>>>  Please indicate to the list, your knowledge of any other IPR related
>>> to this work.
>>> 
>>> Thanks,
>>> Chris.
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt
>> 6yMaO-
>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdmw8
>> Lc$
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Jeff Tantsura]

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.org/ipr/3448/
> 
> Authors,
> 
>  Please indicate to the list, your knowledge of any other IPR related to this 
> work.
> 
> Thanks,
> Chris.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

[Jeff Tantsura]

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, using a technique similar to that, defined for Inter-AS-TE-v2 LSA provides 
you exactly that.

Cheers,
Jeff
On Oct 12, 2020, 11:06 AM -0700, Acee Lindem (acee) 
, wrote:
> Speaking WG member:
>
> Hi Gyan, Aijun,
>
> Even if I agreed with your use case assuming a passive interface denotes the 
> boundary between two domains as shown in figure 1 in your draft (which I 
> don’t), you still should not be trying to hack the prefixes with what is 
> inherently link attribute. Can I state this anymore simply or are you are 
> just going to restate your requirements again???
>
> Acee
>
> From: Gyan Mishra 
> Date: Sunday, October 11, 2020 at 3:19 PM
> To: Acee Lindem 
> Cc: Aijun Wang , Aijun Wang 
> , "Peter Psenak (ppsenak)" , 
> "lsr@ietf.org" 
> Subject: Re: [Lsr] FW: New Version Notification for 
> draft-wang-lsr-passive-interface-attribute-04.txt
>
>
> Hi Acee
>
> I believe what Aijun is trying to explain is that the primary purpose of PCE 
> for active or passive path computation is for inter-as RSVP-TE PCALC path 
> computation or SR-TE path computation.  So PCE is solving a well known PCALC 
> bin packing problem due to pcalc over subscribing RSVP tunnel bandwidth which 
> is inherent an RSVP issue, but a bigger problematic issue is with being able 
> to build an inter-as TE path with a single or multiple PCE controllers that 
> can take the LSDB link attributes in the TEDs dB opaque LSAs in the ospf case 
> and ISIS TE TLVs and rebuild the topology topology from each TE domain to be 
> able to build a congruent end to end RSVP TE or SR-TE traffic steered path 
> instantiation.
>
> Without the use of PCE controllers as the LSDB link attribute information is 
> not known as RSVP loose ERO static lsp is built or SR SR-TE prefix sid loose 
> path is built, failover due to crank back is impacted for reroute, due to not 
> having a complete depiction of the other AS Link state topology by the head 
> end or SR source node.
>
> So to build that entire end to end inter-as path for that end to end RSVP TE 
> or SR-TE path instantiation it is critical to indentify the inter-as link 
> eBGP tie link that may have static routes or BGP LU for RSVP head end to tail 
> end reachability and SR-TE reachability to build out the end to end path 
> instantiation.  So the BGP-LS task to  rebuild the lsdb topology of each 
> inter connected AS that the RSVP TE or SR-TE steered path traverses, we need 
> the accurate depiction and that includes the Identification of the  critical 
> inter-as tie link eBGP peering link that is passive for the PCE path 
> computation logic for the end to end inter-as path instantiation.
>
> As for other interfaces using passive in the context of a operator service 
> provider or enterprise core P and PE routers all links are transit with 
> neighbors except the inter-as tie so having this new IGP TLV will help to 
> that end.  In the operator “core” network if there are other  interfaces that 
> don’t need to be advertised as stub, they can easily be excluded from being 
> added into IGP.
>
> Kind Regards
>
> Gyan
>
> On Sat, Oct 10, 2020 at 6:29 AM Acee Lindem (acee) 
>  wrote:
> > quote_type
> > Hi Aijun,
> >
> > From: Aijun Wang 
> > Date: Friday, October 9, 2020 at 9:58 PM
> > To: Acee Lindem , "Peter Psenak (ppsenak)" 
> > , 'Aijun Wang' 
> > Cc: "lsr@ietf.org" 
> > Subject: RE: [Lsr] FW: New Version Notification for 
> > draft-wang-lsr-passive-interface-attribute-04.txt
> >
> > Hi, Acee:
> >
> > From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Acee 
> > Lindem (acee)
> > Sent: Saturday, October 10, 2020 3:48 AM
> > To: Aijun Wang ; Peter Psenak (ppsenak) 
> > ; 'Aijun Wang' 
> > Cc: lsr@ietf.org
> > Subject: Re: [Lsr] FW: New Version Notification for 
> > draft-wang-lsr-passive-interface-attribute-04.txt
> >
> > Speaking as WG member:
> >
> > Hi Aijun,
> >
> > From: Aijun Wang 
> > Date: Thursday, October 8, 2020 at 11:09 PM
> > To: Acee Lindem , "Peter Psenak (ppsenak)" 
> > , 'Aijun Wang' 
> > Cc: "lsr@ietf.org" 
> > Subject: RE: [Lsr] FW: New Version Notification for 
> > draft-wang-lsr-passive-interface-attribute-04.txt
> >
> > Hi, Acee:
> > Sorry for the previous pruned mail. Let's reply you again along your 
> > original question.
> > Please see inline.[WAJ]
> >
> > -Original Message-
> > From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Acee 
> > Lindem (acee)
> > Sent: Wednesday, September 30, 2020 7:47 PM
> > To: Aijun Wang ; Peter Psenak (ppsenak) 
> > ; 'Aijun Wang' 
> > Cc: lsr@ietf.org
> > Subject: Re: [Lsr] FW: New Version Notification for 
> > draft-wang-lsr-passive-interface-attribute-04.txt
> >
> > Hi Aijun,
> > Other than your ill-c

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Jeff Tantsura]

Gyan,

In simple terms - destination lookup would yield a SID (stack) for SR or 
next-hop/adj for IP. For SR, no transport device in between should try to 
derive/evaluate context (source based routing - once you are in the tunnel), in 
IP case - every device will evaluate (per hop routing) the destination. As long 
as the destination lookup result is unambiguous, any combination of algo's 
could be used.

In SR easy days we (large radio vendor :)) were considering using a set of 
loopbacks per virtual topology as a poor-man’s slicing in MBH, where PCE would 
perform “slicing” and FEC2tunnel mapping over flat routing domain, perceived 
too complex ended up with some other ways of mapping.
Flex algo provides an easier (because distributed + additional meta-data, algo 
= context) way of light virtualization as compared to MT and/or fully 
centralized solutions.

Wrt SRv6 vs IPv6 (algo is irrelevant here), I’d assume there’s no conflict, 
however would leave to the implementors to comment.

Cheers,
Jeff

P.S. Acee - nothing gets me more excited than algo 201 with chocolate over it 
;-)
On Oct 11, 2020, 11:21 AM -0700, Gyan Mishra , wrote:
>
> Jeff
>
> So basically as SR Flex Algo uses SR data plane (SID ,context) uniqueness for 
> SR-MPLS label uniqueness and SRv6 Locator uniqueness as compare to IP Flex 
> Algo IP Data plane is destination prefix based.
>
> So you could literally have both IP flex algo and SR flex also data plane as 
> mutually exclusive data plane work in parallel as two ships in the night.
>
> SRv6 uses Longest prefix match and in SRv6-BE w/o SRH which would be 
> destination based IP and SRv6-BE in parallel to IP Flex algo would not work 
> as they would collide on the IPv6 data plane.
>
> Kind Regards
>
> Gyan
>
> > On Sun, Oct 11, 2020 at 1:38 PM Jeff Tantsura  
> > wrote:
> > > Thanks Ron, indeed!  Autocorrect works in mysterious ways  ;-)
> > >
> > > Regards,
> > > Jeff
> > >
> > > > On Oct 11, 2020, at 09:41, Ron Bonica  wrote:
> > > >
> > > > Jeff,
> > > >
> > > > I think that you mean the scope is different.
> > > >
> > > >                                     Ron
> > > >
> > > >
> > > >
> > > > Juniper Business 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 
> > > > draft-bonica-lsr-ip-flexalgo-00.txt
> > > >
> > > > [External Email. Be cautious of content]
> > > >
> > > >
> > > > Jie,
> > > >
> > > > The scoop is different, for SR data plane entry uniqueness is in 
> > > > context of SR domain (SID = value + context), while for IP it is global 
> > > > to the routing domain, FIB entry is a destination, nothing more.
> > > >
> > > > Regards,
> > > > Jeff
> > > >
> > > >> On Oct 10, 2020, at 05:47, Ron Bonica  wrote:
> > > >>
> > > >> 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@ietf.org; Jeff Tantsura 
> > > >> Subject: RE: [Lsr] FW: New Version Notification for
> > > >> draft-bonica-lsr-ip-flexalgo-00.txt
> > > >>
> > > >> [External Email. Be cautious of content]
> > > >>
> > > >>
> > > >> Hi Peter,
> > > >>
> > > >> Thanks for your reply. It aligns with my understanding of FAD, which 
> > > >> is just a set of constraints for path computation. Thus one Flex-Algo 
> > > >> ID could be used with multiple different data planes. Is this 
> > > >> understanding correct?
> > > >>
> > > >> [RB] I never thought about this. Is there a use-case? I think that it 
> > > >> will work, but I would have to

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Jeff Tantsura]

Thanks Ron, indeed!  Autocorrect works in mysterious ways  ;-)

Regards,
Jeff

> On Oct 11, 2020, at 09:41, Ron Bonica  wrote:
> 
> Jeff,
> 
> I think that you mean the scope is different. 
> 
> Ron
> 
> 
> 
> Juniper Business 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 
> draft-bonica-lsr-ip-flexalgo-00.txt
> 
> [External Email. Be cautious of content]
> 
> 
> Jie,
> 
> The scoop is different, for SR data plane entry uniqueness is in context of 
> SR domain (SID = value + context), while for IP it is global to the routing 
> domain, FIB entry is a destination, nothing more.
> 
> Regards,
> Jeff
> 
>> On Oct 10, 2020, at 05:47, Ron Bonica  wrote:
>> 
>> 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@ietf.org; Jeff Tantsura 
>> Subject: RE: [Lsr] FW: New Version Notification for 
>> draft-bonica-lsr-ip-flexalgo-00.txt
>> 
>> [External Email. Be cautious of content]
>> 
>> 
>> Hi Peter,
>> 
>> Thanks for your reply. It aligns with my understanding of FAD, which is just 
>> a set of constraints for path computation. Thus one Flex-Algo ID could be 
>> used with multiple different data planes. Is this understanding correct?
>> 
>> [RB] I never thought about this. Is there a use-case? I think that it will 
>> work, but I would have to try it before saying for sure.
>> 
>> If so, my question is about the scenario below:
>> 
>> A group of nodes in a network support FA-128, a sub-group of them bind 
>> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address. When 
>> one node compute an SR path to a destination, can it compute the path to 
>> only pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes which 
>> bind FA-128 to IP address?
>> 
>> [RB] I don't think so. However, you could achieve the same outcome using 
>> link colors.
>> 
>> If so, how could this node know the binding of FA to different data planes 
>> on other nodes?
>> 
>> Best regards,
>> Jie
>> 
>>> -Original Message-
>>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
>>> Sent: Friday, October 9, 2020 11:58 PM
>>> To: Dongjie (Jimmy) ; Ron Bonica 
>>> ; Yingzhen Qu 
>>> ; Gyan Mishra 
>>> Cc: lsr@ietf.org; Jeff Tantsura 
>>> Subject: Re: [Lsr] FW: New Version Notification for 
>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>> 
>>> Hi Jimmy,
>>> 
>>> 
>>>>> On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
>>>>> Hi Ron,
>>>>> 
>>>>> Thanks for explaining the difference between IP Flex-Algo and SR 
>>>>> Flex-algo. As
>>> you said, the major difference is the data plane.
>>>> 
>>>> If my understanding is correct, for one Flex-Algo to be used 
>>>> correctly, the set
>>> of nodes need to apply consistent constraints in computation, and 
>>> bind the FAD to the same data plane.
>>>> 
>>>> Is it possible that different nodes may use the same Flex-Algo with 
>>>> different
>>> data plane, e.g. some with SR-MPLS, some with SRv6, and some with 
>>> pure IP etc., or each Flex-Algo is always associated with only one 
>>> data plane? In the former case, should the flex-algo definition also 
>>> indicate the data plane(s) to be used with the flex-algo?
>>> 
>>> let me respond to this query, as this is not specific to Ron's draft.
>>> 
>>> FAD is data plane agnostic and is used by all of them.
>>> 
>>> thanks,
>>> Peter
>>> 
>>>> 
>>>> Best regards,
>>>> Jie
>>>> 
>>>>> -Original Message-
>>>>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
>>>>> Sent: Sunday, October 4, 2020 4:34 AM
>>>>> To: Yingzhen Qu ; Peter Psenak 
>>>>> ; Gyan Mishra 
>>>>> Cc: lsr@ietf.org; Jeff 

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Jeff Tantsura]

Jie,

The scoop is different, for SR data plane entry uniqueness is in context of SR 
domain (SID = value + context),
while for IP it is global to the routing domain, FIB entry is a destination, 
nothing more.

Regards,
Jeff

> On Oct 10, 2020, at 05:47, Ron Bonica  wrote:
> 
> 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@ietf.org; Jeff Tantsura 
> Subject: RE: [Lsr] FW: New Version Notification for 
> draft-bonica-lsr-ip-flexalgo-00.txt
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Peter,
> 
> Thanks for your reply. It aligns with my understanding of FAD, which is just 
> a set of constraints for path computation. Thus one Flex-Algo ID could be 
> used with multiple different data planes. Is this understanding correct?
> 
> [RB] I never thought about this. Is there a use-case? I think that it will 
> work, but I would have to try it before saying for sure.
> 
> If so, my question is about the scenario below:
> 
> A group of nodes in a network support FA-128, a sub-group of them bind FA-128 
> to SR SIDs, another sub-group of them bind FA-128 to IP address. When one 
> node compute an SR path to a destination, can it compute the path to only 
> pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes which bind 
> FA-128 to IP address? 
> 
> [RB] I don't think so. However, you could achieve the same outcome using link 
> colors.
> 
> If so, how could this node know the binding of FA to different data planes on 
> other nodes?
> 
> Best regards,
> Jie
> 
>> -Original Message-
>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
>> Sent: Friday, October 9, 2020 11:58 PM
>> To: Dongjie (Jimmy) ; Ron Bonica 
>> ; Yingzhen Qu 
>> ; Gyan Mishra 
>> Cc: lsr@ietf.org; Jeff Tantsura 
>> Subject: Re: [Lsr] FW: New Version Notification for 
>> draft-bonica-lsr-ip-flexalgo-00.txt
>> 
>> Hi Jimmy,
>> 
>> 
>>>  On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
>>> Hi Ron,
>>> 
>>> Thanks for explaining the difference between IP Flex-Algo and SR 
>>> Flex-algo. As
>> you said, the major difference is the data plane.
>>> 
>>> If my understanding is correct, for one Flex-Algo to be used 
>>> correctly, the set
>> of nodes need to apply consistent constraints in computation, and bind 
>> the FAD to the same data plane.
>>> 
>>> Is it possible that different nodes may use the same Flex-Algo with 
>>> different
>> data plane, e.g. some with SR-MPLS, some with SRv6, and some with pure 
>> IP etc., or each Flex-Algo is always associated with only one data 
>> plane? In the former case, should the flex-algo definition also 
>> indicate the data plane(s) to be used with the flex-algo?
>> 
>> let me respond to this query, as this is not specific to Ron's draft.
>> 
>> FAD is data plane agnostic and is used by all of them.
>> 
>> thanks,
>> Peter
>> 
>>> 
>>> Best regards,
>>> Jie
>>> 
>>>> -Original Message-
>>>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
>>>> Sent: Sunday, October 4, 2020 4:34 AM
>>>> To: Yingzhen Qu ; Peter Psenak 
>>>> ; Gyan Mishra 
>>>> Cc: lsr@ietf.org; Jeff Tantsura 
>>>> Subject: Re: [Lsr] FW: New Version Notification for 
>>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>> 
>>>> Hi Yingzhen,
>>>> 
>>>> IP Flexible Algorithms are like SR Flexible Algorithms in the 
>>>> following
>> respects:
>>>> 
>>>> - Links have IGP metrics, TE metrics, delay metrics and 
>>>> administrative colors
>>>> - FADs define Flexible Algorithms
>>>> 
>>>> More specifically, the FAD:
>>>> 
>>>> - Indicates which metric type the Flexible Algorithm uses
>>>> - Specifies constraints in terms of link colors that are included 
>>>> or excluded from the Flexible Algorithm.
>>>> 
>>>> The significant difference between IP Flexible Algorithms and SR 
>>>> Flexible Algorithms is:
>>>> 
>>>> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators
>>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses.
>>>> 
>>>> 

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Jeff Tantsura]

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 
potential hierarchy) - the prefix itself defines the context(topology) and must 
be globally unique, since IPv4 header can’t have any additional meta-data 
attached.

Cheers,
Jeff
On Oct 2, 2020, 1:15 PM -0700, Yingzhen Qu , wrote:
> Hi Peter,
>
> My understanding of flex-algo is that for traffic destined to a prefix on a 
> particular algo, it can only be routed on routers belong to that algo, which 
> also means only routers in that algo calculates how to reach that prefix and 
> install it into the routing table. It seems to me that using flex-algo 
> (section 12 of the draft) it's possible to have a loopback address associated 
> with only one algo, please correct me if I'm missing or misunderstood 
> something.
>
> Thanks,
> Yingzhen
>
> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak"  behalf of ppsenak=40cisco@dmarc.ietf.org> wrote:
>
> Gyan,
>
> On 02/10/2020 18:30, Gyan Mishra wrote:
> > All,
> >
> > With SRv6 and IP based flex algo a generic question as it applies to
> > both. Is it possible to have within a single IGP domain different sets
> > of nodes or segments of the network running different algorithms.
>
> absolutely.
>
> > From
> > both drafts it sounds like all nodes have to agree on same algorithm
> > similar to concept of metric and reference bandwidth all have to have
> > the same style metric and play to the same sheet of music.
>
> all participating nodes need to agree on the definition of the flex-algo
> and advertise the participation. That's it.
>
> > If there was
> > a way to use multiple algorithms simultaneously based on SFC or services
> > and instantiation of specific algorithm based on service to be
> > rendered. Doing so without causing a routing loop or sub optimal
> > routing.
>
> you can certainly use multiple algorithms simultaneously and use algo
> specific paths to forward specific traffic over it. How that is done
> from the forwarding perspective depends in which forwarding plane you
> use. Flex-algo control plane is independent of the forwarding plane.
>
>
> > I thought with flex algo that there exists a feature that on
> > each hop there is a way to specify which algo to use hop by hop similar
> > to a hop by hop policy based routing.
>
> no, there is no hop-by-hop classification, that is problematic and does
> not scale for high speeds. Classification is done at the ingress only.
>
> thanks,
> Peter
>
> >
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637372537869296887&sdata=R%2FI%2BAUkcw12FmgDtsh%2FBOL7zLjPF%2BwwRpqwnE2Ndv%2Fg%3D&reserved=0
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

[Jeff Tantsura]

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, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.
>
> Thanks,
> Chris and Acee.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Jeff Tantsura]

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,
Jeff
On Sep 30, 2020, 9:03 AM -0700, Ron Bonica 
, wrote:
> Hi Muthu,
>
> Thanks for the review.
>
> An interface can be associated with, at most, one Flexible Algorithm. 
> Likewise, an IP address can be associated with, at most, one Flexible 
> Algorithm.
>
> I tried to express this in the text below, but probably didn’t do a very good 
> job. If you can think of a better way to say it, I would appreciate 
> suggestions.
>
>   Ron
>
> Text from draft
> 
>
> Network operators configure multiple loopback interfaces on an egress
>    node.  They can associate each loopback interface with:
>
>    o  Zero or more IP addresses.
>
>    o  Zero or one Flexible Algorithms.
>
>    If an IP address and a Flexible Algorithm are associated with the
>    same interface, they are also associated with one another.  An IP
>    address MAY be associated with, at most, one interface.
>
>
>
>
>
> Juniper Business Use Only
> From: Muthu Arul Mozhi Perumal 
> Sent: Wednesday, September 30, 2020 9:59 AM
> To: Ron Bonica 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] FW: New Version Notification for 
> draft-bonica-lsr-ip-flexalgo-00.txt
>
> [External Email. Be cautious of content]
>
> A quick question:
>   If an IP address and a Flexible Algorithm are associated with the
>   same interface, they are also associated with one another.  An IP
>   address MAY be associated with, at most, one interface.
>
> If multiple IP addresses and multiple flexible algorithms are associated with 
> a loopback interface, is each IP address associated with all flexible 
> algorithms? What matters is the association b/w an IP address and a flexalgo, 
> so the relationship should be defined in a direct way rather than each being 
> associated with an interface, right?
>
> Regards,
> Muthu
>
> On Tue, Sep 29, 2020 at 7:07 PM Ron Bonica 
>  wrote:
>
> Please review and comment
>
>                                        Ron
>
>
>
> Juniper Business Use Only
>
> > -Original Message-
> > From: internet-dra...@ietf.org 
> > Sent: Tuesday, September 29, 2020 9:36 AM
> > To: Parag Kaneriya ; Shraddha Hegde
> > ; Ron Bonica ; Rajesh M
> > ; William Britto A J 
> > Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
> >
> > [External Email. Be cautious of content]
> >
> >
> > A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
> > has been successfully submitted by Ron Bonica and posted to the IETF
> > repository.
> >
> > Name:           draft-bonica-lsr-ip-flexalgo
> > Revision:       00
> > Title:          IGP Flexible Algorithms (Flexalgo) In IP Networks
> > Document date:  2020-09-29
> > Group:          Individual Submission
> > Pages:          14
> > URL:            
> > https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica-
> > lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
> > Status:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-lsr-
> > ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
> > Htmlized:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
> > bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
> > Htmlized:       
> > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
> > bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$
> >
> >
> > Abstract:
> >    An IGP Flexible Algorithm computes a constraint-based path and maps
> >    that path to an identifier.  As currently defined, Flexalgo can only
> >    map the paths that it computes to Segment Routing (SR) identifiers.
> >    Therefore, Flexalgo cannot be deployed in the absence of SR.
> >
> >    This document extends Flexalgo, so that it can map the paths that it
> >    computes to IP addresses.  This allows Flexalgo to be deployed in any
> >    IP network, even in the absence of SR.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [spring] draft-tgraf-ipfix-mpls-sr-label-type

[Jeff Tantsura]

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 right place to 
collect this data though, since most of meta-data has already been lost 
(flattened FIB structures often contain bare minimum) and really heavily 
depends on the implementation.

Cheers,
Jeff
On Aug 14, 2020, 10:36 AM -0700, Ketan Talaulikar (ketant) 
, wrote:
> < also copying Spring WG for their review/inputs >
>
> Hi Thomas/All,
>
> I have reviewed the draft and would like to share a different perspective.
>
> What or how much value be there on determining whether a SR Prefix SID was 
> signalled/programmed on a node via OSPFv2/OSPFv3/ISIS – what matters and is 
> more important is that it is a Prefix SID. Hardly any deployments would be 
> running multiple protocols and learning the same prefix from different IGPs. 
> IPFIX may be picking this information from a FIB in some implementation where 
> the protocol does not matter and this information is not available therein.
>
> On some nodes, the same Prefix SID may be learnt via both BGP and IGP – what 
> would we use/show?
>
> I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR 
> BGP Peering SID and so on … for the MPLS Label Type.
>
> This also takes away the need for the second table that is being proposed to 
> a large extent. For that table proposal, it is very difficult and in some 
> cases not possible to different between Prefix and Node and Anycast SID. Many 
> of these types are control plane elements and we can be sure more get added. 
> Is there really much value in differentiation between say an Adjacency SID 
> and LAN Adjacency SID?
>
> Could we evaluate the implementation overhead and complexity of this level of 
> categorization/information in IPFIX against their value in flow analysis to 
> perhaps consider a middle ground?
>
> Thanks,
> Ketan
>
> From: Lsr  On Behalf Of thomas.g...@swisscom.com
> Sent: 31 July 2020 20:52
> To: han...@gredler.at
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type
>
> Hi Hannes,
>
> Thanks a lot for the feedback. Yes, makes completely sense. Will take it for 
> the next update...
>
> Best Wishes
> Thomas
>
>
> From: Hannes Gredler 
> Sent: Wednesday, July 29, 2020 9:31 AM
> To: Graf Thomas, INI-NET-DCF 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type
>
> Thomas,
>
> I have one comment/suggestion to Paragraph 4 (IANA Considerations).
>
> Please add also a code point for BGP Prefix-SID - it’s quite popular in DC 
> deployments.
> https://tools.ietf.org/html/rfc8669
>
> thanks,
>
> /hannes
>
> > On 28.07.2020, at 10:11, thomas.g...@swisscom.com wrote:
> >
> > Dear lsr,
> >
> > I presented the following draft
> >
> > Export of MPLS Segment Routing Label Type Information in IP Flow 
> > Information Export (IPFIX)
> > https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04
> >
> > at the spring working group at IETF 108 yesterday
> > https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-information-export-ipfix-00.pdf
> >
> > and today at OPSAWG where I call for adoption.
> >
> > This draft adds additional segment routing code points for in the IANA 
> > IPFIX registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types 
> > to gain further insights into the MPLS-SR forwarding-plane.
> >
> > I have been asked to not only gather feedback from spring and opsawg but 
> > also from lsr and mpls working groups since these code points are related 
> > to link state routing protocols and mpls data plane.
> >
> > I am looking forward to your feedback and input.
> >
> > Best Wishes
> > Thomas Graf
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> spring mailing list
> spr...@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[Jeff Tantsura]

+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, 2020 1:37 PM
> To: Yingzhen Qu ; Les Ginsberg (ginsberg) 
> ; Les Ginsberg (ginsberg) 
> ; BRUNGARD, DEBORAH A ; 
> The IESG 
> Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; Acee Lindem (acee) 
> ; draft-ietf-isis-te-...@ietf.org; lsr@ietf.org
> Subject: RE: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
> (with DISCUSS and COMMENT)
>
> I had mentioned “Application Specific”
>
> Yours Irrespectively,
>
> John
>
>
> Juniper Business Use Only
> From: Yingzhen Qu 
> Sent: Thursday, June 18, 2020 4:30 PM
> To: Les Ginsberg (ginsberg) ; Les Ginsberg (ginsberg) 
> ; BRUNGARD, DEBORAH A ; 
> The IESG 
> Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; Acee Lindem (acee) 
> ; draft-ietf-isis-te-...@ietf.org; lsr@ietf.org
> Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
> (with DISCUSS and COMMENT)
>
> [External Email. Be cautious of content]
>
> Hi Les,
>
> The proposed new titles are much better than the old ones. I’m debating 
> between “application-scoped” and “application-based”, but no strong opinion. 
> It’s up to you and Peter to decide a good name.
>
> Thanks,
> Yingzhen
>
> From: "Les Ginsberg (ginsberg)" 
> Date: Thursday, June 18, 2020 at 11:04 AM
> To: Yingzhen Qu , "Les Ginsberg (ginsberg)" 
> , "BRUNGARD, DEBORAH A" 
> , The IESG 
> Cc: "lsr-cha...@ietf.org" , "aretana.i...@gmail.com" 
> , "Acee Lindem (acee)" , 
> "draft-ietf-isis-te-...@ietf.org" , 
> "lsr@ietf.org" 
> Subject: RE: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
> (with DISCUSS and COMMENT)
>
> Yingzhen –
>
> Thanx for providing the YANG example – and for taking on the additions to the 
> IGP YANG models.
>
> Regarding changing the titles of the documents, I see your point. The work 
> started because of issues related to different TE applications (RSVP-TE and 
> SR Policy) – but you are correct that the solution provided can be used by 
> applications that are NOT TE related.
>
> Peter and I are still mulling this over, but how about these for new titles?
>
> IS-IS Application-Scoped Link Attributes
> OSPF Application-Scoped Link Attributes
>
>    Les
>
>
>
>
> From: Yingzhen Qu 
> Sent: Wednesday, June 17, 2020 11:29 PM
> To: Les Ginsberg (ginsberg) ; BRUNGARD, 
> DEBORAH A ; The IESG 
> Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; Acee Lindem (acee) 
> ; draft-ietf-isis-te-...@ietf.org; lsr@ietf.org
> Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
> (with DISCUSS and COMMENT)
>
> Hi Deborah and Les,
>
> From YANG model’s perspective, whether there is a default value is based on 
> the protocol definition and it is optional. For this case, if there is no 
> default value the following could be an example YANG definition:
>
>   choice te-app-op-mode {
>     mandatory "true";
>     leaf legacy {
>   type empty;
>     }
>     leaf transition {
>   type empty;
>     }
>     leaf app-specific{
>   type empty;
>     }
>     description
>   "Link attributes mode.";
>   }
>
> “mandatory true” is used here to make this configuration mandatory, which 
> means implementations supporting this draft need to explicitly config the 
> operation mode. I’ll add the YANG support of this feature for both OSPF and 
> ISIS into the next version of the augmentation drafts.
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/
> https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/
>
> BTW, I’m now wondering whether the title of the draft is precise? Instead of 
> “IS-IS TE Attributes per application”, maybe something like “IS-IS per 
> application link attributes”? considering more applications will be using the 
> sub-TLV and they may not be TE. Same for OSPF.
>
> Thanks,
> Yingzhen
>
> From: Lsr  on behalf of "Les Ginsberg (ginsberg)" 
> 
> Date: Wednesday, June 17, 2020 at 4:19 PM
> To: "BRUNGARD, DEBORAH A" , The IESG 
> Cc: "lsr-cha...@ietf.org" , "aretana.i...@gmail.com" 
> , "Acee Lindem (acee)" , 
> "draft-ietf-isis-te-...@ietf.org" , 
> "lsr@ietf.org" 
> Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
> (with DISCUSS and COMMENT)
> Resent-From: 
>
> Deborah –
>
> We have a protocol extension that provides alternative ways of supporting 
> legacy applications.
>
> Under the conditions noted in Section 6.1, implementations have a choice as 
> to which advertisements they use.
> There is nothing in the document to specify which choice is the default – nor 
> should there be.
> To do so  implies that you believe that an implementation which is otherwise 
> compliant (i.e., it sends/receives TLVs in accordance with 

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

[Jeff Tantsura]

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> wrote:
>
> [External Email. Be cautious of content]
>
>
> This begins a 2 week WG adoption call for the following draft:
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection__;!!NEt6yMaO-gk!WcIjGwXb7biFdhbdSv8WhQa86HqfdhAiVT-T4gE68NjQ9_Uii9O_HMCdksRshic$
>
> The draft would be adopted on the Experimental track.
>
> Please indicate your support or objection by June 24, 2020.
>
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.
>
> Thanks,
> Chris and Acee.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!WcIjGwXb7biFdhbdSv8WhQa86HqfdhAiVT-T4gE68NjQ9_Uii9O_HMCdWR4R6q4$
>
>
> Non-Juniper
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Thoughts on the area proxy and flood reflector drafts.

[Jeff Tantsura]

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 simplified model of this design can be seen as a horseshoe of horseshoes. 
>> the Major horseshoe is L2 and the minor horseshoes are L1. Each L1 area has 
>> 2 L2 routers for redundancy (I'll consider more though), and all L2 routers 
>> are full-mesh connected to support that redundancy.
>> 
>> Telco
>> 
>> 
>> 
>> But let's map this to a more DC centric view (I guess?) where each L1 area 
>> now has 10 L2 routers instead of 2 (i.e., 10%, but that could be change that 
>> later if need be).
> 
> 
> The key point here is not a DC centric view, but one of scale. The above 
> worked just fine back when we were terminating T1’s and E1’s.  Now, PE 
> routers easily have terabit capacity. WIth the 100:1 ratio between the PE and 
> the L1L2 routers (Area Edge routers), the bandwidth requirements drive us to 
> petabit, multi-chassis routers. While these have been great fun to build, 
> operators are not happy with this direction. Forklift upgrades are necessary 
> with every silicon cycle. The complexity of the router has multiplied, the 
> blast radius is off the charts, and the premiums charged for these devices 
> are impressive. As a result, folks are trying to explore a ’scale-out’ 
> approach. Rather than 2 huge area edge routers, they would much rather be 
> able to scale out the area edge to be many routers.
> 
> If you pursue this design direction, the first thing you observe is that you 
> can see is that you cannot afford to build a full-mesh of inter-area circuits 
> across all of the area edge routers.
> 
> And if your network is a bit more geographically dispersed, you find that it 
> becomes inefficient to have even a full mesh at the area level. This forces 
> some areas to become transit.
> 
> Between these two forces, we are compelled to push transit traffic through 
> the internals of an area.
> 
>> Natural Design
>> 
>> 
>> 
>> 
> 
> 
>> Now for whatever reason some operators do not want to provision 
>> high-bandwidth transit links between their L2 routers in their L1 areas. 
>> This is critically important b/c otherwise you would simply use the above 
>> Natural Design.. I'd like to better understand why that isn't just the 
>> answer here.
> 
> 
> In this design, you’ve shown ten area edge routers.  Yes, you could provision 
> a full mesh of links between them.  The issue remains one of scalability and 
> uniformity. The number of ports per area edge router has to scale linearly 
> with the size of area edge and the overall number of links used for this 
> purpose is O(n^2).  Combine this with the fact that any non-uniformity in the 
> traffic pattern and your full mesh ends up being congested and under-utilized 
> simultaneously.  
> 
> All is not lost, however. Charles Clos to the rescue. By structuring each 
> area as a Clos (or Benes) network (which my employer seems to insist on 
> spelling ‘leaf-spine’), you avoid this. I assume I don’t need to go into 
> details on this.  
> 
> 
>> Area Proxy
>> 
>> First I'll look at area proxy. This seems a fairly simple idea, basically 
>> it's taking the now L1L2 areas and advertising them externally as a single 
>> LSP so the impact is very similar to if they were L1 only. This maps fairly 
>> closely to the Telco and Natural Design from above. Each L1 router in the 
>> Telco design would have 100 LSPs The L12 routers would have 100 L1 + 16 L2 
>> LSP. In the Natural Design each L1 router has 100 L1 and each L12 router 
>> would have 100 L1 and 80 L2. With Area Proxy each router  has 100 L1 and 100 
>> "Inner L2 LSPs" and 80 "Outer LSPs" + 8 "Outer L2 LSPs"
> 
> 
> We’ve made some changes in the latest version of the draft.  In the current 
> version, we require that each router in the area be L1L2.  However, only one 
> LSP is advertised externally for each area.  Thus, each router will see 100 
> L1 LSPs, 100 L2 LSPs and 8 L2 Proxy LSPs.
> 
> 
>> The key thing to note here is that if you double the number of areas you 
>> only add to the Outside LSP and Proxy count just as it would scale in the 
>> Natural Design, so going from 8 to 16 areas here adds 80 more "Outside LSPs" 
>> and 8 more L2 Proxy LSPs for a total of 276 L2 LSPs even though you've added 
>> 800 more routers to your network.
> 
> 
> Doubling the number of areas would give you 16 L2 proxy LSPs, so you end up 
> going from 208 LSPs to 216.  The key point here is that the database now 
> scales linearly with the number of areas.
> 
> Demo time:
> 
> In a lab setup, we have an area of five routers.  We have three L2 routers..  
> The database on one of the pure L2 routers is just 5 entries (three L2, one 
> proxy LSP, one pseudonode):
> 
> rtrmpls8>show isis data
> 
> IS-IS Instance: Amun VRF: 

Re: [Lsr] Call for WG adoption of https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01

[Jeff Tantsura]

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 works meeting 
> use case requirements of multiple customers which neither TTZ nor draft-proxy 
> is addressing or can satisfy in terms of deployment realities. While we would 
> love to not squat on codepoints and ideally have an interoperable solution 
> between vendors it will be the customer reality that will drive deployment 
> and ultimately what runs in their networks.
>
> thanks
>
> --- tony
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ietf-lsr-flex-algo

[Jeff Tantsura]

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 
path that meets the constraints(classical BGP-LS + PCEP scenario) vs building a 
dynamic topology of connected nodes that meet a set of constrains, in first 
case, change in topology/capabilities would cause path 
recalculation/reoptimization on the PCE while in the second - IGP would 
recompute the topology locally.

Regards,
Jeff

> On May 9, 2020, at 01:27, Wang, Weibin (NSB - CN/Shanghai) 
>  wrote:
> 
> 
> Ketan, thank you for clarification.
>  
>  
>  
> Cheers!
>  
> Wang Weibin
>  
> From: Ketan Talaulikar (ketant)  
> Sent: 2020年5月9日 14:52
> To: Wang, Weibin (NSB - CN/Shanghai) ; 
> lsr@ietf.org
> Subject: RE: draft-ietf-lsr-flex-algo
>  
> Hi Wang,
>  
> You are correct. Though I wouldn’t call it a goal but rather a 
> benefit/advantage – same applies to SR-MPLS where the label stack can be 
> reduced.
>  
> Thanks,
> Ketan
>  
> From: Lsr  On Behalf Of Wang, Weibin (NSB - CN/Shanghai)
> Sent: 08 May 2020 19:07
> To: lsr@ietf.org
> Subject: [Lsr] draft-ietf-lsr-flex-algo
>  
> Hi authors:
>  
> After reading through this draft lsr-flex-algo, I want to know whether there 
> is a potential goal of this draft to reduce the SRH size with enabling 
> flex-algo with admin group in SRv6 deployment, because without flex-algo we 
> have to have a big SRH size when the SRH include more SRv6 SIDs, if we enable 
> flex-algo under special topology and link constraint condition, in theory we 
> can even construct  a end to end SR path/tunnel without SRH, but it still 
> meet TE requirement. So my question is whether the flex-algo can be used as 
> tool to reduce SRH size?
>  
>  
>  
> Cheers !
>  
> WANG Weibin
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Flooding across a network

[Jeff Tantsura]

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 towards destinations behind C to B so LFA on B wouldn’t 
really help.

Cheers,
Jeff
On May 5, 2020, 5:04 PM -0700, Robert Raszuk , wrote:
> Hi Les,
>
> A side comment but your example shows another - one may say even much more 
> serious issue.
>
> Assume we have LFA/TI-LFA enabled in the network and precomputed on B which 
> get's activated and shifts traffic to E when detects that C is down. 
> Detection is fast .. 10s-100s of milliseconds.
>
> Now if B converges fast and recomputes topology much faster then D it may 
> remove protection and send packets to D natively. Well clearly as we 
> established D is slow and will loop it back.
>
> That is why I mentioned the other day that a fast control plane is not always 
> a good thing (I am sure many will say the opposite - but it is ok ;).
>
> But this proves that consistent convergence time in a domain is rather a good 
> thing regardless if it takes 2 sec or 50 sec on all nodes.
>
> Best,
> Robert.
>
>
>
> > On Wed, May 6, 2020 at 1:35 AM Les Ginsberg (ginsberg) 
> >  wrote:
> > > Bruno -
> > >
> > > Seems like it was not too long ago that we were discussing this in 
> > > person.  Ahhh...the good old days...
> > >
> > > First, let's agree that the interesting case does not involve 1 or even a 
> > > small number of LSPs. For those cases flooding speed does not matter.
> > > The interesting cases involve a large number of LSPs (hundreds or 
> > > thousands). And in such cases LFA/microloop avoidance techniques are not 
> > > applicable.
> > >
> > > Take the following simple topology:
> > >
> > >    |  | ... |    |
> > >  +---+ +---+
> > >  | C | | E |
> > >  +---+ +---+
> > >    |     | 1000
> > >  +---+ +---+
> > >  | B |-| D |
> > >  +---+   1000      +---+
> > >    | |
> > >    | |
> > >     \   /
> > >  \    /
> > >   \ /
> > >    \  /
> > >  +---+
> > >  | A |
> > >  +---+
> > >
> > > There is a topology northbound of C and E (not shown) and a topology 
> > > southbound of A (not shown).
> > > Cost on all links is 10 except B-D and D-E where cost is high.
> > >
> > > C is a node with 1000 neighbors.
> > > When all links are up, shortest path for all northbound destinations is 
> > > via C.
> > > All nodes in the network support fast flooding except for Node D.
> > > Let’s say fast flooding is 500 LSPs/second and slow flooding (Node D) is 
> > > 20 LSPs/seconds.
> > > If  Node C fails we have 1000 LSPs to flood.
> > > All nodes except for D can receive these in 2 seconds (plus internode 
> > > delay time).
> > > D can receive LSPs in 50 seconds.
> > >
> > > When A and B and all southbound nodes receive/process the LSP updates 
> > > they will start sending traffic to Northbound destinations via D.
> > > But for the better part of 50 seconds, Node D has yet to receive all LSP 
> > > updates and still believes that shortest path is via B-C. It will loop 
> > > traffic.
> > >
> > > Had all nodes used slow flooding, it still would have taken 50 seconds to 
> > > converge, but there would be significantly less looping. There could be a 
> > > good amount of blackholing, but this is preferable to looping.
> > >
> > > One can always come up with examples – based on a specific topology and a 
> > > specific failure - where things might be better/worse/unchanged in the 
> > > face of inconsistent flooding speed support.
> > > But I hope this simple example illustrates the pitfalls.
> > >
> > >     Les
> > >
> > > > -Original Message-
> > > > From: bruno.decra...@orange.com 
> > > > Sent: Tuesday, May 05, 2020 8:28 AM
> > > > To: Les Ginsberg (ginsberg) ; lsr@ietf.org
> > > > Subject: Flooding across a network
> > > >
> > > > Les,
> > > >
> > > > > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg
> > > > (ginsberg)
> > > > > Sent: Monday, May 4, 2020 4:39 PM
> > > > [...]
> > > > > when only some nodes in the network support faster flooding the 
> > > > > behavior
> > > > of the whole network may not be "better" when faster flooding is enabled
> > > > because it prolongs the period of LSDB inconsistency.
> > > >
> > > > 1) Do you have data on this?
> > > >
> > > > 2) If not, can you provide an example where increasing the flooding 
> > > > rate on
> > > > one adjacency prolongs the period of LSDB inconsistency across the
> > > > network?
> > > >
> > > > 3) In the meantime, let's try the theoretical analysis on a simple 
> > > > scenario
> > > > where a single LSP needs to be flooded across the network.
> >

Re: [Lsr] FW: New Version Notification for draft-ginsberg-lsr-isis-flooding-scale-02.txt

[Jeff Tantsura]

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.
>
> Les
>
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Friday, April 17, 2020 12:49 PM
> To: Tony Przygienda ; Acee Lindem (acee) ; 
> Peter Psenak (ppsenak) ; Les Ginsberg (ginsberg) 
> 
> Subject: New Version Notification for 
> draft-ginsberg-lsr-isis-flooding-scale-02.txt
>
>
> A new version of I-D, draft-ginsberg-lsr-isis-flooding-scale-02.txt
> has been successfully submitted by Les Ginsberg and posted to the
> IETF repository.
>
> Name: draft-ginsberg-lsr-isis-flooding-scale
> Revision: 02
> Title: IS-IS Flooding Scale Considerations
> Document date: 2020-04-17
> Group: Individual Submission
> Pages: 13
> URL: 
> https://www.ietf.org/internet-drafts/draft-ginsberg-lsr-isis-flooding-scale-02.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/
> Htmlized: 
> https://tools.ietf.org/html/draft-ginsberg-lsr-isis-flooding-scale-02
> Htmlized: 
> https://datatracker.ietf.org/doc/html/draft-ginsberg-lsr-isis-flooding-scale
> Diff: 
> https://www.ietf.org/rfcdiff?url2=draft-ginsberg-lsr-isis-flooding-scale-02
>
> Abstract:
> Link State PDU flooding rates in use are much slower than what modern
> networks can support. The use of IS-IS at larger scale requires
> faster flooding rates to achieve desired convergence goals. This
> document discusses issues associated with increasing flooding rates
> and some recommended practices which allow faster flooding rates to
> be used safely.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] I,Scope of FIT Capability: a node or a link?

[Jeff Tantsura]

+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 indicating that this advertisement does not 
> > belong in the IGP at all (regardless of scope).
> > My opinion on that has not changed.
>
>
> +1
>
> IS-IS is not the correct place to implement Service Discovery mechanisms. The 
> management plane already has ample mechanisms for service and capability 
> discovery.
>
> Tony
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] I,Scope of FIT Capability: a node or a link?

[Jeff Tantsura]

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 -0700, Greg Mirsky , wrote:
> Dear All,
> I've read these two drafts with interest.. In light of the discussion on the 
> LSR WG list, I've been thinking about the scenarios where IFIT is being used.
> draft-song-opsawg-ifit-framework defines the overall IFIT architecture that, 
> as I understand it, applicable to different methods of collecting and 
> transporting telemetry information. 
> draft-wang-lsr-ifit-node-capability-advertisement is based on the view that 
> IFIT is a node-wide capability advertised as a binary flag for each listed 
> method of collecting telemetry information (Option-Type enabled Flag). 
> On-path telemetry collection is performed in the fast path, i.e., at a link 
> layer. But a node might include ports with different capabilities. How such a 
> heterogeneous, IFIT-wise, node will advertise IFIT Capability? To better use 
> available resources for telemetry information collection, it might be helpful 
> to advertise IFIT as a capability of a link, not of a node?
> What do you think?
>
> Regards,
> Greg
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] problem joining interim [Re: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02]

[Jeff Tantsura]

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 just showed 
> up.
> 
> Lou
> 
>> On April 2, 2020 6:10:43 PM Robert Raszuk  wrote:
>> 
>> Hi Chris,
>> 
>> I never noticed the password  
>> 
>> Just few days back I participated in IDR and no password was needed or 
>> perhaps webex invite link contained a token relaxing from needing one. 
>> 
>> Cheers,
>> R..
>> 
>>> On Fri, Apr 3, 2020 at 12:00 AM Christian Hopps  wrote:
>>> 
>>> 
>>> > On Apr 2, 2020, at 5:17 PM, Robert Raszuk  wrote:
>>> > 
>>> > Many thx,
>>> > R.
>>> > 
>>> > PS. As we are talking LSR here 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. 
>>> > 
>>> 
>>> I am very sorry to hear this! We had 64 participants, at least at one point 
>>> that I saw. I set the meeting up, and I don't believe there is any way to 
>>> exclude anyone in particular, I certainly would never have chosen to do 
>>> that.
>>> 
>>> However, Webex has a password requirement when setting up meetings (I 
>>> guess, I tried to not have one, it wouldn't let me) which we included in 
>>> all the details wherever the details were posted, it was "linkstate"..
>>> 
>>> I did notice an email, from webex, during the meeting about a request from 
>>> Bruno to join as guest, but he was in the participant list when I then 
>>> checked. I didn't receive any other emails like that (and FWIW I had 5 
>>> windows over 2 monitors going at once trying to manage all this, so 
>>> noticing the 1 email was lucky).
>>> 
>>> Did it let you skip entering a password (or did it not offer the option in 
>>> the first place)?
>>> 
>>> It would be good to figure this out before the next interim.
>>> 
>>> Thanks,
>>> Chris.
>>> 
>>> ___
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

[Jeff Tantsura]

Hi Aijun,

I understand very well what you are trying to achieve and don’t argue the need 
for it.  My point however - routing protocols are not the most suitable 
transport for it.

Regards,
Jeff

> On Apr 2, 2020, at 19:39, Aijun Wang  wrote:
> 
> Hi, Jeff:
> The draft only propose to transfer the iFIT capability of the Node via the 
> IGP protocol, not the telemetry data.
> As described in the draft, flooding such capability can assist the 
> controller(it collects such information via the BGP-LS) to deploy the iFIT 
> function at the path headend.
> 
> 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 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 distributed PCE or anything else that 
>> could make use of it. Do you see IGP anywhere in between?
>> 
>> 
>> Regards,
>> Jeff
>> 
>>>> On Apr 2, 2020, at 16:03, Robert Raszuk  wrote:
>>>> 
>>> 
>>> Hi Joel,
>>> 
>>> > Robert, you seem to be asking that we pass full information about the
>>> > dynamic network state to all routers  
>>> 
>>> No not at all. 
>>> 
>>> Only TE headends need this information. 
>>> 
>>> To restate ... I am not asking to have a synchronized input to all routes 
>>> in the domain such that their computation would be consistent. 
>>> 
>>> I am only asking for TE headends to be able to select end to end paths 
>>> based on the end to end inband telemetry data. I find this a useful 
>>> requirement missing from any of today's operational deployments. 
>>> 
>>> Many thx,
>>> R. 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On Fri, Apr 3, 2020 at 12:59 AM Joel M. Halpern  
>>>> wrote:
>>>> Robert, you seem to be asking that we pass full information about the 
>>>> dynamic network state to all routers so that they can, if needed, serve 
>>>> as fully intelligent path computation engines.  If you want to do that, 
>>>> you will need more than just the telemetry.  You will need the demands 
>>>> that are coming in to all of those routers, so that you can make global 
>>>> decisions sensibly.
>>>> Which is why we use quasi-centralized path computation engines.
>>>> 
>>>> Yours,
>>>> Joel
>>>> 
>>>> On 4/2/2020 6:16 PM, Robert Raszuk wrote:
>>>> > 
>>>> >  > If you consider such constrains to provide reachability for
>>>> > applications you will likely see value that in-situ telemetry is
>>>> > your friend here. Really best friend as without him you can not do
>>>> > the proper end to end path exclusion for SPT computations..
>>>> > 
>>>> > [as wg member] Are you thinking that shifting traffic to a router is
>>>> > not going to affect it's jitter/drop rate?
>>>> > 
>>>> > 
>>>> > Well this is actually the other way around.
>>>> > 
>>>> > First you have your default topology. They you are asked to 
>>>> > construct new one based on applied constrains.
>>>> > 
>>>> > So you create complete TE coverage and start running end to end data 
>>>> > plane probing over all TE paths (say SR-TE for specific example). Once 
>>>> > you start collecting the probe results you can start excluding paths 
>>>> > which do not meet your applied constraints. And that process continues...
>>>> > 
>>>> > To your specific question - It is not that unusual where routers degrade 
>>>> > their performance with time and in many cases the traffic is not the 
>>>> > cause for it but internal bugs and malfunctions.
>>>> > 
>>>> > Best,
>>>> > R.
>>>> > 
>>>> > ___
>>>> > Lsr mailing list
>>>> > Lsr@ietf.org
>>>> > https://www.ietf.org/mailman/listinfo/lsr
>>>> > 
>>> ___
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

[Jeff Tantsura]

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 distributed PCE or anything else that could make 
use of it. Do you see IGP anywhere in between?


Regards,
Jeff

> On Apr 2, 2020, at 16:03, Robert Raszuk  wrote:
> 
> 
> Hi Joel,
> 
> > Robert, you seem to be asking that we pass full information about the
> > dynamic network state to all routers  
> 
> No not at all. 
> 
> Only TE headends need this information. 
> 
> To restate ... I am not asking to have a synchronized input to all routes in 
> the domain such that their computation would be consistent. 
> 
> I am only asking for TE headends to be able to select end to end paths based 
> on the end to end inband telemetry data. I find this a useful requirement 
> missing from any of today's operational deployments. 
> 
> Many thx,
> R. 
> 
> 
> 
> 
> 
> 
>> On Fri, Apr 3, 2020 at 12:59 AM Joel M. Halpern  wrote:
>> Robert, you seem to be asking that we pass full information about the 
>> dynamic network state to all routers so that they can, if needed, serve 
>> as fully intelligent path computation engines.  If you want to do that, 
>> you will need more than just the telemetry.  You will need the demands 
>> that are coming in to all of those routers, so that you can make global 
>> decisions sensibly.
>> Which is why we use quasi-centralized path computation engines.
>> 
>> Yours,
>> Joel
>> 
>> On 4/2/2020 6:16 PM, Robert Raszuk wrote:
>> > 
>> >  > If you consider such constrains to provide reachability for
>> > applications you will likely see value that in-situ telemetry is
>> > your friend here. Really best friend as without him you can not do
>> > the proper end to end path exclusion for SPT computations..
>> > 
>> > [as wg member] Are you thinking that shifting traffic to a router is
>> > not going to affect it's jitter/drop rate?
>> > 
>> > 
>> > Well this is actually the other way around.
>> > 
>> > First you have your default topology. They you are asked to 
>> > construct new one based on applied constrains.
>> > 
>> > So you create complete TE coverage and start running end to end data 
>> > plane probing over all TE paths (say SR-TE for specific example). Once 
>> > you start collecting the probe results you can start excluding paths
>> > which do not meet your applied constraints. And that process continues...
>> > 
>> > To your specific question - It is not that unusual where routers degrade 
>> > their performance with time and in many cases the traffic is not the 
>> > cause for it but internal bugs and malfunctions.
>> > 
>> > Best,
>> > R.
>> > 
>> > ___
>> > Lsr mailing list
>> > Lsr@ietf.org
>> > https://www.ietf.org/mailman/listinfo/lsr
>> > 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

[Jeff Tantsura]

Robert,

That is why we have a possibility to signal in-band/as per device data that 
could be used by PCE to compute a path that meets the constrains (RFC 
7471/7810), e.g per node BW  reserved/available or cumulative delay, and 
similar, computed by the PCE.
However if the objective functions used by CSPF are coming from outside 
(end2end latency measurement/$$ of a link  as an example) we don’t feed them 
back into IGP, telemetry analysis (done by an external system) are of no 
business of IGP and should be fed (normalized) into PCE directly.
We are not discussing the value of telemetry, which is obvious, but need to 
autodiscover telemetry capability’s and feed (pollute) them into 
IGP->BGP-LS->controller.
I don’t see how this information would be used in route/path computation and 
hence IMHO it doesn’t belong in IGP. Given the need for configuration (besides 
ability to support particular technology) makes this a clear candidate for 
management plane operations. (Chris’ comment about YANG)

Cheers,
Jeff
On Apr 2, 2020, 2:17 PM -0700, Robert Raszuk , wrote:
> Jeff.
>
> > The role of a routing protocol is to distribute: reachability (doh :-))
> > and any additional data that could influence routing decision wrt 
> > reachability.
>
> The bolded text is precisely the point here.
>
> So let me provide a very simple example.
>
> Today routers already compute CSPF. Moreover today routers are asked to use 
> custom/flexible algorithm to choose reachability paths.
>
> So just imagine an operator who says:
>
> Please compute my SPT with the consideration that end to end inband jitter is 
> not greater then 10 ms otherwise I do not want to see nodes which do not meet 
> that criteria in the reachability graph for application X.
>
> or
>
> Please compute my SPT with the consideration that end to end drop rate is not 
> greater then  5pps otherwise I do not want to see nodes which do not meet 
> that criteria in the reachability graph for application Y.
>
> etc ...
>
> If you consider such constrains to provide reachability for applications you 
> will likely see value that in-situ telemetry is your friend here. Really best 
> friend as without him you can not do the proper end to end path exclusion for 
> SPT computations.
>
> Hint: All per link extensions which were added to IGPs are not going to help 
> here as drops or jitter may equally happen in the routers fabric on fabric to 
> LC boundaries or on the line cards and links. So you need end to end test 
> stream.
>
> Many thx,
> R.
>
> PS. As we are talking LSR here 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,
> > >
> > > 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 5088 
> > > and similar, however should we do it again?
> > >
> > > Specifically to use case described - I really don’t see how this 
> > > information would be used in routing decisions (PCE computation). 
> > > Moreover, if the end-goal is to build a connected graph of the devices 
> > > that have a coherent iFIT feature set it would require reoptimization on 
> > > every change and quite complex computation logic (talking SR - on top of 
> > > regular constrains, MSD, etc).I’d also think that there’s mandatory 
> > > configuration of name-spaces and features supported, in other words - 
> > > autodiscovery is meaningless, it would still require as per device 
> > > configuration (hello YANG). Most of telemetry solutions are designed to 
> > > pass thought nodes that don’t support it transparently, so the real 
> > > requirement is really to know the sink-node (the one that is egress of 
> > > the telemetry domain and must remove all additional encapsulations).
> > >
> > > As to the last point - we already have a kitchen-sink routing protocol  
> > > ;-)
> > >
> > > Cheers,
> > > Jeff
> > > On Apr 2, 2020, 6:10 AM -0700, Robert Raszuk , wrote:
> > > >
> > > > Hi Les,
> > > >
> > > > Ok very well.
> > > >
> > > > So till this draft provides a text or reference to some other document 
> > > > how IGPs may use inband telemetry da

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

[Jeff Tantsura]

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 5088 and 
similar, however should we do it again?

Specifically to use case described - I really don’t see how this information 
would be used in routing decisions (PCE computation). Moreover, if the end-goal 
is to build a connected graph of the devices that have a coherent iFIT feature 
set it would require reoptimization on every change and quite complex 
computation logic (talking SR - on top of regular constrains, MSD, etc).I’d 
also think that there’s mandatory configuration of name-spaces and features 
supported, in other words - autodiscovery is meaningless, it would still 
require as per device configuration (hello YANG). Most of telemetry solutions 
are designed to pass thought nodes that don’t support it transparently, so the 
real requirement is really to know the sink-node (the one that is egress of the 
telemetry domain and must remove all additional encapsulations).

As to the last point - we already have a kitchen-sink routing protocol  ;-)

Cheers,
Jeff
On Apr 2, 2020, 6:10 AM -0700, Robert Raszuk , wrote:
>
> Hi Les,
>
> Ok very well.
>
> So till this draft provides a text or reference to some other document how 
> IGPs may use inband telemetry data for real path selection it does not fit to 
> LSR charter. Fair.
>
> Hi Chris,
>
> I am afraid we are looking at this from completely different perspectives.
>
> I consider this data to be a necessity for routing and you simply treat it as 
> some opaque telemetry. If we would think of it in the latter sense sure you 
> would be right. IGP is not a configuration push protocol. Sufficient to 
> observe how BGP became one :)
>
> Many thx,
> R.
>
>
> > On Thu, Apr 2, 2020 at 8:46 AM Les Ginsberg (ginsberg)  
> > wrote:
> > > Robert -
> > >
> > > First, +1 to what Chris has said.
> > >
> > > There is nothing in the lfit-capability draft that defines any 
> > > information that can be used by IGPs to do what you suggest.
> > > Perhaps it is possible that information gleaned via a telemetry 
> > > application could be used by the IGPs to do something like what you 
> > > suggest - but this draft is not discussing/defining that. It is simply 
> > > proposing to advertise information about the capabilities of the lfit 
> > > application on a given node..
> > >
> > >    Les
> > >
> > > > -Original Message-
> > > > From: Christian Hopps 
> > > > Sent: Thursday, April 02, 2020 5:13 AM
> > > > To: Robert Raszuk 
> > > > Cc: Christian Hopps ; Les Ginsberg (ginsberg)
> > > > ; wangyali ; Acee Lindem
> > > > (acee) ; l...@ietf..org; Tianran Zhou
> > > > 
> > > > Subject: Re: [Lsr] A new version of I-D, 
> > > > draft-liu-lsr-isis-ifit-node-capability-02
> > > >
> > > > We have defined a perfectly acceptable and quite powerful way to do 
> > > > query
> > > > and configuration for routers, it's YANG. I'd like to hear why the the 
> > > > IETF
> > > > standard mechanism for query and configuration can't work for this
> > > > application.
> > > >
> > > > Telemetry is important, I don't think anyone has said or would say that 
> > > > it isn't,
> > > > but that seems orthogonal to this discussion.
> > > >
> > > > Thanks,
> > > > Chris.
> > > > [as WG member]
> > > >
> > > >
> > > > > On Apr 2, 2020, at 5:17 AM, Robert Raszuk  wrote:
> > > > >
> > > > > Hi Les,
> > > > >
> > > > > I would like to respectfully disagree with your assessment.
> > > > >
> > > > > The fact that today's IGP (or for that matter BGP) routing is static 
> > > > > from the
> > > > perspective of not taking into consideration real performance 
> > > > measurements
> > > > from the data plane to me is a bug not a feature.
> > > > >
> > > > > Building SPT based on static link metrics which in vast majority of 
> > > > > cases
> > > > today are emulated circuits on someone else IP backbone. It was a great 
> > > > idea
> > > > when you constructed the network with connection oriented paradigm
> > > > (Sonet,SDH, dark fiber, TDM ...) not connection less often best effort 
> > > > one.
> > > > >
> > > > > So I find this proposal very useful and would vote for adopting it in 
> > > > > LSR WG.
> > > > To me in-situ telemetry is not just some monitoring tool. It is an 
> > > > extremely
> > > > important element to influence how we compute reachability or at least 
> > > > how
> > > > we choose active forwarding paths from protocol RIBs to main RIB.
> > > > >
> > > > > If we extended IGPs to carry TE information, if we extended them to
> > > > enable flexible algorithm based path computation I fail to understand 
> > > > why
> > > > would we resist to natively enable all of the above with getting the 
> > > > inputs
> > > > from real networks to be used as to the parameters to the above 
> > > > me

Re: [Lsr] Methods to label the passive interfaces within ISIS

[Jeff Tantsura]

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 information, it would be sensible to 
> define the use case/requirements.
> Simply having an advertisement that identifies an interface type isn’t 
> sufficient to do anything useful IMO.
>
>    Les
>
> From: Acee Lindem (acee) 
> Sent: Monday, January 13, 2020 8:03 AM
> To: tony...@tony.li; Aijun Wang 
> Cc: Les Ginsberg (ginsberg) ; Robert Raszuk 
> ; lsr@ietf.org
> Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS
>
> Hi Aijun,
> I guess the external use case for this is advertisement in BGP-LS for Network 
> Management purposes?? There really isn’t IS-IS requirement to know whether or 
> not an interface is a passive interface.
> Thanks,
> Acee
>
> From: Lsr  on behalf of Tony Li 
> Date: Monday, January 13, 2020 at 11:00 AM
> To: Aijun Wang 
> Cc: "Les Ginsberg (ginsberg)" , Robert Raszuk 
> , "lsr@ietf.org" 
> Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS
>
>
> Hi Anjun,
>
>
> > Is it reasonable to put the link attribute information into the “IP 
> > Reachability TLV”?
> > IMHO, such stub link is not the normal links within IGP domain.  Label the 
> > related prefix is coming from the passive/stub link seems also acceptable?
>
>
> Well, a passive interface is really configured so that you advertise the 
> interface’s prefix.  Attaching the data that you want to the associated data 
> seems reasonable to me.
>
> There’s no good IS Neighbor advertisement to attach the sub-TLV to because 
> there is no neighbor.
>
> Tony
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv

[Jeff Tantsura]

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 authors already responded during the adoption poll), please 
> indicate your knowledge of any IPR related to this work to the list as well.
>
> Thanks,
> Chris & Acee.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-ketant-lsr-ospf-reverse-metric

[Jeff Tantsura]

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-reverse-metric/
>
> Please indicate your support or objection by Dec 27th.
>
> Authors, please respond indicating whether you are aware of any IPR that 
> applies to this draft.
>
> Thanks,
> Chris & Acee.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-ketant-lsr-ospf-bfd-strict-mode

[Jeff Tantsura]

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 support or objection by Dec 27th.
>
> Authors, please respond indicating whether you are aware of any IPR that 
> applies to this draft.
>
> Thanks,
> Chris & Acee.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] "YANG Module for IS-IS Reverse Metric" - draft-hopps-lsr-yang-isis-reverse-metric-02

[Jeff Tantsura]

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 objection to adoption to the LSR list 
> (lsr@ietf.org) prior to 12:00 AM UTC on December 10th, 2019.
>  
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption poll for draft-acee-lsr-ospf-yang-augmentation-v1-01

[Jeff Tantsura]

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 comments to the list by Wednesday Oct 16th, 2019.
>
> Thanks,
> Chris.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for draft-acee-lsr-ospfv3-extended-lsa-yang-06

[Jeff Tantsura]

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, 2019.
>
> Thanks,
> Chris.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using ISIS" - draft-ietf-isis-mpls-elc-07

[Jeff Tantsura]

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 Entropy Readable Label-stack Depth Using ISIS" - 
> draft-ietf-isis-mpls-elc-07
>  
> We’ve gone through a number of iterations with these ELC drafts and I believe 
> they are ready and meets all the use case requirements. Note that “Entropy 
> Label for Spring tunnels” – draft-ietf-mpls-spring-entropy-label-12 is on the 
> RFC editor’s queue.  
> 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 Sept 14th, 2014. 
> Also, review comments are certainly welcome.
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

[Jeff Tantsura]

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 and Entropy Readable Label-stack Depth Using OSPF" - 
> draft-ietf-ospf-mpls-elc-08
>  
> We’ve gone through a number of iterations with these ELC drafts and I believe 
> they are ready and meets all the use case requirements. Note that “Entropy 
> Label for Spring tunnels” – draft-ietf-mpls-spring-entropy-label-12 is on the 
> RFC editor’s queue.  
> 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 Sept 14th, 2014.
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ietf-isis-mpls-elc-07

[Jeff Tantsura]

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 can’t envision all the trade-offs but I certainly don’t see much 
> risk in continuing with the ERLD as this has been in the drafts for some time.
>  
> All,
>  
> I’d like to Working Group Last Call these drafts as I believe they are ready 
> and we even have some implementation momentum. Anyone disagree?
>  
> Thanks,
> Acee
>  
> From: "Les Ginsberg (ginsberg)" 
> Date: Wednesday, August 28, 2019 at 4:59 PM
> To: Acee Lindem , Uma Chunduri , 
> "lsr@ietf.org" 
> Subject: RE: [Lsr] draft-ietf-isis-mpls-elc-07
>  
> Point taken…
>  
>   Les
>  
> From: Acee Lindem (acee)  
> Sent: Wednesday, August 28, 2019 1:56 PM
> To: Les Ginsberg (ginsberg) ; Uma Chunduri 
> ; lsr@ietf.org
> Subject: Re: [Lsr] draft-ietf-isis-mpls-elc-07
>  
> Les,
>  
> Then what you meant in your response was, “generic RLD” as opposed to 
> “generic MSD”.
>  
> Thanks,
> Acee
>  
>  
>  
>  
> From: "Les Ginsberg (ginsberg)" 
> Date: Wednesday, August 28, 2019 at 4:46 PM
> To: Acee Lindem , Uma Chunduri , 
> "lsr@ietf.org" 
> Subject: RE: [Lsr] draft-ietf-isis-mpls-elc-07
>  
> Acee –
>  
> I do understand the question – and I believe the reference I cited provides 
> the answer. You need to read the referenced draft.
>  
> If you have a cogent argument why it is safe to assume that the combination 
> of actions required to support EL translate to any other type of activity 
> that might be required on a label stack, please make it. Then Uma’s 
> suggestion might make sense.
>  
>Les
>  
> From: Acee Lindem (acee)  
> Sent: Wednesday, August 28, 2019 1:34 PM
> To: Les Ginsberg (ginsberg) ; Uma Chunduri 
> ; lsr@ietf.org
> Subject: Re: [Lsr] draft-ietf-isis-mpls-elc-07
>  
> Hi Les,
> I think the question is whether there can be a single RLD depth MSD rather 
> than a RLD solely for entropy label discovery.
> Thanks,
> Acee
>  
> From: Lsr  on behalf of "Les Ginsberg (ginsberg)" 
> 
> Date: Wednesday, August 28, 2019 at 4:29 PM
> To: Uma Chunduri , "lsr@ietf.org" 
> Subject: Re: [Lsr] draft-ietf-isis-mpls-elc-07
>  
> Uma –
>  
> Please read 
> https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-12#section-4
>  
> In short, we do not assume that EL Load Balancing can be performed for 
> generic MSD.
>  
> Thanx.
>  
>Les
>  
>  
> From: Lsr  On Behalf Of Uma Chunduri
> Sent: Wednesday, August 28, 2019 11:38 AM
> To: lsr@ietf.org
> Subject: [Lsr] draft-ietf-isis-mpls-elc-07
>  
> Can anybody tell what was the conclusion (if any) in previous discussions in 
> various WGs on why the readable label depth in an LSR has to be entropy label 
> specific ?
>  
> IOW can we just modify this as “readable label depth” as opposed to “entropy 
> readable label depth” ?
> This would allow any other special purpose label inserted in the stack and 
> would be at par with current MSD type “Base MPLS Imposition MSD” ( 
> https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml )..
>  
>  
> --
> Uma C.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

[Jeff Tantsura]

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 !
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

[Jeff Tantsura]

+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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Regd covering BGP-LS extensions for IGP ELC drafts

[Jeff Tantsura]

+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://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/
> https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/
>
> Originally, these IGP drafts introduced a new node capability that required a 
> new BGP-LS TLV and this was captured in the IDR WG document 
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/
>
> However after the discussion in the LSR WG over the last few months, the 
> approach has changed such that the IGP signalling is being done by 
> introduction of new flags and MSD-type. This makes the corresponding BGP-LS 
> updates quite trivial and as discussed in the LSR WG, I would recommend to 
> add some text (proposed below) to the two IGP documents.
>
> OSPF:
> The OSPF extensions defined in this document can be advertised via BGP-LS 
> [RFC7752] using existing BGP-LS TLVs. The flags field of the OSPFv2 Extended 
> Prefix TLV and the OSPFv3 PrefixOptions where the ELC Flag introduced in this 
> document is advertised using the Prefix Attribute Flags TLV (TLV 1170) of the 
> BGP-LS IPv4/IPv6 Prefix NLRI Attribute 
> [https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.3.2].
>  The new ERLD MSD-type introduced for OSPF by this document is advertised 
> using the Node MSD TLV (TLV 266) of BGP-LS Node NLRI Attribute 
> [https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-05#section-3].
>
> ISIS:
> The IS-IS extensions defined in this document can be advertised via BGP-LS 
> [RFC7752] using existing BGP-LS TLVs. The Prefix Attribute Flags sub-TLV 
> where the ELC Flag is introduced in this document is advertised using the 
> Prefix Attribute Flags TLV (TLV 1170) of the BGP-LS IPv4/IPv6 Prefix NLRI 
> Attribute 
> [https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.3.2].
>  The new ERLD MSD-type introduced for IS-IS by this document is advertised 
> using the Node MSD TLV (TLV 266) of BGP-LS Node NLRI Attribute 
> [https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-05#section-3].
>
> I am copying the IDR WG and authors of the BGP-LS ERLD draft as well for 
> their inputs/feedback.
>
> Thanks,
> Ketan
>
> From: Lsr  On Behalf Of Acee Lindem (acee)
> Sent: 25 July 2019 16:28
> To: lsr@ietf.org
> Subject: [Lsr] IETF 105 LSR Working Group Meeting Minutes
>
> I think we had some very good discussions in our sessions this week. I’ve 
> uploaded the minutes for the both LSR sessions on Monday. Thanks much to 
> Yingzhen Qu for taking them.
>
> https://datatracker.ietf.org/meeting/105/materials/minutes-105-lsr-00
>
> Thanks,
> Acee
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

[Jeff Tantsura]

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 PM -0400, Ketan Talaulikar (ketant) , 
wrote:
> Hi Albert,
>
> Thanks for your feedback from an operator perspective – it is valuable. This 
> “BFD hold up” behaviour that you desire is best handled by BFD since I would 
> expect that similar behaviour would be desired across routing protocols 
> (OSPF, ISIS, BGP) and perhaps other clients.
>
> IMHO this is not something that we should be tackling within the scope of 
> this BGP draft. Would you agree?
>
> That said, this seems like a local implementation aspect to me. We should 
> however discuss within the BFD WG if there is value in documenting this.
>
> Thanks,
> Ketan
>
> From: Idr  On Behalf Of Susan Hares
> Sent: 25 July 2019 16:21
> To: 'Albert Fu' ; i...@ietf.org
> Subject: Re: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode
>
> Albert:
>
> To clarify, do you support WG adoption with the draft as is.
>
> As a WG chair, I have to trust that all  drafts are improved during the WG 
> process.  Can this small change be made after adoption or should it be made 
> before the draft is considered for adoption.
>
> Sue Hares
>
> From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Albert Fu (BLOOMBERG/ 
> 120 PARK)
> Sent: Thursday, July 25, 2019 4:19 PM
> To: i...@ietf.org
> Subject: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode
>
> I am in support of this draft, and would like to request a small change to 
> make this draft more operationally useful.
>
> We have encountered several traffic blackhole problems in our production 
> network without this feature. As such, we have deployed BGP with strict BFD 
> mode on a proprietary vendor implementation for a while.
>
> Since a lot of MetroE circuit failures occur with interfaces still up, ie. 
> break in the middle issues, the traditional knobs like interface 
> hold-time/debounce timer can not be used to dampen interface flaps.
>
> We have observed that interface issues tend to occur in bursts and would like 
> to request that an option be added in "Section 4 Operation:" to delay BGP 
> from coming up until BFD is proven stable continuously for a period of time 
> (i.e. BFD hold up feature).
>
> This is a feature that we are currently using in the proprietary vendor 
> deployment. In our case, since we have multiple redundant paths, we have some 
> links where we delay BGP from coming up until BFD has been stable 
> continuously for 60 seconds.
>
> Thanks
> Albert Fu
> Bloomberg
> >
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call: draft-ginsberg-lsr-isis-invalid-tlv

[Jeff Tantsura]

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.
> 
> Authors: Please indicate your knowledge of any IPR related to this work
> to the list as well.
> 
> Thanks,
> Chris & Acee.
> 
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Adjacency SID and Passive Interface

[Jeff Tantsura]

+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 a passive link separately (somewhat on 
> lines of what was done for inter-AS TE) so that it does not get mixed up with 
> the classical IGP links. I would think a new draft would be apt for such an 
> extension.
> 
> Thanks,
> Ketan
> 
> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem (acee)
> Sent: 10 May 2019 17:39
> To: Christian Franke ; 
> olivier.dug...@orange.com; SPRING ; LSR 
> Subject: Re: [Lsr] Adjacency SID and Passive Interface
> 
> Hi Chris, Olivier, 
> 
> On 5/10/19, 4:41 AM, "Lsr on behalf of Christian Franke" 
>  wrote:
> 
>>On 5/10/19 9:58 AM, olivier.dug...@orange.com wrote:
>> In the current state of Segment Routing drafts, do you think it is possible 
>> to advertise
>> Adjacency SID on such passive or inter-domain interfaces or do we need to 
>> specify this behaviour
>> in a new draft ?
>> 
>> For me I don't see anything in the drafts that prohibits this kind of 
>> advertisement, but perhaps I'm wrong.
> 
>My understanding is that the SID is specific to an adjacency and
>advertised in IS-IS in either TLV 22, 222, 23, 223.
> 
>As adjacencies will not be formed on a passive interface, an adjacency
>SID should not be advertised for the passive interface.
> 
> I agree with Chris. We shouldn't reuse the existing Adj-SID when there will 
> never be an adjacency and the current semantics require this. If we need 
> advertisement of SIDs for passive interfaces, it would definitely be a new 
> draft that clearly articulates the use case and designates a new type of SID 
> that has different semantics. Also note that while passive interfaces are 
> very useful in order to include a stub network in the topologies, they are 
> not part of the OSPF specifications. I haven't done an exhaustive search on 
> IS-IS. 
> 
> Thanks,
> Acee
> 
> 
>I might also be wrong here, though.
> 
>All Best,
>Chris
> 
>___
>Lsr mailing list
>Lsr@ietf.org
>https://www.ietf.org/mailman/listinfo/lsr
> 
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IPR Poll for "IS-IS Extensions to Support Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

[Jeff Tantsura]

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 at 10:23 AM
> To: "draft-bashandy-isis-srv6-extensi...@ietf.org" 
> 
> Cc: "lsr@ietf.org" 
> Subject: IPR Poll for "IS-IS Extensions to Support Routing over IPv6 
> Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt
>  
> Authors,
>  
> Are you aware of any IPR that applies to 
> draft-bashandy-isis-srv6-extensions-05.txt?
>  
> If so, has this IPR been disclosed in compliance with IETF IPR rules 
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
>  
> If you are listed as a document author or contributor please respond
> to this email regardless of whether or not you are aware of any
> relevant IPR. *The response needs to be sent to the LSR WG mailing
> list.* The document will not advance to the next stage until a
> response has been received from each author and contributor.
>  
> If you are on the LSR WG email list but are not listed as an author or
> contributor, then please explicitly respond only if you are aware of
> any IPR that has not yet been disclosed in conformance with IETF rules.
>  
> Thanks,
> Acee
>  
>  
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt

[Jeff Tantsura]

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 by the drafts:
> 
> 1)Support of incongruent topologies for different applications
> 
> 2)Advertisement of application specific values even on links that are in
> use by multiple applications
> 
> These issues are clearly articulated in the Introductions of both
> drafts. LSR WG acknowledged them a while back and decided to address
> them.
> 
> Issue #1 has already had a significant impact on early deployments of
> SRTE in networks where there is partial deployment of SR in the presence
> of RSVP-TE.
> 
> Issue #2 will be seen in deployments where Flex-Algo and SRTE (or
> RSVP-TE) are also present. Early implementers of Flex-Algo can attest to
> this.
> 
> It is simply not possible to address these issues with the existing
> single set of application independent advertisements.
> 
> The solutions we provide in both drafts allow to share the link
> attributes between application as well as keep them separate if that is
> what is required.
> 
> thanks,
> Peter
> 
>> On 11/04/2019 19:43 , olivier.dug...@orange.com wrote:
>> Hi,
>> 
>> I'm not in favour of this draft.
>> 
>> As already mention, I don't see the interest to duplicate TE attributes
>> in new Extended Link Opaque LSA. For me, it is only a matter of
>> implementation to look at various place in the OSPF TE Database to take
>> Traffic Engineering information.
>> 
>> From an operator perspective, it is already hard to manage TE attribute
>> and I'm pretty sure that we could not ask network management team to
>> maintain 2 systems for certainly a long period of time as many TE
>> attributes remains in the standard Opaque LSA Traffic Engineering.
>> 
>> Regards
>> 
>> Olivier
>> 
>> 
>>> Le 11/04/2019 à 18:11, Acee Lindem (acee) a écrit :
>>> 
>>> 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 Friday, April 27^th , 2019.
>>> 
>>> 
>>> 
>>> Thanks,
>>> Acee
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
>> 
>> _
>> 
>> Ce message et ses pieces jointes peuvent contenir des informations 
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
>> ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
>> electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
>> falsifie. Merci.
>> 
>> This message and its attachments may contain confidential or privileged 
>> information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and 
>> delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been 
>> modified, changed or falsified.
>> Thank you.
>> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IPR Poll for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt

[Jeff Tantsura]

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 compliance with IETF IPR rules 
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
>  
> If you are listed as a document author or contributor please respond
> to this email regardless of whether or not you are aware of any
> relevant IPR. *The response needs to be sent to the LSR WG mailing
> list.* The document will not advance to the next stage until a
> response has been received from each author and contributor.
>  
> If you are on the LSR WG email list but are not listed as an author or
> contributor, then please explicitly respond only if you are aware of
> any IPR that has not yet been disclosed in conformance with IETF rules.
>  
> Thanks,
> Acee 
>  
>  
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "IS-IS TE Attributes per application" - draft-ietf-isis-te-app-06.txt (Corrected Author Alias)

[Jeff Tantsura]

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.
>  
> Thanks,
> Acee 
>  
>  
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Flooding Path Direction

[Jeff Tantsura]

+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 careful about thus far is to not 
> change the operation of the Update process on a given link.
> We allow links to be excluded from the FT but we do not change flooding 
> behavior on a link when it is part of the FT.
> We have also gone so far as to indicate that even if a link is NOT part of 
> the FT but we do receive an LSP on that link we acknowledge it in the 
> standard fashion.
>
> I think all of this simplifies the deployment of the feature and we should be 
> careful before introducing additional changes in standard protocol behavior.
>
> Les
>
>
> > -Original Message-
> > From: Lsr  On Behalf Of tony...@tony.li
> > Sent: Thursday, April 04, 2019 10:04 AM
> > To: David Allan I 
> > Cc: lsr@ietf.org; Jakob Heitz (jheitz) ; Peter Psenak
> > (ppsenak) 
> > Subject: Re: [Lsr] Flooding Path Direction
> >
> >
> > Hi Dave,
> >
> > > The algorithm in draft-allan actually has the notion of upstream,
> > downstream
> > > and both upstream and downstream FT adjacencies. However as a
> > generalized
> > > form is still a WIP and has yet to demonstrate merit against any of the
> > > other approaches on the table, I'd not be looking to suggest a specific
> > > encoding.
> >
> >
> > Thanks.
> >
> >
> > > If at some point it is decided that different classes of FT adjacency are
> > > required, simply using additional types that share the format of the
> > > flooding path TLV would appear to be sufficient(?)
> >
> > Or perhaps having a separate TLV for a unidirectional path would suffice.
> >
> > That would allow both paths to be encoded most optimally.
> >
> > Tony
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call for "Restart Signaling for IS-IS" - draft-ietf-lsr-isis-rfc5306bis-01

[Jeff Tantsura]

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, 2019.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Temporary addition of links to flooding topology in dynamic flooding

[Jeff Tantsura]

+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,
Jeff

> On Mar 11, 2019, at 21:28, Les Ginsberg (ginsberg)  wrote:
> 
> Robert –
>  
> I don’t think the word “random” is applicable.
>  
> Section 6.7.11 states (emphasis added):
>  
> “In the unlikely event of multiple failures on the flooding topology,
>it may become partitioned.  The nodes that remain active on the edges
>of the flooding topology partitions will recognize this and will try
>to repair the flooding topology locally by enabling temporary
>flooding towards the nodes that they consider disconnected from the
>flooding topology until a new flooding topology becomes connected
>again.”
>  
> This isn’t a case of every node in the network trying to decide how to repair 
> the partition. It is only the nodes at the edge(s) of the partition doing so. 
> I do not see this as “random”.
>  
> What is being debated on the list is not related to randomness – it is the 
> degree of temporary flooding along the continuum from “minimal” (one 
> additional edge) to “maximal” (all edges to nodes which are seen as currently 
> disconnected). The former risks longer convergence – the latter risks 
> temporary flooding storms. But neither approach is random. Once the failures 
> are known, the set of candidates is predictable.
>  
> The concept of LFA also isn’t applicable here.  LFA (if we use the term in 
> this case to mean a precalculated set of temporary flooding edges) is useful 
> when it can be preinstalled in the forwarding plane, allowing a node to 
> eliminate waiting for control plane intervention when a local failure is 
> detected.
> But LSP/LSA flooding is always done by the control plane – so having a 
> precalculated LFA wouldn’t produce a faster response time. If you are going 
> to suggest that the calculation required to determine a flooding topology 
> partition is itself costly I think this is not supported by current SPF 
> calculation times. In addition, given temporary flooding is normally only 
> required in the event of multiple failures, the combinations required to be 
> supported in order to have a useful set of pre-calculated temporary flooding 
> edges becomes quite large – which makes such an approach impractical.
>  
>Les
>  
>  
> From: Lsr  On Behalf Of Robert Raszuk
> Sent: Monday, March 11, 2019 2:28 PM
> To: lsr@ietf.org
> Subject: [Lsr] Temporary addition of links to flooding topology in dynamic 
> flooding
>  
> Hi,
>  
> As of now at the event of failure of any of the FT enabled link additional 
> links are being added in more or less random fashion by nodes directly 
> connected to the failed links. 
>  
> In the event of 100s of links on such nodes and advisable rate limiting 
> addition of those links it seems that repair of FT may take some time. 
>  
> In order to reduce such time interval better then random addition of 
> remaining links seems recommended. How about we hint participating nodes to 
> execute purely in control plane of FT an LFA algorithm for possible future 
> event of active link failure and use results of the LFA computation to 
> prioritize links which will be first temporary additions upon active flooding 
> links failures ? 
>  
> Such optimization is local and optional and does not require any changes to 
> proposed protocol signalling. 
>  
> Therefor how about just one sentence addition to section 6.7.1 of 
> draft-ietf-lsr-dynamic-flooding:
>  
> Temporary additions of links to flooding topology could be more educated if 
> given node runs a pure control plane LFA ahead of any FT failure on active FT 
> links completely detached from potential LFA runs for data plane topology. 
>  
> Kind regards,
> R.
>  
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

[Jeff Tantsura]

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 information. It does not standardize any 
> specific algorithm for flooding topology creation.
>
> Authors please respond indicating if you are aware of any IPR related to this 
> work.
>
> We also have another draft (draft-cc-lsr-flooding-reduction-01) that started 
> as a distributed flooding topology algorithm and morphed into that plus 
> competing ideas on signaling of flooding topology information. The intent 
> after adoption of draft-li-lsr-dynamic-flooding-02 is two-fold. One, the WG 
> can discuss adding any signaling ideas from this work to the adopted 
> signaling draft (with proper attribution given as appropriate), and two, for 
> the authors of draft-cc-lsr-flooding-reduction-01 to publish a new document 
> without the signaling portion and instead focus on their flooding topology 
> algorithm. This new focused document can be considered in parallel along with 
> the other algorithm work that has been proposed.
>
> Flooding topology creation is seen as a hard problem for which we don't 
> expect a one-size-fits-all solution. Taking the steps outlined above will 
> help us move forward on the solutions.
>
> Thanks,
> Chris & Acee.
> LSR WG Chairs.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

[Jeff Tantsura]

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
>> Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
>> 
>> 
>> Summary of where we are at with dynamic flooding reduction:
>> 
>> - We have a well written original work that came first and described the
>> problems as well as a TLVs to allow for a centralized solution (draft-li-
>> dyanmic-flooding). We do not need to standardize the centralized algorithm.
>> 
>> - A small change to this work allowed for distributed algorithms and for
>> outside work on distributed algorithms to continue in parallel.
>> 
>> - We have another original work that started primarily as a distributed
>> algorithm
>>   (draft-cc-ospf-flooding-reduction)
>> 
>> - Finally we also have:
>>   - Cross-pollination of ideas.
>>   - Failed attempts at merging.
>>   - An authors list "Arms-Race".
>> 
>> Moving forward:
>> 
>> - During IETF 103 I proposed we have no conflict if we:
>> 
>>   1) adopt draft-li-lsr-dyanmic-flooding as the base WG document.
>>   2) have authors of draft-cc-lsr-flooding-reduction work on a distributed
>> algorithm as they started with.
>> 
>> - Acee agreed during the meeting (as chair) that this was the best way
>> forward. We had some agreement form the floor as well.
>> 
>> - Any good ideas regarding the distribution of a centralized topology can be
>> debated and added (with appropriate attribution) to the base document
>> after we adopt one.
>> 
>> - This is what happens when we adopt a document as WG work, we work on
>> it.
>> 
>> - The original authors of the distributed solution can continue to work on
>> their distributed algorithm in a separate document which would also need
>> standardization.
>> 
>> Does anyone see a serious problem with this path forward?
>> 
>> Thanks,
>> Chris & Acee.
>> LSR Chairs.
>> 
>> Christian Hopps  writes:
>> 
>>> We've had the authors of the individual conflicting drafts take a shot at
>> merging their work.
>>> 
>>>   This has failed.
>>> 
>>> Here is the full history (which I also summarized during IETF103 as well). I
>> will send a second email discussing this.
>>> 
>>> - Jan 2, 2018 Publication: draft-li-dynamic-flooding and drfat-li-dynamic-
>> flooding-isis
>>>  published centralized solution.
>>> 
>>> - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and 
>>> draft-cc-ospf-
>> flooding-reduction
>>>  published distributed solution.
>>>  - mention of centralized solution asserting it is not good choice.
>>> 
>>> - IETF 101 (Mar 2018)
>>>  - Video:
>> https://www.youtube.com/watch?v=qHmT4ytMn4w&list=PLC86T-
>> 6ZTP5j_HaBNdfPbgxGIp22cnaWS
>>>  - Minutes: https://datatracker.ietf.org/meeting/101/materials/minutes-
>> 101-lsr-00
>>>  - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101
>>>- Generally well received.
>>>  - draft-cc-ospf-flooding-reduction-00 (4 authors) presented.
>>>- Serious problems immediately found during presentation -- not fully
>> baked.
>>> 
>>> - Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author)
>>> - Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author)
>>> - Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised
>>> - Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors)
>>>  - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*.
>>>  - Does not specify distributed algorithm only how to indicate one in use,
>> small change.
>>> 
>>> - Jul 2, 2018 draft-cc-ospf-flooding-reduction-02 published
>>> 
>>> - IETF 102 (Jul 14, 2018)
>>>  - draft-li-dynamic-flooding-05 presented.
>>>  - draft-cc-ospf-flooding-reduction-02 presented.
>>> 
>>> - Sep 12, 2018 draft-cc-ospf-flooding-reduction-03 (4 authors)
>>>  - *LARGE CHANGE ADDS NEW CENTRALIZED SOLUTION*.
>>> 
>>> - Sep 20, 2018 draft-cc-ospf-flooding-reduction-04 (4 authors)
>>> 
>>> - Oct 21, 2018 draft-li-lsr-dynamic-flooding-00 and -01 (5 authors)
>>> 
>>> - IETF 103 (Nov 3, 2018)
>>> 
>>>  - Chairs give direction
>>> 
>>>- draft-li-lsr-dynamic-flooding-05 having come first, being well written
>> and not
>>>  specifying a distributed algorithm (merely allowing for one) is the 
>>> correct
>> vehicle
>>>  to adopt as a base document.
>>> 
>>>- Distributed algorithm work (the original basis for 
>>> draft-cc-ospf-flooding-
>> reduction)
>>>  should continue as a separate document form the base which would
>> thus we have no
>>>  conflicts.
>>> 
>>> - In the meantime the authors try and merge work, this fails.
>>> 
>>> - Dec 3, 2018 draft-li-lsr-dynamic-flooding-02 (7 authors)
>>> 
>>> - Dec 10, 2018 draft-cc-lsr-flooding-reduction-00 (4 authors)
>>> 
>>> - Jan 7, 2019  draft-cc-lsr-flooding-reduction-01 (8 authors)
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> htt

Re: [Lsr] WG Adoption Call for "IS-IS Routing for Spine-Leaf Topology" - draft-shen-isis-spine-leaf-ext-07

[Jeff Tantsura]

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-IS extension doesn’t 
> really conflict with any of the other more disruptive flooding proposals. 
> Also, it is more mature and there is some implementation momentum. Note that 
> I’m making every attempt to be transparent and it is perfectly ok to disagree 
> with me. Please post your comments to this list before 12:00 AM, December 
> 16th, 2018.
>  
> With respect to the more disruptive proposals, we are discussing our next 
> steps.
>  
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-isis-rfc5306bis-00 - Restart Signaling for IS-IS

[Jeff Tantsura]

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 than some RFC boiler plate changes, the RFC 5306 BIS document really 
> only adds the PR/PA bit handling in section 2.2.3 and the addition of the 
> Planned Restart State to sections 3.1 and 3.2.
>  
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR: Using DSCP for path/topology selection Q

[Jeff Tantsura]

Robert,

match DSCP X
set context Y or plane Z doesn’t make it any different.
It has been used and abused in any possible way. If you want to write a BCP
saying - use it for X/Y/Z but not for A/B/C because of - your business.

As to using it someplace else - I’d expect respective documents to cover
the use, flex-algo drafts as to your example.

More fundamentally, (flex-algo is the best example) we have got context
aware metadata in a form of: MPLS labels (SR SID), v6 EHs, plethora of
overlay encaps, etc, with accompanying CP extensions that can be used to
achieve exactly that.

Now tell me - why again DSCP?

P.S. in my previous life, working on 5G transport slicing (yes, i know :))
- i needed per slice identity over the common transport, we ended up
looking at UDP port ranges, rather than DSCP - too few bits

Cheers,
Jeff
On Thu, Nov 15, 2018 at 23:37 Robert Raszuk  wrote:

> Jeff,
>
> > What architecture?
> > PBR is a form of:
> > match DSCP X
> > set next-hop Y
> > needs no interoperability...
>
> That's pretty narrow view. I could say the worst possible example :)  You
> would have to either encapsulate or apply your 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 
> wrote:
>
>> Tony,
>>
>> What architecture?
>> PBR is a form of:
>> match DSCP X
>> set next-hop Y
>> needs no interoperability...
>> If someone wants to describe how they use a particular vendor feature to
>> solve a particular problem in a BCP, sure, the more BCPs - the better.
>>
>> Wrt using DSCP in routing decision process - it was 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 here to standardize?
>>>
>>>
>>>
>>> There’s a fine architectural BCP here: this is how we are solving
>>> problem XYZ.  Please don’t break this.
>>>
>>> Tony
>>>
>>>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR: Using DSCP for path/topology selection Q

[Jeff Tantsura]

Tony,

What architecture?
PBR is a form of:
match DSCP X
set next-hop Y
needs no interoperability...
If someone wants to describe how they use a particular vendor feature to
solve a particular problem in a BCP, sure, the more BCPs - the better.

Wrt using DSCP in routing decision process - it was 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 here to standardize?
>
>
>
> There’s a fine architectural BCP here: this is how we are solving problem
> XYZ.  Please don’t break this.
>
> Tony
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR: Using DSCP for path/topology selection Q

[Jeff Tantsura]

+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 
details, not standardization.

Am I missing something?


Regards,
Jeff

> On Nov 16, 2018, at 07:47, Rob Shakir  wrote:
> 
>> On Thu, 15 Nov 2018 at 16:07 Toerless Eckert  wrote:
>> > And btw I read Peter's note as possibility (or invitation) to define
>> > algorithm which takes into account DSCP rather then a announcement that
>> > this is not there and it should never be.
>> 
>> Sure, i am only talking about the solutions that tried to use DSCP for
>> routing so far. I think those failed. And when other agree and we codify
>> that, then that would not exclude the option for new work (like what
>> Peter may have in mind) to superceed that recommendation. 
> 
> A number of networks on which I have worked have used DSCP-based tunnel 
> selection to choose between RSVP-TE LSPs. This essentially is different 
> routing based on DSCP, which seems to be something that you're trying to 
> cover -- is that correct?
> 
> If so, given that these are running in real networks, I find it hard to 
> conclude that any IETF standard should declare them as failed.
> 
> r.
> 
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for IGP extension for PCEP security capability support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00

[Jeff Tantsura]

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
> capability support in the PCE discovery -
> draft-wu-lsr-pce-discovery-security-support-00
>
>
>
> At the LSR WG meeting in Bangkok, there was general agreement that we
> should adopt this draft given that the PCE WG believes it is useful. Please
> indicate your support or objection prior to 12:00 AM UT, Wednesday November
> 26th, 2018. Note the authors may refresh the draft to address some
> comments prior to that time.
>
>
>
>
>
> Thanks,
>
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt

[Jeff Tantsura]

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 behalf of Acee Lindem 
> Date: Monday, October 22, 2018 at 6:25 PM
> To: "lsr@ietf.org" 
> Subject: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering 
> Tunnels - draft-ietf-ospf-xaf-te-04.txt
>
> This begins an LSR WG last call for the subject draft. Please send your 
> comments to this list prior to 12:00 AM GMT, November 13th , 2018. While its 
> only an 8 page document, I added an extra week due to the IETF. Please let me 
> know if anyone needs any more time.
>
> https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr