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] 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] [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] [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] 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] 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 "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] 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] 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-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] 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] 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-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] 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

[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] [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] 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] 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 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] 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]

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]

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-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] 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] 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 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] 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] [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] 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] 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]

+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] [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]

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] 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] 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]

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]

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]

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]

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 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 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] [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] 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] 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] 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] 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] 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] 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] "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] "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] 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] 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]

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] 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] FW: New Version Notification for draft-ginsberg-isis-rfc7810bis-00.txt

[Jeff Tantsura]

+1

 

I’d think the below would work:

lsr for #2

lsr-ospf(ospfv3) / lsr-isis for #1 

 

Cheers,

Jeff

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Wednesday, April 4, 2018 at 13:27
To: Tony Li , "Les Ginsberg (ginsberg)" 
Cc: "lsr@ietf.org" 
Subject: Re: [Lsr] FW: New Version Notification for 
draft-ginsberg-isis-rfc7810bis-00.txt

 

I think the WG name should be in the expected place in the file name. I seem to 
remember some drafts with -bgp- rather than -idr- that flew under the radar for 
a while. 

Thanks,
Acee

 

From: Tony Li 
Date: Wednesday, April 4, 2018 at 4:03 PM
To: "Les Ginsberg (ginsberg)" 
Cc: Acee Lindem , "lsr@ietf.org" 
Subject: Re: [Lsr] FW: New Version Notification for 
draft-ginsberg-isis-rfc7810bis-00.txt

 

 

I don’t see the big deal in having the WG name in the draft title, even for 
category 1 documents.

 

It’s only the name of the draft and the fact that it is protocol specific 
doesn’t really need to be called out at that level.  People who read the 
document will certainly figure it out.

 

Tony

 

 

On Wed, Apr 4, 2018 at 12:39 PM Les Ginsberg (ginsberg)  
wrote:

Well...this raises a topic on which I would like to have feedback from the WG.

Combining IS-IS/OSPF into one working group is fine - no argument there.
But, we now may be producing two classes of documents:

1)Documents which are specific to a protocol (IS-IS or OSPFv2 or OSPFv3)

2)Documents which cover 2 or more protocols

draft-ginsberg-isis-rfc7810bis-00.txt is Category #1 - and there is NO CHANCE 
this document will EVER cover OSPF - since OSPF already has RFC 7471 and this 
bis document is a correction to the IS-IS specific RFC7810. Calling it "-lsr-" 
to me is simply confusing as it in no way indicates that it is IS-IS specific.
I suggest that any document which falls into Category 1 should continue to 
follow the traditional protocol specific naming.
If this somehow violates some IETF rule then I suppose we could use 
"-lsr-isis-". (somewhat verbose)

For Category 2 documents "-lsr-" certainly makes sense.

Comments??

   Les


> -Original Message-
> From: Acee Lindem (acee)
> Sent: Tuesday, April 03, 2018 7:45 AM
> To: Les Ginsberg (ginsberg) ; lsr@ietf.org
> Subject: Re: [Lsr] FW: New Version Notification for draft-ginsberg-isis-
> rfc7810bis-00.txt
>
> Hi Les,
>
> Can you resubmit as draft-ginsberg-lsr-rfc7810bis-00.txt? Also, please add a
> "Changes from RFC 7810" section to the "Introduction". I see you have added
> RFC8174 to the "Requirements Language" section already.
>
> I think we should accept this as an LSR Working Group document - does
> anyone disagree?
>
> Thanks,
> Acee
>
> On 3/30/18, 6:39 PM, "Lsr on behalf of Les Ginsberg (ginsberg)"  boun...@ietf.org on behalf of ginsb...@cisco.com> wrote:
>
> Folks -
>
> A bis version of RFC 7810 has been submitted to address the issue reported
> in Errata ID: 5293 https://www.rfc-editor.org/errata_search.php?rfc=7810
>
> Given that there exist implementations which have interpreted the
> ambiguous encoding of some sub-TLVs in different/non-interoperable ways
> it was felt that a bis version of the RFC was justified.
> Please see the Appendix of the draft for a discussion of the changes from
> RFC 7810 and the reasons why.
>
>Les
>
>
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Friday, March 30, 2018 3:33 PM
> To: Qin Wu ; David Ward (wardd)
> ; Spencer Giacolone ;
> Spencer Giacalone ; John Drake
> ; Les Ginsberg (ginsberg) ; David
> Ward (wardd) ; Stefano Previdi 
> Subject: New Version Notification for 
> draft-ginsberg-isis-rfc7810bis-00.txt
>
>
> A new version of I-D, draft-ginsberg-isis-rfc7810bis-00.txt
> has been successfully submitted by Les Ginsberg and posted to the IETF
> repository.
>
> Name: draft-ginsberg-isis-rfc7810bis
> Revision: 00
> Title:IS-IS Traffic Engineering (TE) Metric Extensions
> Document date:2018-03-30
> Group:Individual Submission
> Pages:19
> URL:https://www.ietf.org/internet-drafts/draft-ginsberg-isis-
> rfc7810bis-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ginsberg-isis-rfc7810bis/
> Htmlized:   
> https://tools.ietf.org/html/draft-ginsberg-isis-rfc7810bis-00
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-ginsberg-isis-
> rfc7810bis
>
>
> Abstract:
>In certain networks, such as, but not limited to, financial
>information networks (e.g., stock market data providers), network-
>performance criteria (e.g., latency) are becoming as critical to
>data-path selection as other metrics.
>
>This document describes extensions to IS-IS Traffic Engineering
>Extensions (RFC 5305) such that network-performance information can
>be distributed and collected in a scalable fashion.  The information
>distributed using IS-I

Re: [Lsr] LSR WG IPR Query for "Signaling MSD (Maximum SID Depth) using OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

[Jeff Tantsura]

Hi Acee,

 

I’m aware of the IPR and it has been disclosed in compliance with IETF IPR 
rules.

https://datatracker.ietf.org/ipr/3040/

 

Thanks!

Cheers,

Jeff

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Thursday, April 5, 2018 at 18:22
To: "draft-ietf-ospf-segment-routing-msd...@ietf.org" 

Cc: "lsr@ietf.org" 
Subject: [Lsr] LSR WG IPR Query for "Signaling MSD (Maximum SID Depth) using 
OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

 

Authors, 

 

Are you aware of any IPR that applies to 
draft-ietf-ospf-segment-routing-msd-10.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] FW: New Version Notification for draft-ginsberg-isis-rfc7810bis-00.txt

[Jeff Tantsura]

+1

Regards,
Jeff

> On Apr 6, 2018, at 12:25, Acee Lindem (acee)  wrote:
> 
> I'm fine with the proposed naming conventions for new drafts. Formally: 
> 
>-lsr-ospf-   - OSPF Specific drafts
>-lsr-isis-  - IS-IS Specific drafts 
>-lsr- - Drafts covering both 
> protocols. 
> 
> Anyone strongly disagree? 
> 
> Thanks,
> Acee 
> 
> 
> 
> 
> On 4/6/18, 1:57 PM, "Les Ginsberg (ginsberg)"  wrote:
> 
>Tom -
> 
>Thanx for the support.
> 
>It occurs to me that your filter still needs adjustment however - since 
> there will be cases when a common document is used for all protocols - and in 
> such a case you can only expect "-lsr-" to be in the title.
> 
>My point is there should be a straightforward way to identify the scope of 
> the content from the name - just using "-lsr-" for all documents is very 
> sub-optimal - and the fix for this is very easy.
> 
>   Les
> 
> 
>> -Original Message-
>> From: t.petch 
>> Sent: Friday, April 06, 2018 3:43 AM
>> To: Les Ginsberg (ginsberg) ; Christian Hopps
>> 
>> Cc: lsr@ietf.org; Acee Lindem (acee) 
>> Subject: Re: [Lsr] FW: New Version Notification for draft-ginsberg-isis-
>> rfc7810bis-00.txt
>> 
>> - Original Message -
>> From: "Les Ginsberg (ginsberg)" 
>> Sent: Thursday, April 05, 2018 5:26 PM
>> 
>>> Chris -
>>> 
 -Original Message-
 From: Christian Hopps 
 Sent: Thursday, April 05, 2018 7:32 AM
 
 I think that the only time we should include the protocol (in
>> addition to '-lsr-')
 is if we have split documents (for whatever reason) on the same
>> solution.
 We have an example of this actually:
 
draft-ietf--segment-routing-msd-09
draft-ietf-ospf-segment-routing-msd-09
 
 Going forward we either combine these types of documents into a
>> single
 document (discussion started @101) so "-lsr-" is appropriate, or if
>> there's
 some reason not to merge them then we have 2 documents that need
>> the
 protocol identifier to disambiguate.
 
 In this case there's no ambiguity so I don't see the need of adding
>> an extra "-
 isis-".
>>> [Les:] RFC 7810 is  specific.
>>> There is a separate document for equivalent OSPF functionality (RFC
>> 7471).
>>> 
>>> My point is - the reader should not have to go through the body of the
>> document to find out that the document is specific to a particular protocol.
>> The document name (which is preserved in the text even when it becomes
>> an RFC) should make that clear.
>>> 
>> 
>> I agree.
>> 
>> From a purely personal point of view, I track OSPF but have no interest in 
>> the
>> other protocol (mention of which causes my ISP to blackhole my e-mail).  I
>> filter the I-D announce list and will see notification of any I-D with OSPF 
>> in the
>> title - any without OSPF in the title will pass under the radar.
>> 
>> Tom Petch
>> 
>>>   Les
>>> 
 Thanks,
 Chris.
 
 Les Ginsberg (ginsberg)  writes:
 
> Well...this raises a topic on which I would like to have feedback
>> from the
 WG.
> 
> Combining /OSPF into one working group is fine - no argument
>> there.
> But, we now may be producing two classes of documents:
> 
> 
> 
> 
> ___
> 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-ginsberg-isis-rfc7810bis-00.txt

[Jeff Tantsura]

Acee,

What about ospfv2 vs ospfv3 specifics?
We keep it as before - eg “ospf” covers either or ospfv2, “ospfv3” is for 
ospfv3 only? 

Regards,
Jeff

> On Apr 6, 2018, at 12:25, Acee Lindem (acee)  wrote:
> 
> I'm fine with the proposed naming conventions for new drafts. Formally: 
> 
>-lsr-ospf-   - OSPF Specific drafts
>-lsr-isis-  - IS-IS Specific drafts 
>-lsr- - Drafts covering both 
> protocols. 
> 
> Anyone strongly disagree? 
> 
> Thanks,
> Acee 
> 
> 
> 
> 
> On 4/6/18, 1:57 PM, "Les Ginsberg (ginsberg)"  wrote:
> 
>Tom -
> 
>Thanx for the support.
> 
>It occurs to me that your filter still needs adjustment however - since 
> there will be cases when a common document is used for all protocols - and in 
> such a case you can only expect "-lsr-" to be in the title.
> 
>My point is there should be a straightforward way to identify the scope of 
> the content from the name - just using "-lsr-" for all documents is very 
> sub-optimal - and the fix for this is very easy.
> 
>   Les
> 
> 
>> -Original Message-
>> From: t.petch 
>> Sent: Friday, April 06, 2018 3:43 AM
>> To: Les Ginsberg (ginsberg) ; Christian Hopps
>> 
>> Cc: lsr@ietf.org; Acee Lindem (acee) 
>> Subject: Re: [Lsr] FW: New Version Notification for draft-ginsberg-isis-
>> rfc7810bis-00.txt
>> 
>> - Original Message -
>> From: "Les Ginsberg (ginsberg)" 
>> Sent: Thursday, April 05, 2018 5:26 PM
>> 
>>> Chris -
>>> 
 -Original Message-
 From: Christian Hopps 
 Sent: Thursday, April 05, 2018 7:32 AM
 
 I think that the only time we should include the protocol (in
>> addition to '-lsr-')
 is if we have split documents (for whatever reason) on the same
>> solution.
 We have an example of this actually:
 
draft-ietf--segment-routing-msd-09
draft-ietf-ospf-segment-routing-msd-09
 
 Going forward we either combine these types of documents into a
>> single
 document (discussion started @101) so "-lsr-" is appropriate, or if
>> there's
 some reason not to merge them then we have 2 documents that need
>> the
 protocol identifier to disambiguate.
 
 In this case there's no ambiguity so I don't see the need of adding
>> an extra "-
 isis-".
>>> [Les:] RFC 7810 is  specific.
>>> There is a separate document for equivalent OSPF functionality (RFC
>> 7471).
>>> 
>>> My point is - the reader should not have to go through the body of the
>> document to find out that the document is specific to a particular protocol.
>> The document name (which is preserved in the text even when it becomes
>> an RFC) should make that clear.
>>> 
>> 
>> I agree.
>> 
>> From a purely personal point of view, I track OSPF but have no interest in 
>> the
>> other protocol (mention of which causes my ISP to blackhole my e-mail).  I
>> filter the I-D announce list and will see notification of any I-D with OSPF 
>> in the
>> title - any without OSPF in the title will pass under the radar.
>> 
>> Tom Petch
>> 
>>>   Les
>>> 
 Thanks,
 Chris.
 
 Les Ginsberg (ginsberg)  writes:
 
> Well...this raises a topic on which I would like to have feedback
>> from the
 WG.
> 
> Combining /OSPF into one working group is fine - no argument
>> there.
> But, we now may be producing two classes of documents:
> 
> 
> 
> 
> ___
> 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-ginsberg-isis-rfc7810bis-00.txt

[Jeff Tantsura]

Sold!

Cheers,
Jeff
On 4/6/18, 14:45, "Acee Lindem (acee)"  wrote:

Good point - we will expand to: 

-lsr-ospf-  - OSPF Specific 
drafts pertaining to both OSPFv2 and OSPFv3
-lsr-ospfv2-  - OSPFv2 only Specific 
drafts 
-lsr-ospfv3-  - OSPFv3 only Specific 
drafts 
-lsr-isis-- IS-IS Specific 
drafts
-lsr-   - Drafts covering 
both protocols.

I'd hope the OSPFv2 and OSPFv3 specific drafts are few and far between but 
I can still see reasons to have both (e.g., OSPFv2 will never support multiple 
address familes). 

Thanks,
Acee

On 4/6/18, 5:29 PM, "Jeff Tantsura"  wrote:

Acee,

What about ospfv2 vs ospfv3 specifics?
We keep it as before - eg “ospf” covers either or ospfv2, “ospfv3” is 
for ospfv3 only? 

Regards,
Jeff

> On Apr 6, 2018, at 12:25, Acee Lindem (acee)  wrote:
> 
> I'm fine with the proposed naming conventions for new drafts. 
Formally: 
> 
>-lsr-ospf-   - OSPF Specific 
drafts
>-lsr-isis-  - IS-IS Specific 
drafts 
>-lsr- - Drafts 
covering both protocols. 
> 
> Anyone strongly disagree? 
> 
> Thanks,
> Acee 
> 
> 
> 
> 
> On 4/6/18, 1:57 PM, "Les Ginsberg (ginsberg)"  
wrote:
> 
>Tom -
> 
>Thanx for the support.
> 
>It occurs to me that your filter still needs adjustment however - 
since there will be cases when a common document is used for all protocols - 
and in such a case you can only expect "-lsr-" to be in the title.
> 
>My point is there should be a straightforward way to identify the 
scope of the content from the name - just using "-lsr-" for all documents is 
very sub-optimal - and the fix for this is very easy.
> 
>   Les
> 
> 
>> -Original Message-
>> From: t.petch 
>> Sent: Friday, April 06, 2018 3:43 AM
>> To: Les Ginsberg (ginsberg) ; Christian Hopps
>> 
>> Cc: lsr@ietf.org; Acee Lindem (acee) 
>> Subject: Re: [Lsr] FW: New Version Notification for 
draft-ginsberg-isis-
>> rfc7810bis-00.txt
>> 
>> - Original Message -
>> From: "Les Ginsberg (ginsberg)" 
>> Sent: Thursday, April 05, 2018 5:26 PM
>> 
>>> Chris -
>>> 
>>>> -Original Message-
>>>> From: Christian Hopps 
>>>> Sent: Thursday, April 05, 2018 7:32 AM
>>>> 
>>>> I think that the only time we should include the protocol (in
>> addition to '-lsr-')
>>>> is if we have split documents (for whatever reason) on the same
>> solution.
>>>> We have an example of this actually:
>>>> 
>>>>draft-ietf--segment-routing-msd-09
>>>>draft-ietf-ospf-segment-routing-msd-09
>>>> 
>>>> Going forward we either combine these types of documents into a
>> single
>>>> document (discussion started @101) so "-lsr-" is appropriate, or if
>> there's
>>>> some reason not to merge them then we have 2 documents that need
>> the
>>>> protocol identifier to disambiguate.
>>>> 
>>>> In this case there's no ambiguity so I don't see the need of adding
>> an extra "-
>>>> isis-".
>>> [Les:] RFC 7810 is  specific.
>>> There is a separate document for equivalent OSPF functionality (RFC
>> 7471).
>>> 
>>> My point is - the reader should not have to go through the body of 
the
>> document to find out that the document is specific to a particular 
protocol.
>> The document name (which is preserved in the text even when it 
becomes
>> an RFC) should make that clear.
>>> 
>> 
>> I agree.
>> 
>> From a purely personal point of view, I track OSPF but have no 
interest in the
>> other protocol (mention of which causes my ISP to blackhole my 
e-mail).  I
&

Re: [Lsr] LSR WG Adoption call for "IS-IS Traffic Engineering (TE) Metric Extensions" - draft-ginsberg-lsr-isis-rfc7810bis-00

[Jeff Tantsura]

Support!

Regards,
Jeff

> On Apr 9, 2018, at 21:20, Acee Lindem (acee)  wrote:
> 
> This draft simply fixes a problem in RFC 7810 that resulted in an 
> incompatibility issue with implementations. Given the simplicity of this 
> document, I’d like to have an abbreviated WG adoption call of one week. 
> Please indicate your support or objections to this document by April 17th, 
> 2018.  
>  
> 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 WG Last Call for "Signaling MSD (Maximum SID Depth) using OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

[Jeff Tantsura]

Hi Ketan

 

Thank you for your review, I’ll address the comments during this week.

Thanks!

 

Cheers,

Jeff

From: Lsr  on behalf of "Ketan Talaulikar (ketant)" 

Date: Thursday, April 12, 2018 at 05:04
To: "Acee Lindem (acee)" , "lsr@ietf.org" 
Subject: Re: [Lsr] LSR WG Last Call for "Signaling MSD (Maximum SID Depth) 
using OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

 

Hi Acee,

 

I have reviewed this draft for OSPF but in the same context also gone over its 
corresponding ISIS draft 
(https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/ ) and 
some of the comments apply to both since they are mostly identical in content.

 

I need to ask the question if it makes sense to merge these drafts into a 
single one to save everyone cycles and ensure consistency in the spirit of LSR J

 

General Qs:
There are some differences between the ISIS and OSPF versions of this draft.. 
Could I request the authors to please cross-check and fix? The ISIS draft does 
not have some of the issues mentioned below.
Do these TLVs apply only when the router is enabled for Segment Routing? i.e. 
they should be originated when SR is enabled on the router and the receiver 
should not expect them when SR is disabled? Or do we foresee MSD to be more 
generic. This aspect needs to be clarified.
The allowable values are specified as 0-254 in OSPF draft while ISIS one allows 
255 as well. The IANA section though says that 255 is reserved.
The draft using “sub-type” in some places and “type” in some places.. This is 
confusing. The ISIS draft uses “type” everywhere which seems better.
Several comments below about the section where OSPF TLVs are defined and I 
would suggest to use similar text as in the ISIS draft.
I think it is better that the draft mandates that the  MSD sub-types SHOULD be 
encoded in ascending order? This makes it easier for the receiver/consumer to 
detect absence or removal of a specific sub-type from signalling.
Reference to RFC4970 should be replaced with RFC7770
Both the ISIS and OSPF drafts are asking IANA for creation of MSD type 
registry. Should the creation not be done by only one of them and the other 
points to it?
 

 

Sec 1

 
can be imposed at each node/link on a given SR path
 
It laso also defines
   the Base MPLS Imposition MSD type.
 
Sec 1.1.1

 
   BMI: Base MPLS Imposition is the number of MPLS labels that can be
   imposed inclusive of any all service/transport/special labels
 

Sec 3

 
Node MSD is the minimum MSD supported by all the links of the node.
 
Sub-Type 1 (IANA Section), MSD and the Value field contains maximum
   MSD of the router originating the RI LSA.
 
 

Some Qs on Sec 3:
In my understanding, the Node MSD is the minimum value of all the Link MSDs for 
the links on that node that are enabled in that specific IGP instance. There 
may be another IGP instance configured on the same node with a different set of 
links and for that instance, the Node MSD may be higher. The same goes for 
links that are not configured/enabled under the specific IGP instance. The 
draft needs to clarify this aspect.
The draft needs to specify how many instances of this TLV are allowed in the RI 
LSA and when there are multiple instances in the same or multiple RI LSA 
fragments, then how should the receiver handle or interpret them? E.g. uses the 
minimum of the signalled Node MSD values or uses the first instance of the TLV 
in the lowest fragment, etc. Also, we don’t want multiple instances of the MSD 
TLV to be encoded for different types – all of them must be in a single 
instance of the MSD TLV.
 

Sec 4

 
   For OSPFv3, the Link level MSD value is advertised as an optional
   Sub-TLV of the Router-Link E-Router-LSA TLV as defined in
   [I-D.ietf-ospf-ospfv3-lsa-extend], and has value of TBD3.
 
   Sub-Type 1 (IANA Section), MSD and the Value field contains Link MSD
   of the link router originating the corresponding LSA as specified for
   OSPFv2 and OSPFv3.
 

Some Qs on Sec 4:
The draft needs to specify how many instances of this TLV are allowed in the 
Extended Link Attribute/E-Router LSA and when there are multiple instances then 
how should the receiver handle or interpret them? Also, we don’t want multiple 
instances of the MSD TLV to be encoded for different types – all of them must 
be in a single instance of the MSD TLV.
 

 

Sec 5

 
Suggest to add “When a Link MSD type is not signalled but the Node MSD type is, 
then the value of that Link MSD type MUST considered as the corresponding Node 
MSD type value.” I realize this is obvious but it is better to be clarified. 
This enables routes with homogenous link MSD values to advertise just the Node 
MSD values. I also think this should be RECOMMENDED by the draft for flooding 
efficiencies.
 
Sec 6
 
   The Base MPLS Imposition MSD (BMI-MSD) signals the total number of
   MPLS labels a node is capable of imposing, including any all service/
   Transport/special labels.
 
Sec 8
 
I think the security secti

Re: [Lsr] LSR Working Group Secretary

[Jeff Tantsura]

Couldn’t agree more!
Yingzhen is great at everything she does, thanks!
(Don’t forget us, at RTGWG ;-))

Regards,
Jeff

> On Apr 23, 2018, at 10:49, Les Ginsberg (ginsberg)  wrote:
> 
> Bravo!
> Now LSR is a world class WG.
>  
> Thanx to Yingzhen for taking on this additional responsibility.
>  
>Les
>  
>  
> From: Lsr  On Behalf Of Acee Lindem (acee)
> Sent: Monday, April 23, 2018 6:43 AM
> To: lsr@ietf.org
> Subject: [Lsr] LSR Working Group Secretary
>  
> All,
>  
> I’m delighted to announce that Yingzhen Qu has volunteered to take on the 
> role of WG secretary. Yingzhen took the minutes at the first formal meeting 
> of the LSR WG in London and is also RTG WG secretary.
>  
> 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 for draft-ietf-isis-segment-routing-extensions-16

[Jeff Tantsura]

Support as co-author

Regards,
Jeff

> On Apr 23, 2018, at 07:02, Christian Hopps  wrote:
> 
> Hi Folks,
> 
> We are starting a new 2 week WG last call on
> 
> https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/
> 
> as there have (*) been some changes to the document since our last WG last 
> call last year. Here's the diff.
>   
> https://www.ietf.org/rfcdiff?url1=draft-ietf-isis-segment-routing-extensions-12&url2=draft-ietf-isis-segment-routing-extensions-16
> 
> Will end Monday May 7th.
> 
> Thanks,
> Chris.
> 
> (*) contrary to what you may have heard from folks at the mic in London. :)
> 
> ___
> 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] RtgDir Early review: draft-ietf-ospf-segment-routing-msd.txt

[Jeff Tantsura]

Hi Tal,

Many thanks for your review!
Coming week I’ll be working to address them as well as on earlier comments 
provided by Ketan. 
Should be done by the end of the week.

Regards,
Jeff

> On Apr 29, 2018, at 04:08, Tal Mizrahi  wrote:
> 
> + LSR mailing list.
> 
> Cheers,
> Tal.
> 
>> On Sun, Apr 29, 2018 at 2:04 PM, Tal Mizrahi  
>> wrote:
>> Hello
>> 
>> I have been selected to do a routing directorate “early” review of this 
>> draft. 
>> ​https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/
>> 
>> The routing directorate will, on request from the working group chair, 
>> perform an “early” review of a draft before it is submitted for publication 
>> to the IESG. The early review can be performed at any time during the 
>> draft’s lifetime as a working group document.
>> 
>> For more information about the Routing Directorate, please see 
>> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>> 
>> Document: draft-ietf-ospf-segment-routing-msd.txt 
>> Reviewer: Tal Mizrahi
>> Review Date: April 2018 
>> Intended Status: Standards Track
>> 
>> Summary: 
>> This document is basically ready for publication, but has a couple of issues 
>> and a few nits that should be considered prior to being submitted to the 
>> IESG.
>> 
>> Comments:
>> 
>> The Security Considerations should be more detailed. The reference to RFC 
>> 7770 is a good start, but please add more details about potential attacks. 
>> For example, what happens if there is a spoofed MSD with a low MSD value? 
>> What is the impact of such an attack?
>> Section 3:
>> The description of the Length field says “minimum of 2”, implying it can be 
>> higher than 2.
>> On the other hand, the Value field: “consists of a 1 octet sub-type (IANA 
>> Registry) and 1 octet value.”, which implies that the Length is equal to 2.
>> Please align the two descriptions, i.e., if flexibility for future sub-types 
>> is required, please change the description of Value to allow longer values.
>> The comment applies to Section 4 as well.
>> Nits:
>> 
>> The term “minimum MSD”, which translates to “minimum maximum SID Depth” 
>> should be explained.
>> The term “maximum MSD” appears twice in the document, which seems either 
>> redundant, or a typo (did you mean minimum MSD?).
>> The acronym SID should be spelled out on its first use.
>> The acronyms RI and LSA should be added to the Terminology subsection.
>> Section 1.1.1 and Section 2 are both titled “Terminology”.. It would be best 
>> to merge Section 1.1 into Section 2, and avoid the duplicate title.
>> “each node/link a given SR path” -> “each node/link of a given SR path”
>> “nodes and links which has been configured” -> “nodes and links that have 
>> been configured”
>> “laso”->”also”
>> “Other Sub-types other than defined” -> “Sub-types other than defined”
>> 
>> 
>> Cheers,
>> Tal Mizrahi.
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] RtgDir Early review: draft-ietf-ospf-segment-routing-msd.txt

[Jeff Tantsura]

Hi Tal,

 

New version (11) should address all your comments.

Many thanks and please let me know, if there’s anything else.

 

Cheers,

Jeff

From: Tal Mizrahi 
Date: Sunday, April 29, 2018 at 04:08
To: , , 

Cc: , 
Subject: Re: RtgDir Early review: draft-ietf-ospf-segment-routing-msd.txt
Resent-From: 
Resent-To: Jeff Tantsura , , 
, 
Resent-Date: Sun, 29 Apr 2018 04:08:12 -0700 (PDT)

 

+ LSR mailing list.

 

Cheers,

Tal.

 

On Sun, Apr 29, 2018 at 2:04 PM, Tal Mizrahi  wrote:

Hello

I have been selected to do a routing directorate “early” review of this draft. 
​https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/

The routing directorate will, on request from the working group chair, perform 
an “early” review of a draft before it is submitted for publication to the 
IESG. The early review can be performed at any time during the draft’s lifetime 
as a working group document. 

For more information about the Routing Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-ospf-segment-routing-msd.txt 
Reviewer: Tal Mizrahi
Review Date: April 2018 
Intended Status: Standards Track

Summary: 
This document is basically ready for publication, but has a couple of issues 
and a few nits that should be considered prior to being submitted to the IESG.

Comments:
The Security Considerations should be more detailed. The reference to RFC 7770 
is a good start, but please add more details about potential attacks. For 
example, what happens if there is a spoofed MSD with a low MSD value? What is 
the impact of such an attack?
Section 3:
The description of the Length field says “minimum of 2”, implying it can be 
higher than 2.
On the other hand, the Value field: “consists of a 1 octet sub-type (IANA 
Registry) and 1 octet value.”, which implies that the Length is equal to 2.
Please align the two descriptions, i.e., if flexibility for future sub-types is 
required, please change the description of Value to allow longer values..
The comment applies to Section 4 as well.
Nits:
The term “minimum MSD”, which translates to “minimum maximum SID Depth” should 
be explained.
The term “maximum MSD” appears twice in the document, which seems either 
redundant, or a typo (did you mean minimum MSD?).
The acronym SID should be spelled out on its first use.
The acronyms RI and LSA should be added to the Terminology subsection.
Section 1.1.1 and Section 2 are both titled “Terminology”. It would be best to 
merge Section 1.1 into Section 2, and avoid the duplicate title.
“each node/link a given SR path” -> “each node/link of a given SR path”
“nodes and links which has been configured” -> “nodes and links that have been 
configured”
“laso”->”also”
“Other Sub-types other than defined” -> “Sub-types other than defined”
 

 

Cheers,

Tal Mizrahi.

 

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

Re: [Lsr] LSR WG Last Call for "Signaling MSD (Maximum SID Depth) using OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

[Jeff Tantsura]

Hi Ketan,

 

New version (11) should address all your comments, please check and let me know.

ISIS version is being aligned as we speak.

 

Many thanks!

 

Cheers,

Jeff

From: Lsr  on behalf of "Ketan Talaulikar (ketant)" 

Date: Thursday, April 12, 2018 at 05:04
To: "Acee Lindem (acee)" , "lsr@ietf.org" 
Subject: Re: [Lsr] LSR WG Last Call for "Signaling MSD (Maximum SID Depth) 
using OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

 

Hi Acee,

 

I have reviewed this draft for OSPF but in the same context also gone over its 
corresponding ISIS draft 
(https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/ ) and 
some of the comments apply to both since they are mostly identical in content.

 

I need to ask the question if it makes sense to merge these drafts into a 
single one to save everyone cycles and ensure consistency in the spirit of LSR J

 

General Qs:
There are some differences between the ISIS and OSPF versions of this draft.. 
Could I request the authors to please cross-check and fix? The ISIS draft does 
not have some of the issues mentioned below.
Do these TLVs apply only when the router is enabled for Segment Routing? i.e. 
they should be originated when SR is enabled on the router and the receiver 
should not expect them when SR is disabled? Or do we foresee MSD to be more 
generic. This aspect needs to be clarified.
The allowable values are specified as 0-254 in OSPF draft while ISIS one allows 
255 as well. The IANA section though says that 255 is reserved.
The draft using “sub-type” in some places and “type” in some places.. This is 
confusing. The ISIS draft uses “type” everywhere which seems better.
Several comments below about the section where OSPF TLVs are defined and I 
would suggest to use similar text as in the ISIS draft.
I think it is better that the draft mandates that the  MSD sub-types SHOULD be 
encoded in ascending order? This makes it easier for the receiver/consumer to 
detect absence or removal of a specific sub-type from signalling.
Reference to RFC4970 should be replaced with RFC7770
Both the ISIS and OSPF drafts are asking IANA for creation of MSD type 
registry. Should the creation not be done by only one of them and the other 
points to it?
 

 

Sec 1

 
can be imposed at each node/link on a given SR path
 
It laso also defines
   the Base MPLS Imposition MSD type.
 
Sec 1.1.1

 
   BMI: Base MPLS Imposition is the number of MPLS labels that can be
   imposed inclusive of any all service/transport/special labels
 

Sec 3

 
Node MSD is the minimum MSD supported by all the links of the node.
 
Sub-Type 1 (IANA Section), MSD and the Value field contains maximum
   MSD of the router originating the RI LSA.
 
 

Some Qs on Sec 3:
In my understanding, the Node MSD is the minimum value of all the Link MSDs for 
the links on that node that are enabled in that specific IGP instance. There 
may be another IGP instance configured on the same node with a different set of 
links and for that instance, the Node MSD may be higher. The same goes for 
links that are not configured/enabled under the specific IGP instance. The 
draft needs to clarify this aspect.
The draft needs to specify how many instances of this TLV are allowed in the RI 
LSA and when there are multiple instances in the same or multiple RI LSA 
fragments, then how should the receiver handle or interpret them? E.g. uses the 
minimum of the signalled Node MSD values or uses the first instance of the TLV 
in the lowest fragment, etc. Also, we don’t want multiple instances of the MSD 
TLV to be encoded for different types – all of them must be in a single 
instance of the MSD TLV.
 

Sec 4

 
   For OSPFv3, the Link level MSD value is advertised as an optional
   Sub-TLV of the Router-Link E-Router-LSA TLV as defined in
   [I-D.ietf-ospf-ospfv3-lsa-extend], and has value of TBD3.
 
   Sub-Type 1 (IANA Section), MSD and the Value field contains Link MSD
   of the link router originating the corresponding LSA as specified for
   OSPFv2 and OSPFv3.
 

Some Qs on Sec 4:
The draft needs to specify how many instances of this TLV are allowed in the 
Extended Link Attribute/E-Router LSA and when there are multiple instances then 
how should the receiver handle or interpret them? Also, we don’t want multiple 
instances of the MSD TLV to be encoded for different types – all of them must 
be in a single instance of the MSD TLV.
 

 

Sec 5

 
Suggest to add “When a Link MSD type is not signalled but the Node MSD type is, 
then the value of that Link MSD type MUST considered as the corresponding Node 
MSD type value.” I realize this is obvious but it is better to be clarified. 
This enables routes with homogenous link MSD values to advertise just the Node 
MSD values. I also think this should be RECOMMENDED by the draft for flooding 
efficiencies.
 
Sec 6
 
   The Base MPLS Imposition MSD (BMI-MSD) signals the total number of
   MPLS labels a node is capable of imposing, including any all service/
  

Re: [Lsr] LSR WG Last Call for "Signaling MSD (Maximum SID Depth) using OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

[Jeff Tantsura]

Hi Ketan,

 

Many thanks for you thoughtful reviews, working with the authors to improve the 
draft! 

 

Cheers,

Jeff

From: "Ketan Talaulikar (ketant)" 
Date: Thursday, May 10, 2018 at 08:05
To: Jeff Tantsura , "Acee Lindem (acee)" 
, "lsr@ietf.org" 
Subject: RE: [Lsr] LSR WG Last Call for "Signaling MSD (Maximum SID Depth) 
using OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

 

Hi Jeff,

 

The version 12 addresses all my comments and thanks for the updates.

 

Thanks,

Ketan

 

From: Jeff Tantsura  
Sent: 08 May 2018 04:53
To: Ketan Talaulikar (ketant) ; Acee Lindem (acee) 
; lsr@ietf.org
Subject: Re: [Lsr] LSR WG Last Call for "Signaling MSD (Maximum SID Depth) 
using OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

 

Hi Ketan,

 

New version (11) should address all your comments, please check and let me know.

ISIS version is being aligned as we speak.

 

Many thanks!

 

Cheers,

Jeff

From: Lsr  on behalf of "Ketan Talaulikar (ketant)" 

Date: Thursday, April 12, 2018 at 05:04
To: "Acee Lindem (acee)" , "lsr@ietf.org" 
Subject: Re: [Lsr] LSR WG Last Call for "Signaling MSD (Maximum SID Depth) 
using OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

 

Hi Acee,

 

I have reviewed this draft for OSPF but in the same context also gone over its 
corresponding ISIS draft 
(https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/ ) and 
some of the comments apply to both since they are mostly identical in content.

 

I need to ask the question if it makes sense to merge these drafts into a 
single one to save everyone cycles and ensure consistency in the spirit of LSR J

 

General Qs:
There are some differences between the ISIS and OSPF versions of this draft.. 
Could I request the authors to please cross-check and fix? The ISIS draft does 
not have some of the issues mentioned below.
Do these TLVs apply only when the router is enabled for Segment Routing? i.e. 
they should be originated when SR is enabled on the router and the receiver 
should not expect them when SR is disabled? Or do we foresee MSD to be more 
generic. This aspect needs to be clarified.
The allowable values are specified as 0-254 in OSPF draft while ISIS one allows 
255 as well. The IANA section though says that 255 is reserved.
The draft using “sub-type” in some places and “type” in some places.. This is 
confusing. The ISIS draft uses “type” everywhere which seems better.
Several comments below about the section where OSPF TLVs are defined and I 
would suggest to use similar text as in the ISIS draft.
I think it is better that the draft mandates that the  MSD sub-types SHOULD be 
encoded in ascending order? This makes it easier for the receiver/consumer to 
detect absence or removal of a specific sub-type from signalling.
Reference to RFC4970 should be replaced with RFC7770
Both the ISIS and OSPF drafts are asking IANA for creation of MSD type 
registry. Should the creation not be done by only one of them and the other 
points to it?
 

 

Sec 1

 
can be imposed at each node/link on a given SR path
 
It laso also defines
   the Base MPLS Imposition MSD type.
 
Sec 1.1.1

 
   BMI: Base MPLS Imposition is the number of MPLS labels that can be
   imposed inclusive of any all service/transport/special labels
 

Sec 3

 
Node MSD is the minimum MSD supported by all the links of the node.
 
Sub-Type 1 (IANA Section), MSD and the Value field contains maximum
   MSD of the router originating the RI LSA.
 
 

Some Qs on Sec 3:
In my understanding, the Node MSD is the minimum value of all the Link MSDs for 
the links on that node that are enabled in that specific IGP instance. There 
may be another IGP instance configured on the same node with a different set of 
links and for that instance, the Node MSD may be higher. The same goes for 
links that are not configured/enabled under the specific IGP instance. The 
draft needs to clarify this aspect.
The draft needs to specify how many instances of this TLV are allowed in the RI 
LSA and when there are multiple instances in the same or multiple RI LSA 
fragments, then how should the receiver handle or interpret them? E.g. uses the 
minimum of the signalled Node MSD values or uses the first instance of the TLV 
in the lowest fragment, etc. Also, we don’t want multiple instances of the MSD 
TLV to be encoded for different types – all of them must be in a single 
instance of the MSD TLV.
 

Sec 4

 
   For OSPFv3, the Link level MSD value is advertised as an optional
   Sub-TLV of the Router-Link E-Router-LSA TLV as defined in
   [I-D.ietf-ospf-ospfv3-lsa-extend], and has value of TBD3.
 
   Sub-Type 1 (IANA Section), MSD and the Value field contains Link MSD
   of the link router originating the corresponding LSA as specified for
   OSPFv2 and OSPFv3.
 

Some Qs on Sec 4:
The draft needs to specify how many instances of this TLV are allowed in the 
Extended Link Attribute/

Re: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-11.txt

[Jeff Tantsura]

Hi Chris,

I don't see much value in merging, most of the content describes encodings 
which are different, per protocol,
Wrt registry - please let us know which draft you'd want to request the new 
registry.

Thanks! 

Cheers,
Jeff
On 5/15/18, 11:33, "Lsr on behalf of Peter Psenak"  wrote:

Hi Chris,

On 15/05/18 10:54 , Christian Hopps wrote:
>
> Hi Les,
>
> I was going over the 2 SR-MSD documents (IS-IS and OSPF) just wondering
> how viable it would be and if we should combine them.
>
> In any case doing the diff highlighted a couple issues in the IS-IS
> version.
>
> Issue: Under both the Node and Link sub-tlv's the MSD type (1?) is not
> actually mentioned, only the "MSD value", if one was pedantic it would
> mean that regardless of the type the value was always the same,
> certainly not what is intended. :)
>
> Issue: The OSPF version adds text about what to do in the presence of
> multiple instances of the same TLV. This highlighted the fact that the
> IS-IS draft doesn't do this, but also doesn't talk about there only
> being 1 allowed.
>
> Maybe Issue: We've got 2 drafts creating the same sub-[-sub]-tlv MSD
> type registry. I fully agree that we should only have one registry, but
> it's interesting that we'll have 2 publications that create and
> reference it. Also, where does this registry go in IANA? There are
> distinct IS-IS, OSPFv2 and OSPFv3 pages that contain the IANA registries
> for each protocol. Should we create a new shared LSR or IGP page? Anyway
> this might be a reason to combine the 2 documents.

there is one already:
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml

I agree that we need registry to be created in only one of the documents 
and have other reference it, unless we merge these two drafts.


thanks,
Peter

>
> While somewhat inelegant we could probably avoid any need to re-Last
> Call if the combination was basically a cut and paste operation.
>
> Thanks,
> Chris.
>
> Les Ginsberg (ginsberg)  writes:
>
>> This is a minor editorial revision to make the draft consistent w
>> draft-ietf-ospf-segment-routing-msd-12.
>>
>>Les
>>
>>> -Original Message-
>>> From: Lsr  On Behalf Of internet-dra...@ietf.org
>>> Sent: Thursday, May 10, 2018 5:49 PM
>>> To: i-d-annou...@ietf.org
>>> Cc: lsr@ietf.org
>>> Subject: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-11.txt
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Link State Routing WG of the IETF.
>>>
>>> Title   : Signaling MSD (Maximum SID Depth) using IS-IS
>>> Authors : Jeff Tantsura
>>>   Uma Chunduri
>>>   Sam Aldrin
>>>   Les Ginsberg
>>> Filename: draft-ietf-isis-segment-routing-msd-11.txt
>>> Pages   : 9
>>> Date: 2018-05-10
>>>
>>> Abstract:
>>>This document defines a way for an IS-IS Router to advertise multiple
>>>types of supported Maximum SID Depths (MSDs) at node and/or link
>>>granularity.  Such advertisements allow entities (e.g., centralized
>>>controllers) to determine whether a particular SID stack can be
>>>supported in a given network.  This document only defines one type of
>>>MSD maximum label imposition, but defines an encoding that can
>>>support other MSD types.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-isis-segment-routing-msd-11
>>> 
https://datatracker.ietf.org/doc/html/draft-ietf-isis-segment-routing-msd-
>>>
>>> 11
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-segment-routing-msd-11
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>&

Re: [Lsr] IPR Poll for "OSPFv3 Extensions for Segment Routing" Prior to WG Last Call

[Jeff Tantsura]

Acee,

I’m no aware of any IPR that applies to this draft.

Regards,
Jeff

> On May 22, 2018, at 16:43, Acee Lindem (acee)  wrote:
> 
> Are you aware of any IPR that applies to
> draft-ietf-ospf-ospfv3-segment-routing-extensions-12.txt?
>  
> If so, has this IPR been disclosed in compliance with 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] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00

[Jeff Tantsura]

Yes/support 

Regards,
Jeff

> On May 23, 2018, at 17:28, Christian Hopps  wrote:
> 
> Hi Folks,
> 
> We're starting a 2 week WG Last Call on
> 
>   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc7810bis/
> 
> Please raise any objections or comments before Jun 6th, 2018.
> 
> Thanks,
> 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 Working Group Last Call for "OSPFv3 Extensions for Segment Routing" - draft-ietf-ospf-ospfv3-segment-routing-extensions-13

[Jeff Tantsura]

Support as co-author

Regards,
Jeff

> On May 23, 2018, at 17:03, Acee Lindem (acee)  wrote:
> 
> This begins an LSR WG last call for the subject draft. Please send your
> comments to this list prior to 12:00 AM GMT, June 7th, 2018.
> Thanks,
> Acee and Chris
>  
> ___
> 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] IGP TE Metric Extensions

[Jeff Tantsura]

Muthu,

LSR would be a more suitable list to post to, CCed.

Regards,
Jeff

> On May 30, 2018, at 18:06, Muthu Arul Mozhi Perumal  
> wrote:
> 
> Muthu

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

Re: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 (Shepherd write-up)

[Jeff Tantsura]

Uma,

 

I’m not aware of any IPR that has not been previously disclosed. 

 

Cheers,

Jeff

From: Lsr  on behalf of Uma Chunduri 

Date: Monday, June 11, 2018 at 12:18
To: 
Subject: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 
(Shepherd write-up)

 

Dear All,

 

Are you aware of any IPR that applies to 

https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-16 ? 

 

Sending this email as suggested by LSR chairs - as this was not noticed 
during/around WGLC.

 

===

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.

===

 

--

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] draft-ietf-isis-segment-routing-extensions-16 - Shepherd review comments

[Jeff Tantsura]

Uma,

Wrt number of authors, if I recall correctly (I don’t have pointers to the 
discussion anymore), given the lengths and involvement of the authors currently 
on the front page, as an exception - both ospf and isis sr drafts would keep 
the initial number of authors.

Thanks,
Jeff

> On Jun 11, 2018, at 22:05, Les Ginsberg (ginsberg)  wrote:
> 
> Uma –
>  
> One item I forgot…there are no meaningful nits.
> Idnits reports:
>  
> -- Looks like a reference, but probably isn't: '100' on line 1009
>  'SRGB = [100, 199]...'
>  
>   -- Looks like a reference, but probably isn't: '199' on line 1009
>  'SRGB = [100, 199]...'
>  
>   -- Looks like a reference, but probably isn't: '1000' on line 1010
>  '[1000, 1099]...'
>  
>   -- Looks like a reference, but probably isn't: '1099' on line 1010
>  '[1000, 1099]...'
>  
>   -- Looks like a reference, but probably isn't: '500' on line 1011
>  '[500, 599]...'
>  
>   -- Looks like a reference, but probably isn't: '599' on line 1011
>  '[500, 599]...'
>  
>   -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589'
>  
> The fact that idnits looks at everything enclosed in [] as a reference does 
> not mean the text requires revision.
> Idnits also does not allow that a non-RFC document can be a normative 
> reference – but clearly ISO 10589 is a normative reference.

[jeff] indeed, we have used variety of non-RFC documents as normative 
references in the past, this should be acceptable in this case.
>  
> Thanx.
>  
>Les
>  
>  
> From: Les Ginsberg (ginsberg) 
> Sent: Monday, June 11, 2018 10:00 PM
> To: Uma Chunduri mailto:umac.i...@gmail.com>>; 
> lsr@ietf.org 
> Cc: draft-ietf-isis-segment-routing-extensi...@ietf.org 
> ; 
> lsr-cha...@ietf.org ; lsr-...@ietf.org 
> 
> Subject: RE: draft-ietf-isis-segment-routing-extensions-16 - Shepherd review 
> comments
>  
> Uma –
>  
> Thanx for the prompt review.
>  
> I have attached proposed diffs to address some of your comments.
>  
> Additional responses inline.
>  
>  
> From: Uma Chunduri mailto:umac.i...@gmail.com>> 
> Sent: Monday, June 11, 2018 6:27 PM
> To: lsr@ietf.org 
> Cc: draft-ietf-isis-segment-routing-extensi...@ietf.org 
> ; 
> lsr-cha...@ietf.org ; lsr-...@ietf.org 
> 
> Subject: draft-ietf-isis-segment-routing-extensions-16 - Shepherd review 
> comments
>  
> Dear Authors,
>  
> I have done shepherd  review of  
> draft-ietf-isis-segment-routing-extensions-16 document as requested by LSR 
> chairs. First, I would like to thank all the the authors and contributors on 
> this document.
> I have few minor comments below  and would be great if authors take a look at 
> these.
>  
>  
> =
>  
> A. I see few ID nits (comments and warnings). Please fix  those.
> B. For the record: (as this would come up soon) : Currently there are 8  
> front page authors and please indicate why this document should be given 
> exception w.r.t 5 co-authors norm, that is being followed in general.
>  
> [Les:] This will be addressed after discussion among the authors – thanx for 
> the reminder. J
>  
> 1. Abstract & Section 1
>  
> a.
>"These segments are   advertised by the link-state routing protocols 
> (IS-IS and OSPF)."
>  
>I see more than LSR protocols e.g. 
> https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-07 
> 
>Also not sure if this statement is necessary. Please either correct or 
> remove this.
>  
> [Les:] The abstract and introduction state “within IGP topologies”.  In that 
> context I believe limiting the protocols mentioned to IGPs is appropriate.
>  
> b.
>"Twotypes of segments are defined, Prefix segments and Adjacency   
> segments."
>  
>This document defines more than these two if you include Section 2.4 
> (SID/Label Binding TLV). Section 2 is much better
>where all types in this document are described as well as   
> [I-D.ietf-spring-segment-routing] is referred for other types.
>In that sense the above statement looks incomplete/repetitive.
>  
> [Les:] I have revised the text in this section – see attached diffs.
>  
>  2. Section 2.1
>  
> a. "The 'Prefix SID' MUST   be unique within a given IGP domain (when the 
> L-flag is not set)."
>  
>I see this is conflicting with what's been defined in 
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-14 
> ,
> section 3.3 -
>"Within an anycast group, all routers in an SR domain MUST advertise  the 
> same prefix with the same SID value."
>  
>If you see otherwise please explain why?
>  
> [Les:] This is a misunderstanding on your part.
> An anycast prefix

Re: [Lsr] IPR Poll draft-ietf-isis-segment-routing-msd.

[Jeff Tantsura]

Chris,

I'm not aware of any IPR outside of that already disclosed.

Thanks,
Jeff 

Cheers,
Jeff
On 6/13/18, 06:37, "Christian Hopps"  wrote:

[Sigh, I quoted the wrong email and mixed things up -- thanks Bruno!]

Authors,

The original WGLC requested the authors indicate if they were aware of any 
additional IPR. This seems to have gotten lost in a bunch of comments that 
followed.

Can each author reply to this email (and the list) indicating if they are 
aware of any *new* IPR on this document. Currently declared related IPR:


https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-isis-segment-routing-msd

Thanks,
Chris.



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

Re: [Lsr] [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS)

[Jeff Tantsura]

Gunter,

I have nothing to add to Les' comments, 100% agree.

Cheers,
Jeff
On 6/13/18, 08:42, "Idr on behalf of Les Ginsberg (ginsberg)" 
 wrote:

Gunter -

I strongly support Option #2 and strongly support Ketan's recommendation 
that an MSD sub-type be used to advertise ERLD.
This is the unified framework that the MSD advertisement has been designed 
to support.

The following documents provide a unified definition of this mechanism:

https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/
https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/

(The last one needs a refresh.)

If we can update the related ERLD documents to align I think we will have 
an excellent solution.

 (Note: in the case of 
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/ 
perhaps that can be combined with 
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/  - 
but I leave that to the respective authors to work out.)

   Les



> -Original Message-
> From: Lsr  On Behalf Of Van De Velde, Gunter (Nokia
> - BE/Antwerp)
> Sent: Wednesday, June 13, 2018 2:10 AM
> To: Ketan Talaulikar (ketant) ; i...@ietf.org; 
lsr@ietf.org;
> spr...@ietf.org
> Subject: Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS)
> 
> It is desirable that same understanding of TLVs ([ELC, RLD] or [ERLD]) are
> signaled for ISIS, OSPF and BGP-LS.
> 
> If the WG's can manage to agree upon a decision (option1/2/3 or 4), then
> next, have a look into how to encode the TLV so that we have a clean
> technological solution space.
> 
> G/
> 
> -Original Message-
> From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
> Sent: Wednesday, June 13, 2018 10:45
> To: Van De Velde, Gunter (Nokia - BE/Antwerp)
> ; i...@ietf.org; lsr@ietf.org;
> spr...@ietf.org
> Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)
> 
> Hi Gunter,
> 
> In that case, I concur with you that option (2) is better than the 
others. My
> only difference in opinion is that ERLD not have its own separate TLV but
> instead get advertised as a new MSD sub-type - it is just a different 
encoding.
> 
> Thanks,
> Ketan
> 
> -Original Message-
> From: Van De Velde, Gunter (Nokia - BE/Antwerp)
> 
> Sent: 13 June 2018 13:55
> To: Ketan Talaulikar (ketant) ; i...@ietf.org; 
lsr@ietf.org;
> spr...@ietf.org
> Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)
> 
> Indeed, the debate that made BGP-LS to go down the ERLD path is of
> pragmatic motivation.
> 
> The major Readable Label Depth use-case is entropy. Hence, if the ERLD TLV
> is available, then ELC can be implicitly assumed. No pragmatic reason to 
signal
> separately, as it just make things more complex then should be.
> 
> >From a holistic perspective having something similar, yet different, in 
both
> IGP and BGP-LS encoding seems to make little sense and only bring
> confusion (router/controller implementers and network operators).
> 
> The ways to address this in IGP and BGP-LS going forward:
> 1) do nothing and leave all as it is (it has potential to create massive
> confusion)
> 2) only signal ERLD TLV in IGP and BGP
> 3) signal ELC TLV and RLD TLV (unclear pragmatic value of explicit 
signaling of
> ELC TLV compared to option (2))
> 4) signal ELC TLV, RLD TLV and ERLD TLV (it has all, but is much much more
> complex as option (2))
> 
> I believe that option (2) is the best option:
> * it bring the needed readable label depth value to operators
> * most simple solution for implementers (routers and controller)
> * easy to understand with no confusion
> * is compliant with draft-ietf-mpls-spring-entropy-label-10
> 
> G/
> 
> -Original Message-
> From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
> Sent: Wednesday, June 13, 2018 08:05
> To: Van De Velde, Gunter (Nokia - BE/Antwerp)
> ; i...@ietf.org; lsr@ietf.org;
> spr...@ietf.org
> Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)
> 
> Hi Gunter,
> 
> The difference in IGP signalling seems to be because the ELC is a 
capability
> which is advertised differently than ERLD which is a limit. Are you 
saying that
> ELC does not have value by itself without the ERLD?
> 
> IMHO it makes sense to retain ELC as capability of the router (as 
specified in
> the IGP specs) and position ERLD as a MSD sub-type for indicating the 
limit.
> This way we have the flexibility of signalling ERLD both per node and per
> ingress link/LC level.
> 
> Thanks,
> Ketan
> 
> --

Re: [Lsr] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Jeff Tantsura]

Robin,

Pretty much same comment as Acee - I'm not clear as to why...
Protocol YANG models developed in the last years clearly provide much better 
and more scalable approach to what has been proposed in the draft, since we are 
talking is-is - look at notifications in draft-ietf-isis-yang-isis-cfg. How do 
you propose to corelate operational state to configuration?

gRPC provides high performance RPC framework  to streaming the telemetry data 
that is structured, easy to consume and extend. 

I'm not going to go into technical discussion, however would appreciate your 
response as to why NMP (please do not restate the points in the section 4 of 
the draft, they are quite incorrect) 

Thanks!

Cheers,
Jeff

On 7/3/18, 09:21, "Lsr on behalf of Acee Lindem (acee)"  wrote:

Hi Robin, 
I'm not arguing to deprecate BMP. What I am arguing is that the fact that 
BMP was created 15 years ago doesn't necessarily mean we should create an 
analogous IMP for IS-IS given the current IETF OPS technologies and the fact 
that faster link speeds and Moore's law facilitate deployment of these new OPS 
technologies. Anyway, I looked at the agenda and I will definitely attend GROW 
on Wednesday afternoon for the discussion. 
Thanks,
Acee 

On 7/3/18, 6:40 AM, "Lizhenbin"  wrote:

Hi Acee,
Thank for your attention to the new draft. Please refer to my reply 
inline.

Best Regards,
Robin



-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Acee Lindem 
(acee)
Sent: Monday, July 02, 2018 9:24 PM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
; g...@ietf.org; ops...@ietf.org
Subject: Re: [OPSAWG] [GROW] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

Hi Yunan, Shunwan, and Zhenbin, 

What are the advantages of inventing a new protocol over just using 
YANG and NETCONF, RESTCONF, or gNMI? 
[Robin] In the draft we simply mention the difference between NMP and 
protocols you mentioned for the management plane. Though there is maybe some 
overlap between the two types of protocols, the protocols you mentioned is not 
enough for monitoring the control protocol. For example, would we like to use 
YANG and NETCONF, RESTCONF, or gNMI to export the packets of control protocols 
such as update message of BGP and/or ISIS PDU, etc. for the purpose of 
monitoring?


Operators and vendors are doing this anyway. A second alternative would 
be to listen passively in IS-IS (or OSPF for that matter). Why would anyone 
want this? 
[Robin] In fact we tried the method you proposed. From our point of 
view, the basic design principle should be that the monitoring entity should be 
decoupled from the monitored entity. This is to avoid following cases:
1. The failure of operation of the control protocol may affect the 
monitoring at the same time.
2. The limitation of the control protocol will also have effect on the 
monitoring. For example, for the method of listening passively, if there are 
multiple hops between the listener and the network devices, it has to set up a 
tunnel as the virtual link for direct connection. But the TCP-based monitoring 
protocol need not care about it. 


As far as where it belongs, we have a rather full agenda in LSR so I 
don't think we want to devote time to it there at IETF 102.  
[Robin] Though the WG the draft should belong to is not determined yet, 
we think the work belongs to OPS area and send the notice to GROW WG and 
OPSAWG. We also applied for the presentation in the two WGs. We should have 
copied the notice to the related WGs of RTG area. So the LSR WG and RTGWG WG 
mailing list are added. More comments and suggestions are welcome.

Thanks,
Acee



On 7/2/18, 8:20 AM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology 
Research Dept. NW)"  
wrote:

Dear GROW & OPSAWG WGs,

We have proposed a Network Monitoring Protocol (NMP) for the 
control plane OAM. NMP for ISIS is illustrated in this draft to showcase the 
benefit and operation of NMP. Yet, we haven't decided which WG it belongs to. 

   
Comments and suggestions are very welcome! 

Thank you!


Yunan Gu
Huawei Technologies Co. Ltd

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: 2018年7月2日 20:07
To: Zhuangshunwan ; Lizhenbin 
; Guyunan (Yunan Gu, IP Technology Research Dept. NW) 

Subject: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt


A new version 

Re: [Lsr] [mpls] Comments on draft-ietf-mpls-spring-entropy-label

[Jeff Tantsura]

Hi,

 

Please see inline (MSD section).

Hope this clarifies, thanks!

 

Cheers,

Jeff

 

 

 

[jeff] both IGP drafts have identical description of the BMI-MSD:

“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS labels a 
node is capable of imposing, including all service/transport/special labels.”

PCEP draft supports only a subset of overall MSD functionality and in general 
it is expected that this info would come from IGPs(BGP-LS).

However the functoriality provided by PCEP is inline with the  BMI-MSD 
definition in the IGP drafts, at the node granularity only though. 

 

 

3. Section 5 introduces the MSD concept. I wonder whether this concept is 
aligned with the MSD concept as defined in the PCEP-SR draft or the MSD concept 
as defined in the IGP-MSD draft. In PCEP-SR draft, it said "
The "Maximum SID Depth" (1
   octet) field (MSD) specifies the maximum number of SIDs (MPLS label
   stack depth in the context of this document) that a PCC is capable of
   imposing on a packet.
 
In the IGP-MSD draft, it said "
MSD of type 1 (IANA Registry), called Base MSD is used to signal the
   total number of SIDs a node is capable of imposing, to be used by a
   path computation element/controller.  "
 
If I understand it correctly, the MSD in this draft==the MSD in PCEP-SR 
draft==the Base MSD (i.e., the MSD of type 1), No?
 

[SLI] Today, the two IGP drafts does not seem to agree on the definition
ISIS says:” Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels a node is capable of imposing, including all

   service/transport/special labels.”
OSPF says:” MSD of type 1 (IANA Registry) is used to signal the number of SIDs a
   node is capable of imposing, to be used by a path computation

   element/controller and is only relevant to the part of the stack

   created as the result of the computation.”

 

MSD is just MSD is defines a maximum number of labels to be pushed. This is the 
definition we use and it is compliant with the one used in PCEP-SR:
“The "Maximum SID Depth" (1
   octet) field (MSD) specifies the maximum number of SIDs (MPLS label

   stack depth in context of this document) that a PCC is capable of

   imposing on a packet.”

 

As we also say: “This includes any kind of labels (service, entropy, 
transport...).”, we are compliant with the BMI-MSD defined in IS-IS.

 

 

 

Best regards,

Xiaohu
_
 
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.
___ mpls mailing list 
m...@ietf..org https://www.ietf.org/mailman/listinfo/mpls 

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

Re: [Lsr] [OPSAWG] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Jeff Tantsura]

Robin,

Einar pointed exactly right points, very little to add.
Let’s keep is-is (narrow) scope.
1. There’s operational state of the protocol - I don’t really see what’s
missing in IETF/OpenConfig YANG models that would nessesarily require new
work?
Please be specific in your answers

2. What’s in LSDB - to my understanding you are not looking at that?
Reading your draft - it only concerns operational state,  not the content,
so BMP is not really a comparable solution either...

Wrt gRPC and some other work being done by OpenConfig/open source community
- besides Einar’s points - we have got great working relationship with the
team working on these technologies, there are gRPC and gNMI drafts in RTGWG
that would be updated when the need arise.
Wrt performance - there’s significant amount of research/testing and
comparisons of gRPC vs most of other RPC solutions, at scale, we in
networking won’t reach in quite some time, I’d advice to look it up. We
could discuss other advantages of running on top of HTTPv2 separately.

Please note - I’m not judging your proposal, but trying to understand why,
we as the community should be spending time and effort on it, so far you
you didn’t manage to convince me.

Looking forward to your reply.

Thanks,
Jeff

On Thu, Jul 5, 2018 at 04:45 Einar Nilsen-Nygaard (einarnn) <
eina...@cisco.com> wrote:

> Robin,
>
> With respect to your points below:
>
>
>- #1 – The draft ISIS model doesn’t seem to have many lateral
>dependencies as far as I can see. And if it is incomplete from the
>perspective of monitoring the health of ISIS, then it should be extended.
>I’m not sure why it would be difficult to stabilise the definition?
>- #2 – This seems to be the same issue of an incomplete model. Can you
>clearly articulate any data that you think should be available that *cannot
>be modelled in YANG*?
>- #3 – Agreed that exporting high volume, low latency telemetry one
>the baseline transport suggested in ietf-netconf-yang-push would
>perhaps have issues. This is one of the reasons why transport extensibility
>is an explicit part of the draft.
>- #4 – IMO, as long as the encoding for data is clearly defined in an
>"open" way, then this is not really an issue yet. I still think we need to
>experiment with encodings, but I do not think an entirely new protocol will
>serve network operators.
>
>
> I’d also like to add to the last point and say that I do not think adding
> new protocols and new encodings will serve network operators well. Over the
> last few years operators have been making it clear that they want to
> simplify their interactions with the network, and not have more things they
> need to understand thrown at them. Acee isn’t suggesting deprecating BMP,
> and neither am I, but in at least two discussions with operators I have
> attended, when introduced to BMP, their initial reaction could be
> summarised as "this looks interesting, but why have you introduced
> *another* protocol for this?"
>
> I completely support identifying the use cases you have, but would really
> like to see us focus on rectifying any deficiencies we can identify with
> existing proposals, rather than dilute our efforts.
>
> Cheers,
>
> Einar
>
> On 5 Jul 2018, at 11:48, Lizhenbin  wrote:
>
> Hi Jeff,
> Before we propose the NMP idea, we carefully compared it with the existing
> NETCONF, gRPC and YANG models work:
> 1. Based on my experience in the YANG model work, it may be not
> satisfactory for these models does not define config/oper of all features
> of specific protocol and these models have much relation with each other
> and it is difficult to stabilize the definition.
> 2. For monitoring the control protocol, it is not enough based on the
> existing YANG models such as the packets of control protocol which should
> be monitored but not defined in YANG models.
> 3. Performance concern on the existing NETCONF.
> 4. Standardization of the existing gRPC.
>
> We would like to define the NMP based on the usecases. That is, a specific
> set of parameters exported by NMP can satisfy the purpose of a specific
> usecase. Thus the protocol can be deployed incrementally.
>
>
> Best Regards,
> Robin
>
>
>
> -Original Message-
> From: Jeff Tantsura [mailto:jefftant.i...@gmail.com
> ]
> Sent: Wednesday, July 04, 2018 5:15 AM
> To: Acee Lindem (acee) ; Lizhenbin <
> lizhen...@huawei.com>; g...@ietf.org; ops...@ietf.org
> Cc: lsr@ietf.org; rt...@ietf.org; Guyunan (Yunan Gu, IP Technology
> Research Dept. NW) 
> Subject: Re: [Lsr] [GROW] FW: New Version Notification for
> draft-gu-network-mornitoring-protol-00.txt
>
> Robin,
>
> Pretty much same comment as Acee - I'm not cle

Re: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-13.txt

[Jeff Tantsura]

Folks,

The only update is the correct name for the registry - from "MSD Types" to "IGP 
MSD Types"

Cheers,
Jeff

On 7/24/18, 15:51, "lsr-boun...@ietf.org on behalf of 
internet-dra...@ietf.org"  wrote:


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   : Signaling MSD (Maximum SID Depth) using IS-IS
    Authors : Jeff Tantsura
  Uma Chunduri
  Sam Aldrin
  Les Ginsberg
Filename: draft-ietf-isis-segment-routing-msd-13.txt
Pages   : 9
Date: 2018-07-24

Abstract:
   This document defines a way for an IS-IS Router to advertise multiple
   types of supported Maximum SID Depths (MSDs) at node and/or link
   granularity.  Such advertisements allow entities (e.g., centralized
   controllers) to determine whether a particular SID stack can be
   supported in a given network.  This document only defines one type of
   MSD maximum label imposition, but defines an encoding that can
   support other MSD types.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-isis-segment-routing-msd-13
https://datatracker.ietf.org/doc/html/draft-ietf-isis-segment-routing-msd-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-segment-routing-msd-13


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.

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

Re: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

[Jeff Tantsura]

Not going to repeat all the comments made before, +1

Regards,
Jeff

> On Jul 24, 2018, at 23:08, Tony Przygienda  wrote:
> 
> pretty obvious +1 here 
> 
> --- tony 
> 
>> On Tue, Jul 24, 2018 at 3:41 AM Rob Shakir  wrote:
>> +1 to Peter. We should not define fragile solutions within the IETF.
>> 
>> There are also a multitude of other solutions here already:
>> 
>> 1) IGP adjacency with one router in each area (at a minimum - probably two 
>> for a robust system) over a tunnel. Deployed in many networks for years. 
>> 2) BGP-LS to one router (ditto robustness comment) in each area. 
>> 3) streaming telemetry of the LSDB contents via gNMI.
>> 
>> All these solutions exist in shipping implementations - please let’s not add 
>> to the system complexity of the IGP here.
>> 
>> r. 
>>> On Mon, Jul 23, 2018 at 12:30 Peter Psenak 
>>>  wrote:
>>> Hi Aijun,
>>> 
>>> On 23/07/18 13:07 , Aijun Wang wrote:
>>> > Hi, Peter:
>>> > 
>>> > For routers that connected by LAN, the router will establish adjacent
>>> > neighbor with DR, but not only DR advertises the connected prefixes. 
>>> 
>>> only the Network LSA includes the network mask, other routers would
>>> include the interface address only.
>>> 
>>> 
>>> > DR and
>>> > DRother will all advertise type 1 and type 2 LSA with each other, then the
>>> > process and proposal described in this draft will still work.
>>> > We seldom use the ip unnumbered features in our network, can we ignore it
>>> > then? Or other persons has some idea on such situation?
>>> 
>>> the fact that you do not use unnumbered is not really relevant. IETF
>>> defines solutions that MUST work for all possible scenarios, not only
>>> for a specific one.
>>> 
>>> > Anycast prefixes are often /32 long, this can be easily filtered by SDN
>>> > controller because the link prefixes between two routers will be no larger
>>> > than /32 for IPv4 network.
>>> 
>>> protocol allows to advertise the same prefix with an arbitrary mask from
>>> multiple routers without these routers being directly connected. Your
>>> proposal is based on the assumptions that are incorrect.
>>> 
>>> thanks,
>>> Peter
>>> 
>>> > 
>>> > Best Regards.
>>> > 
>>> > Aijun Wang
>>> > Network R&D and Operation Support Department
>>> > China Telecom Corporation Limited Beijing Research Institute,Beijing, 
>>> > China.
>>> > 
>>> > -邮件原件-
>>> > 发件人: Peter Psenak [mailto:ppsenak=40cisco@dmarc.ietf.org]
>>> > 发送时间: 2018年7月23日 18:20
>>> > 收件人: Aijun Wang; 'Peter Psenak'; cho...@chopps..org
>>> > 抄送: lsr@ietf.org; 'Ketan Talaulikar (ketant)'; 'Acee Lindem (acee)';
>>> > 'Dongjie (Jimmy)'
>>> > 主题: Re: [Lsr] 答复: Regarding OSPF extension for inter-area topology
>>> > retrieval
>>> > 
>>> > Hi Aijun,
>>> > 
>>> > On 23/07/18 11:16 , Aijun Wang wrote:
>>> >> Hi, Peter:
>>> >>
>>> >> Actually, I consider mainly the point-to-point connection and the
>>> >> numbered interface, which are normal in our network.
>>> >> For the two situations that you mentioned, I will investigation the
>>> >> possible solutions and feedback you later.
>>> >>
>>> >> For the point-to-point and numbered interface, do you have other
>>> >> questions then?
>>> > 
>>> > the fact that two routers announce the same subnet, does not mean they are
>>> > connected together by p2p link. Anycast prefix is an example.
>>> > 
>>> > The idea you are proposing simply does not work.
>>> > 
>>> > thanks,
>>> > Peter
>>> > 
>>> > 
>>> >>
>>> >> Best Regards.
>>> >>
>>> >> Aijun Wang
>>> >> Network R&D and Operation Support Department China Telecom Corporation
>>> >> Limited Beijing Research Institute,Beijing, China.
>>> >>
>>> >> -邮件原件-
>>> >> 发件人: Peter Psenak [mailto:ppsenak=40cisco@dmarc.ietf.org]
>>> >> 发送时间: 2018年7月23日 16:15
>>> >> 收件人: Aijun Wang; cho...@chopps.org
>>> >> 抄送: lsr@ietf.org; 'Ketan Talaulikar (ketant)'; 'Acee Lindem (acee)';
>>> >> 'Dongjie (Jimmy)'
>>> >> 主题: Re: [Lsr] Regarding OSPF extension for inter-area topology
>>> >> retrieval
>>> >>
>>> >> Hi Aijun,
>>> >>
>>> >> you are trying to reconstruct the topology of the remote area based on
>>> >> the fact that two routers are connected to the same subnet. It does
>>> >> not work
>>> >> because:
>>> >>
>>> >> 1. connections between routers can be unnumbered 2. routers can be
>>> >> connected via LAN, in which case only DR announces the prefix.
>>> >>
>>> >> In summary, what you propose does not work.
>>> >>
>>> >> thanks,
>>> >> Peter
>>> >>
>>> >>
>>> >>
>>> >> On 23/07/18 09:49 , Aijun Wang wrote:
>>> >>> (Sorry for my previous mail sent wrongly to the IDR mail list, please
>>> >>> reply on this thread within the LSR wg)
>>> >>>
>>> >>> Hi, Peter:
>>> >>>
>>> >>> I am Aijun Wang from China Telecom, the author of draft about “OSPF
>>> >>> extension for inter-area topology retrieval”
>>> >>> >> >>> l ogy-ext/>, which is presented by Mr.Jie Dong during the IETF102
>>> >>> meeting.
>>> >>>
>>> >>> Thanks for your comments 

Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

[Jeff Tantsura]

+1
Nothing really to add to Les’ comments 

Regards,
Jeff

> On Aug 3, 2018, at 09:32, Les Ginsberg (ginsberg) 
>  wrote:
> 
> Bruno –
>  
> I appreciate why you suggest per-prefix signaling for ELC, but I would prefer 
> that we not employ that model.
>  
> ELC is clearly a node capability – signaling it in per node scope is 
> therefore most appropriate. And it aligns with the SR model where we do not 
> need to depend on hop-by-hop signaling as in the LDP case.
>  
> As regards the interarea issues you raise:
>  
> Both Router Capability TLV (IS-IS) and Router Information LSA (OSPF) support 
> domain-wide flooding scope. This is not a new capability – though I do agree 
> with you that the ELC drafts should explicitly mention the flooding scope 
> requirement.
>  
> As regards identifying the source of a prefix advertisement domain-wide, 
> IS-IS has a complete solution for this as defined in RFC 7794.
> OSPF is lacking support for advertising the source Router-ID, but this can be 
> easily remedied by defining an extension using Extended Prefix LSA (as has 
> been mentioned by Peter in another thread). And this functionality is needed 
> for other reasons e.g., to know when PHP should/should not be done. So it is 
> probably past time when this should be defined.
>  
> So I think it is better if we use the per-node ELC scope proposed in the ELC 
> drafts.
>  
> As an aside, I would prefer that we utilize the existing TE Node Capability 
> Descriptor registry defined in RFC 5073 rather than invent a new 
> codepoint/registry (the proposed Non-IGP Functional  Capabilities registry) – 
> but that is a minor point.
>  
>Les
>  
>  
> From: Lsr  On Behalf Of bruno.decra...@orange.com
> Sent: Friday, August 03, 2018 12:46 AM
> To: 徐小虎(义先) 
> Cc: lsr@ietf.org; draft-ietf-isis-mpls-...@ietf.org
> Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt
>  
> Hi  Xiaohu,
>  
> Thanks for the reply.
> You seem to assume/require that (router) capability advertisement be 
> propagated across IGP areas/domains. If so,
> - this is a new requirement for existing multi-area networks that need to be 
> indicated in the draft
> - I find this debatable. This point should be explicitly discussed. I’d 
> rather advertise the ELC capability on a per Segment basis. This would also 
> be better aligned with RFC 6790 hence safer if EL extensions are defined.. 
> The (Segment Routing) Prefix-SID sub-TLV has 2 flags remaining. This may be a 
> good candidate as this information seems SR specific. Alternatively, RFC7794 
> may be used.
>  
> Thanks
> Best regards,
> --Bruno
>  
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of ???(??)
> Sent: Friday, August 03, 2018 4:13 AM
> To: Lsr; draft-ietf-isis-mpls-...@ietf.org
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt
>  
> Hi Bruno,
>  
> Thanks for raising this important issue.
>  
> In fact, the Routable IP Address TLVs/sub-TLVs as described in 
> (https://tools.ietf.org/html/draft-ietf-ospf-routable-ip-address-02) and 
> (https://tools..ietf.org/html/draft-xu-isis-routable-ip-address-01) 
> respectively were intended to address the problem that you had mentioned 
> (i.e., it is required for OSPF routers in one area to find correlations 
> between routable IP addresses and capabilities of OSPF routers in another 
> area). 
>  
> The following text is quoted from 
>  
> "There are several situations where it is required for OSPF routers in
>one area to find correlations between routable IP addresses and
>capabilities of OSPF routers in another area.  One example is the
>Entropy Label Capability (ELC) advertisement [I-D.xu-ospf-mpls-elc]
>across the OSPF domain.  In this example, assume the ELC TLV
>originated by a router in one area is propagated to another area.
>Those routers in the latter area need to find routable IP addresses
>of the router originating that ELC TLV before inserting the Entropy
>Label (EL) for packets going to the Label Switch Path (LSP) tunnel
>towards one of the above routable IP addresses..."
>  
> Later, such correlation requirement in the ISIS domain was addressed by 
> introducing the source IPv4/IPv6 router ID sub-TLVs into the Extended 
> Reachability TLVs (see https://tools.ietf.org/html/rfc7794). I forget whether 
> the same extension to OSPF as RFC7794 has been done. 
>  
> Best regards,
> Xiaohu
> --
> From:bruno.decraene 
> Send Time:2018年8月3日(星期五) 04:50
> To:draft-ietf-isis-mpls-...@ietf.org 
> Cc:lsr@ietf.org 
> Subject:Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt
>  
> Hi authors,
> 
> "4.  Advertising ELC Using IS-IS
> 
>One bit of the Non-IGP Functional Capability Bits (Bit 0 is desired)
>is to be assigned by the IANA for the ELC [RFC6790]."
> 
> RFC6790 defines ELC capability on a per FEC/LSP egress basis.
> Please defines what you mean exactly with this per node capabilit

Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

[Jeff Tantsura]

Stephane,

 

Leaving protocol semantics aside – do you see a real use cases for 
multi-area/multi-protocol scenarios? 

For all practical reasons (and to repeat Gunter’s comments) – this info is 
really of value for the controller, from distribution prospective, 
source->BGP-LS speaker, deployment wise, I believe most people strive to have a 
pair of BGP-LS speakers per area/level.

Area/level scoop would just good enough, don’t you think?

 

Thanks!

 

Cheers,

Jeff

 

From: Lsr  on behalf of "Les Ginsberg (ginsberg)" 

Date: Wednesday, August 8, 2018 at 16:54
To: "stephane.litkow...@orange.com" , "Van De 
Velde, Gunter (Nokia - BE/Antwerp)" , DECRAENE 
Bruno IMT/OLN 
Cc: "lsr@ietf.org" , "draft-ietf-isis-mpls-...@ietf.org" 
, "徐小虎 (义先)" 
Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

 

Stephane –

 

There are some issues you raise that I think are easily resolved/agreed upon – 
some others that may require more discussion.

Responses inline.

 

From: stephane.litkow...@orange.com  
Sent: Monday, August 06, 2018 2:58 AM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
Les Ginsberg (ginsberg) ; DECRAENE Bruno IMT/OLN 

Cc: lsr@ietf.org; draft-ietf-isis-mpls-...@ietf.org; 徐小虎(义先) 

Subject: RE: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

 

Hi Gunter,

 

IMO, there are multiple cases to distinguish.

 

The basic case (Adj-SIDs & Prefix-SIDs, single area, single domain, single 
protocol):
ELC as a node property is a good thing. I personally do not see a use case to 
get some segments to be ELC and some others not to be ELCs.
 

[Les:] Good – I think there is general agreement on this point.

 

Multiarea case:
When prefixes are leaked from one area to the other, we are losing the per node 
properties (like the ERLD). If we want to get benefit of EL, the ingress node 
in one area should get the ELC status of nodes in the other areas.
One solution would be to propagate the ELC as part of the prefix advertisement 
(when the prefix is leaked). We are still losing the ERLD which may impact the 
loadbalancing (EL/ELI placement not efficient).
Another solution could be for the ingress node to retrieve the ERLD from 
another source of information like BGP-LS but that’s not trivial as the ingress 
must know the best route to the tail from the ABR point of view.
 

[Les:] There is no issue with multiarea.  Repeating some points made earlier in 
the thread:

 

Both IGPs have the ability to leak router capabilities/info between areas. 
Which means the node based attributes ELC and ERLD can be available domain-wide.

We also have the ability to leak source router-id with the leaked prefixes 
(OSPF has a gap here but we have a commitment to address that with a modest 
extension to the protocol – which needs to be done for multiple reasons.)

So all the information necessary is available in all areas.

 

Multiprotocol case:
It’s not really different than the multiarea case.
 

[Les:] Multiprotocol is quite different than multiarea.

In the case of multiprotocol we do not have the ability to know/advertise the 
original source router-id nor the node capabilities in the destination 
protocol. It is not even guaranteed that reachability to the router-id of the 
source protocol is available in the area of the destination protocol.

This is where a controller based solution is most advantageous as it has the 
ability to learn all of that information from all of the protocols enabled in 
the domain.

 

SRMS and SR-LDP stitching:
SR to LDP: the LDP tail-end may be ELC, if an SR ingress node wants to use an 
ELI/EL on top of the prefix SID associated to the LDP FEC, we need to propagate 
the ELC known from LDP (attached to the FEC) to the SR advertisement. The 
SR-LDP stitching node is not a tail-end node, it will do a label swap, not a 
pop then push. So an entropy label pushed by the SR ingress node will be 
carried to the tail-end LDP node. Am I wrong ?
LDP to SR: the stitching node knows if the tail-end SR node is ELC (through the 
IGP advertisement). It may propagate the ELC into LDP. All the prefixes of the 
tail-end SR node which are LDP FECs can get the ELC set if the SR tail-end node 
is ELC.
I do not see any strict prescription requirement for the LSP here.

 

[Les:] Here there is more room for differences of opinion.

One viewpoint is that SR-LDP interworking is a transition strategy. Any 
solution which attempts to exchange ELC/ELRD information between the SR<->LDP 
portions of the network will be “messy” and perhaps not worth the trouble as we 
hope that the transition will be “short-lived”.

 

Another viewpoint could be that if the transition period is long enough it may 
be useful to have such support.

 

But as any solution (even if we were to advertise ELC per prefix) would be 
non-trivial, I think there needs to be a strong case for taking this on.

Do you believe we have a strong case here? 

 

Binding SID:
Binding SID associated to an SRTE LSP: if an ingress node wants to

Re: [Lsr] AD Review of draft-ietf-isis-segment-routing-msd-13

[Jeff Tantsura]

I’m almost ready with OSPF,  let’s take it from there

 

Cheers,

Jeff

 

From: "Les Ginsberg (ginsberg)" 
Date: Wednesday, August 15, 2018 at 15:51
To: Alvaro Retana , 
"draft-ietf-isis-segment-routing-...@ietf.org" 

Cc: "lsr-cha...@ietf.org" , "lsr@ietf.org" , 
Christian Hopps 
Subject: RE: AD Review of draft-ietf-isis-segment-routing-msd-13
Resent-From: 
Resent-To: Jeff Tantsura , , 
, 
Resent-Date: Wed, 15 Aug 2018 15:51:43 -0700 (PDT)

 

Alvaro –

 

A very thorough review – thanx.

 

Jeff has the pen – but I think he is on holiday at the moment – so there may be 
a short delay as regards a new version.

I will confine myself to comments on the non-editorial issues.

Inline.

 

From: Alvaro Retana  
Sent: Wednesday, August 15, 2018 1:53 PM
To: draft-ietf-isis-segment-routing-...@ietf.org
Cc: lsr-cha...@ietf.org; lsr@ietf.org; Christian Hopps 
Subject: AD Review of draft-ietf-isis-segment-routing-msd-13

 

Dear authors:

 

I just finished reading this document.  I have several comments and concerns 
that I included inline below.

 

One item that I want to highlight here is the lack of specific procedures 
defined to handle the cases of multiple advertisements (in both §2 and §3).  
Please take a look at my specific comments below -- in short, a clear 
specification is required for proper interoperability.  I will wait for (at 
least) this item to be addressed before starting the IETF LC.

 

Thanks!

 

Alvaro.

 

 

 

[The line numbers came from the idnits output.]

 



76   1.  Introduction



95 links in the network MSD is relevant, MSD capabilites should be

96 advertised by every IS-IS router in the network.

 

[nit] s/capabilites/capabilities

 



109   or SIDs associated with another dataplane e.g., IPv6.  Although MSD

110   advertisements are associated with Segment Routing, the

111   advertisements MAY be present even if Segment Routing itself is not

112   enabled.

 

[minor] Given that you're using Normative language...  It would be nice if you 
expanded on the use of the MSD in a non-SR network.  Something simple such as 
"a SID and a label are the same thing" would be enough.

 

114 1.1.  Conventions used in this document

 

116 1.1.1.  Terminology

 

[minor] Except for BMI/MSD, the other terms are not definitions, just 
expansions.  Some of the abbreviations are already included in the RFC Editor 
Abbreviations List [1].  In general, it would be better to just expand on first 
use (BGP-LS, for example, is used *before* this section) than to have this 
section with expansions.

 

[1] https://www.rfc-editor.org/materials/abbrev.expansion.txt

 



147 2.  Node MSD Advertisement



156  0   1

157  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

 

159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

160 |Type   |   Length  |

161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

162 |   MSD-Type| MSD Value |

163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

164 // ... //

165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

166 |   MSD-Type| MSD Value |

167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

169Figure 1: Node MSD Sub-TLV

 

171   Type: 23 (allocated by IANA via the early assignment process)

 

173   Length: variable (minimum of 2, multiple of 2 octets) and represents

174   the total length of value field.

 

[nit] ...in octets (?).

 

176   Value: field consists of one or more pairs of a 1 octet MSD-Type and

177   1 octet MSD-Value.

 

[nit] There is no "Value" field illustrated above.  You might want to reword a 
little.

 

[nit] The figure says "MSD Value", but the text talks about "MSD-Value".

 



191   If there exist multiple Node MSD advertisements for the same MSD-Type

192   originated by the same router, the procedures defined in [RFC7981]

193   apply.

 

[major] Does this text refer to multiple node MSD sub-TLVs (inside the same, or 
different, IS-IS Router CAPABILITY TLV), or to the same MSD-Type (included 
multiple times in a node MSD sub-TLV), or both?

 

[Les:] It really doesn’t matter. If you have two advertisements for the same 
MSD type from the same source then the procedures defined in RFC 7981 apply. It 
does not matter whether you find the advertisements in the same sub-TLV, in the 
same Router Capabilities TLV but different sub-TLVs, or in different Router 
Capabilities TLVs(sic).

 

 

 

[major] The only relevant text I can find in rfc7981 is this:

 

   Where a receiving system has two copies of an IS-IS Router CAPABILITY

   TLV from the same system that have conflicting information for a

   given sub-TLV, the procedure used to choose which copy shall be used

   is undefined.

 

Re: [Lsr] LSR Working Last Call for draft-ietf-ospf-yang

[Jeff Tantsura]

Acee,

 

The draft is in good shape, support.

 

Cheers,

Jeff

 

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Friday, August 17, 2018 at 13:09
To: "lsr@ietf.org" 
Subject: [Lsr] LSR Working Last Call for draft-ietf-ospf-yang

 

This begins an LSR WG last call for the subject draft. Please send your

comments to this list prior to 12:00 AM GMT, September 8th, 2018.

 

Given the size of the model and the US Labor Day Holiday, we’re allowing a full 
3 weeks. 

 

For your convenience, here is a URL:

 

https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/

 

Note there is one obsolete reference left as an exercise for the reviewers. 
Note that the document has already been through a couple YANG doctor reviews. 

 

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] AD Review of draft-ietf-ospf-segment-routing-msd-15

[Jeff Tantsura]

Dear Alvaro,

 

V16 of the draft has been posted addressing your comments – subject to my 
responses previously sent.

Please let us know if this is sufficient or you still have concerns which need 
to be addressed.

 

Cheers,

Jeff

 

From: Alvaro Retana 
Date: Wednesday, August 15, 2018 at 13:53
To: 
Cc: , , "Acee Lindem (acee)" 

Subject: AD Review of draft-ietf-ospf-segment-routing-msd-15
Resent-From: 
Resent-To: Jeff Tantsura , , 
, 
Resent-Date: Wed, 15 Aug 2018 13:53:45 -0700 (PDT)

 

Dear authors:

 

I just finished reading this document.  I have several comments and concerns 
that I included inline below.

 

While I do have some significant concerns (see below), I don't think there are 
specific items that prevent the start of the IETF LC (they should not be hard 
to address), so I'm getting that underway.  However, given the close 
relationship to and dependency on draft-ietf-isis-segment-routing-msd, I will 
schedule both of them on the same IESG Telechat.

 

Thanks!

 

Alvaro.

 

 



76 1.  Introduction

 

78When Segment Routing(SR) paths are computed by a centralized

79controller, it is critical that the controller learns the Maximum 
SID

80Depth(MSD) that can be imposed at each node/link on a given SR 
path

81to insure that the SID stack depth of a computed path doesn't 
exceed

82the number of SIDs the node is capable of imposing.

 

[nit] s/Depth(MSD)/Depth (MSD)

 

84The PCEP SR extensions draft [I-D.ietf-pce-segment-routing] 
signals

85MSD in SR PCE Capability TLV and METRIC Object.  However, if PCEP 
is

86not supported/configured on the head-end of an SR tunnel or a

87Binding-SID anchor node and controller do not participate in IGP

 

[nit] s/and controller do not participate/and the controller does not 
participate

 

88routing, it has no way to learn the MSD of nodes and links.  
BGP-LS

89[RFC7752] defines a way to expose topology and associated 
attributes

90and capabilities of the nodes in that topology to a centralized

91controller.  MSD signaling by BGP-LS has been defined in

92[I-D.ietf-idr-bgp-ls-segment-routing-msd].  Typically, BGP-LS is

93configured on a small number of nodes that do not necessarily act 
as

94head-ends.  In order for BGP-LS to signal MSD for all the nodes 
and

95links in the network MSD is relevant, MSD capabilites should be

96advertised by every OSPF router in the network.

 

[nit] s/capabilites/capabilities

 



108  or SIDs associated with another dataplane e.g., IPv6.  Although MSD

109  advertisements are associated with Segment Routing, the

110  advertisements MAY be present even if Segment Routing itself is not

111  enabled.

 

[minor] Given that you're using Normative language...  It would be nice if you 
expanded on the use of the MSD in a non-SR network.  Something simple such as 
"a SID and a label are the same thing" would be enough.

 

113   1.1.  Conventions used in this document

 

115   1.1.1.  Terminology

 

[minor] Except for BMI/MSD, the other terms are not definitions, just 
expansions.  Some of the abbreviations are already included in the RFC Editor 
Abbreviations List [1].  In general, it would be better to just expand on first 
use (BGP-LS, for example) is used *before* this section than to have this 
section with expansions.

 

[1] https://www.rfc-editor.org/materials/abbrev.expansion.txt

 



152   2.  Node MSD Advertisement

 

154  The node MSD TLV within the body of the OSPF RI Opaque LSA is 
defined

 

[nit] A reference to rfc7770 would be nice.

 

155  to carry the provisioned SID depth of the router originating the RI

156  LSA.  Node MSD is the smallest MSD supported by the node on the set

157  of interfaces configured for use by the advertising IGP instance.

158  MSD values may be learned via a hardware API or may be 
provisioned..

 

160   0   1   2   3

161   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

 

163  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

164  |Type   | Length   
 |

165  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

166  | MSD Type and Value ...

167  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

 

169     Figure 1: Node MSD TLV

 

[nit] It would be nicer to display the actual pairs:

 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|   MSD-Type| MSD-Value |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

 

171    

Re: [Lsr] LSR Working Last Call for draft-ietf-ospf-yang

[Jeff Tantsura]

Tom,

Many thanks, great comments (as always)!

Regards,
Jeff

> On Aug 22, 2018, at 08:41, tom petch  wrote:
> 
>  Original Message -
> From: "Jeff Tantsura" 
> Sent: Friday, August 17, 2018 9:14 PM
> 
> Acee,
> 
> The draft is in good shape, support.
> 
> 
> 
> Mmm that sounds like a good challenge.  I had a quick look and noticed:
> 
> - NMDA gets discussed in s.2.1; I like to see support for it mentioned
> earlier, in Abstract and Introduction, something I have seen the IESG
> request recently
> 
> - there is no explanation of the legend used in the tree diagrams; if
> appropriate, this can be fixed with an Informative Reference to RFC8340
> 
> - s.2.4 NSR needs expanding IMHO
> 
> - s.2.4 I would like a list of features, all 20 of them, not just
> "such as NSR, max-LSA, etc"
> so I don't have to reverse engineer the YANG module to find them; as and
> when new features come along, I expect there will be a delay before they
> make it into YANG so a clear list for those supported by this module
> would be useful
> 
> - sometimes it is 'link state database ', sometimes 'Link State
> Database', sometimes 'Link State database'; I would like consistency
> (and prefer the capitalised version)
> 
> - the YANG module as
> version 1.1
> but RFC7950 is not mentioned or referenced; odd
> 
> - the YANG module has
> RFC 5178 - OSPFv3 Graceful Restart";
> which I think should be RFC 5187
> 
> - the YANG module has
> "RFC  - YANG Data Model for Bidirectional Forwarding Detection
> (BFD)";
> "RFC : A YANG Data Model for OSPF.";
> "RFC  - SPF Back-off algorithm for link state IGPs";  RFC8405
> reference "draft-ietf-bfd-yang-xx.txt:
> 
> I suggest using a larger namespace than ''; perhaps '' and
> '' (since  "RFC  - SPF Back-off algorithm for link state IGPs"
> is in fact RFC8405 and is already in the Normative References) along
> with a note to the RFC Editor telling them what '' and '' should
> be replaced with.
> 
> reviewing the technical bits is going to be a challenge; I struggle to
> interpret such as
> when "derived-from("
>+ "../../../../../areas/area[area-id=current()/../area-id]/"
>+ "area-type, 'stub-nssa-area')" {
> or
> refine "version/ospfv2/ospfv2" {
>   must "derived-from-or-self( "
>  + "../../../../../../../../../../"
>  + "rt:type, 'ospf:ospfv2')" {
> description "OSPFv2 LSA.";
> 
> I note the use of "derived-from-or-self " as opposed to "derived-from "
> but it will take me longer to work out if the usage is appropriate.
> 
> Tom Petch
> 
> Cheers,
> 
> Jeff
> 
> 
> 
> From: Lsr  on behalf of "Acee Lindem (acee)"
> 
> Date: Friday, August 17, 2018 at 13:09
> To: "lsr@ietf.org" 
> Subject: [Lsr] LSR Working Last Call for draft-ietf-ospf-yang
> 
> 
> 
> This begins an LSR WG last call for the subject draft. Please send your
> 
> comments to this list prior to 12:00 AM GMT, September 8th, 2018.
> 
> 
> 
> Given the size of the model and the US Labor Day Holiday, we’re allowing
> a full 3 weeks.
> 
> 
> 
> For your convenience, here is a URL:
> 
> 
> 
> https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/
> 
> 
> 
> Note there is one obsolete reference left as an exercise for the
> reviewers. Note that the document has already been through a couple YANG
> doctor reviews.
> 
> 
> 
> 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] LSR WG Adoption Poll for "Restart Signaling for IS-IS" - draft-ginsberg-isis-rfc5306bis-01

[Jeff Tantsura]

Acee,

I support the adoption and quick progress of this, clear and useful document..

Regards,
Jeff

> On Aug 22, 2018, at 06:42, Acee Lindem (acee) 
>  wrote:
> 
> This draft has been presented several times and I believe there is general 
> agreement that IS-IS graceful restart signaling enhancements are useful for 
> the case of planned restart.
>  
> This begins the WG adoption poll for 
> https://www.ietf.org/id/draft-ginsberg-isis-rfc5306bis-01.txt. It will end on 
> 12:00 AM GMT on September 6th, 2018..
>  
> 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 Flooding Reduction Drafts - Moving Forward

[Jeff Tantsura]

+1 Tony

We could start with a document, similar to dc-routing requirements one we did 
in RTGWG before chartering RIFT and LSVR.
Would help to disambiguate requirements from claims and have apple to apple 
comparison.
Doing it on github was a good experience.


Regards,
Jeff

> On Aug 22, 2018, at 09:27, Tony Li  wrote:
> 
> 
> 
>> At IETF 102, there was no dearth of flooding reduction proposals.  In fact, 
>> we have so many proposals that there wasn’t agree as how to move forward and 
>> we agreed to discuss on the list. This Email is to initiate that discussion 
>> (which I intend to participate in but as a WG member). 
> 
> 
> Hi Acee,
> 
> Perhaps a useful starting point of the discussion is to talk about 
> requirements.  There seem to many different perceptions.
> 
> 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] LSR Flooding Reduction Drafts - Moving Forward

[Jeff Tantsura]

Les,

 

Not going to repeat Tony P. points, however I don’t think anyone said – 
requirement document should be a gating factor,  personally, I’d do it same way 
we did in RTGWG – to have a unbiased reference point others can reference to. 
Development of such document should go in parallel with other work and be a 
wg/design team effort. 

 

Hope this clarifies.

 

Cheers,

Jeff

 

From: "Les Ginsberg (ginsberg)" 
Date: Wednesday, August 22, 2018 at 13:10
To: Tony Przygienda 
Cc: Jeff Tantsura , Tony Li , 
"lsr@ietf.org" , "Acee Lindem (acee)" 
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

 

Tony –

 

The points you make below are good and need to be considered.

 

But let’s examine what work we have that we could do now.

 

1)draft-li-dynamic-flooding

 

This defines modest protocol extensions to support use of flooding reduction 
algorithms in  any type of topology. Note that it does not (not yet anyway…) 
specify any algorithms.

Adopting this draft would allow us to define the extensions necessary to enable 
the use of alternate algorithms and to get immediate benefits from the use of 
some well known algorithms. Since it does not preclude (and is a necessary 
infra for)  the use of any algorithm, and it allows support for many algorithms 
(NOT simultaneously though J ) it does not prevent any future algorithmic 
solutions from being used.

 

In parallel with this, discussion/research of points such as you mention below 
can be done, but I do not see why we should not proceed with this work 
immediately. 

 

2)Flooding reduction drafts specific to Clos topologies

 

There are multiple candidates – and I am obviously biased since I have a horse 
in the race (draft-shen-isis-spine-leaf-ext),  but the point is we have 
proposals that have practical benefits and have received support. So long as 
they are compatible with draft-li-dynamic-flooding I again do not see why these 
cannot move forward now.

 

Further research/discussion is a fine thing, but that should not prevent us 
from realizing real benefits now – especially since we can do so in a way that 
is future-proofed.

 

   Les

 

 

 

From: Tony Przygienda  
Sent: Wednesday, August 22, 2018 11:59 AM
To: Les Ginsberg (ginsberg) 
Cc: Jeff Tantsura ; Tony Li ; 
lsr@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

 

I do think it is a good idea in a sense to somehow outline WHAT problem is 
being solved via some write-down or mind-melt 

 

a) I hope it's captured in the meeting notes but otherwise running the danger 
of repeating myself, the problem splits along the line of "directed graphs" 
(basically lattices) which DC topologies are today and generic graphs. In first 
case problem can be solved quite well (Pascal's idea based loosely on MANET in 
RIFT that could be stretched to flat flooding as well), in 2nd it's much 
harder. 

b) Beside pure reduction, aspects like redundancy of the resulting mesh(es), 
minimal-cut properties and load balancing aspects emerge from practical pursuit 
of the problem (let's not even mention the dynamic re-convergence problems no 
matter whether some centralized instance floods or async distributed algorithm 
is run). Hence the scope or scopes of what needs being done seems prudent.

c) ultimately, other things like link properties and resulting meshes play a 
big role (MANET). In sparse networks we lived quite well without reduction but 
MANET/DSR had to deal with it already AFAIR & IP fabric seem to cause a 
different variation of the limitation to rear its head

 

2c

 

--- tony 

 

On Wed, Aug 22, 2018 at 11:04 AM Les Ginsberg (ginsberg) 
 wrote:

In the discussions which led to the creation of LSVR and RIFT WGs, considerable 
interest was expressed in working on enhancements to existing Link State 
protocols. You can peruse the dcrouting mailing list archives.

 

https://mailarchive.ietf.org/arch/browse/dcrouting/

 

It is rather befuddling to me that the IETF seems to have decided to move 
forward on two new protocols (no objection from me) but seems to feel there is 
insufficient reason to move forward on proposals to extend existing IGPs.

I think the suggestion that we need to write (yet another)  requirements 
document before doing so is a recipe for delay – not for progress.

 

Multiple drafts have been presented over the course of the past two years and 
discussed on the list as well.

In the case of two of the drafts:

 

draft-shen-isis-spine-leaf-ext

draft-li-dynamic-flooding

 

WG adoption was requested in Montreal..

 

Please explain why we cannot proceed with “business as usual” as regards these 
drafts.

 

 

   Les

 

 

From: Lsr  On Behalf Of Jeff Tantsura
Sent: Wednesday, August 22, 2018 9:43 AM
To: Tony Li 
Cc: lsr@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

 

+1 Tony

 

We cou

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Jeff Tantsura]

Naiming,

 

That’s would be the goal, not to boil the ocean (again)the constrain part would 
be “improvements on existing protocols”, since we are in LSR, perhaps further 
scoped to ISIS/OSPF.

 

Cheers,

Jeff

 

From: "Naiming Shen (naiming)" 
Date: Wednesday, August 22, 2018 at 12:19
To: "Les Ginsberg (ginsberg)" 
Cc: Jeff Tantsura , Tony Li , 
"lsr@ietf.org" , "Acee Lindem (acee)" 

Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

 

 

I do think to solve all the data centers (massive or small) requirement, 

this discussion is very useful. If we can list all the requirements and see

what technical approaches we can do to achieve them.

 

But incremental improvements on existing protocols is useful also. They may not

solve the complete set of “requirements”, but they do help data center

and also non-data center deployments to improve their operations.

 

I would think this group can proceed with both approaches.

 

Regards,

- Naiming

 

On Aug 22, 2018, at 11:02 AM, Les Ginsberg (ginsberg) 
 wrote:

 

In the discussions which led to the creation of LSVR and RIFT WGs, considerable 
interest was expressed in working on enhancements to existing Link State 
protocols. You can peruse the dcrouting mailing list archives.

 

https://mailarchive.ietf.org/arch/browse/dcrouting/

 

It is rather befuddling to me that the IETF seems to have decided to move 
forward on two new protocols (no objection from me) but seems to feel there is 
insufficient reason to move forward on proposals to extend existing IGPs.

I think the suggestion that we need to write (yet another)  requirements 
document before doing so is a recipe for delay – not for progress.

 

Multiple drafts have been presented over the course of the past two years and 
discussed on the list as well.

In the case of two of the drafts:

 

draft-shen-isis-spine-leaf-ext

draft-li-dynamic-flooding

 

WG adoption was requested in Montreal.

 

Please explain why we cannot proceed with “business as usual” as regards these 
drafts.

 

 

   Les

 

 

From: Lsr  On Behalf Of Jeff Tantsura
Sent: Wednesday, August 22, 2018 9:43 AM
To: Tony Li 
Cc: lsr@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

 

+1 Tony

 

We could start with a document, similar to dc-routing requirements one we did 
in RTGWG before chartering RIFT and LSVR.

Would help to disambiguate requirements from claims and have apple to apple 
comparison.

Doing it on github was a good experience.

 

Regards,

Jeff


On Aug 22, 2018, at 09:27, Tony Li  wrote:

 




At IETF 102, there was no dearth of flooding reduction proposals.  In fact, we 
have so many proposals that there wasn’t agree as how to move forward and we 
agreed to discuss on the list. This Email is to initiate that discussion (which 
I intend to participate in but as a WG member). 

 

 

Hi Acee,

 

Perhaps a useful starting point of the discussion is to talk about 
requirements.  There seem to many different perceptions.

 

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

 

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

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Jeff Tantsura]

Peter,

As previously stated - I'm against gating, it should be developed in parallel 
and with cooperation with the ongoing/existing work.
Note - there's a document (albeit expired, it played its role) that talks about 
generic DC Routing requirements, work in LSR would be scooped to LSR only.
So no going into religious discussions - new vs old/ls vs pv, etc, but focusing 
on ospf/isis and what is needed for DC specifically.
I think it would be good to do some gain/complexity mental exercise...  

Cheers,
Jeff

On 8/23/18, 02:05, "Peter Psenak"  wrote:

Jeff, All,

we have added many extensions to IGP protocols over the years. Many 
times multiple solutions were proposed for the same or similar problem 
and WG picked from the set, many times multiple solutions were merged or 
combined together. We never asked for a requirement document. Even for 
more significant changes then we are talking about here.

I understand that the area of DC routing using IGPs is a broader area, 
but it does not fundamentally change IGPs to warrant the need for 
requirement document as a prerequisite to move forward with any work 
that is related to any optimization that may be applicable to DC 
environment.

So while I'm not against the existence of the document that would cover 
the requirements for IGPs in DC environments , I don't believe we should 
gate all proposed work in this space by such a document. And to be 
completely honest, the requirements are pretty straightforward for 
anyone that is familiar with the protocols' operation.

my 2c,
Peter

    On 22/08/18 18:42 , Jeff Tantsura wrote:
> +1 Tony
>
> We could start with a document, similar to dc-routing requirements one
> we did in RTGWG before chartering RIFT and LSVR.
> Would help to disambiguate requirements from claims and have apple to
> apple comparison.
> Doing it on github was a good experience.
>
>
> Regards,
> Jeff
>
> On Aug 22, 2018, at 09:27, Tony Li  <mailto:tony1ath...@gmail.com>> wrote:
>
>>
>>
>>> At IETF 102, there was no dearth of flooding reduction proposals.  In
>>> fact, we have so many proposals that there wasn’t agree as how to
>>> move forward and we agreed to discuss on the list. This Email is to
>>> initiate that discussion (which I intend to participate in but as a
>>> WG member).
>>
>>
>> Hi Acee,
>>
>> Perhaps a useful starting point of the discussion is to talk about
>> requirements.  There seem to many different perceptions.
>>
>> Regards,
>> Tony
>>
>>
>> ___
>> Lsr mailing list
>> Lsr@ietf.org <mailto:Lsr@ietf.org>
>> https://www..ietf.org/mailman/listinfo/lsr
>> <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] RtgDir review: draft-ietf-ospf-segment-routing-msd

[Jeff Tantsura]

Hi Tal,

 

Many thanks for your comments.

Updated draft has been published for your review.

 

Cheers,

Jeff

 

From: Tal Mizrahi 
Date: Monday, August 20, 2018 at 23:45
To: , , 
, 
Cc: , "Yemin (Amy)" 
Subject: RtgDir review: draft-ietf-ospf-segment-routing-msd
Resent-From: 
Resent-To: Jeff Tantsura , , 
, 
Resent-Date: Mon, 20 Aug 2018 23:45:53 -0700 (PDT)

 

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related drafts as 
they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.

Document: draft-ietf-ospf-segment-routing-msd 
Reviewer: Tal Mizrahi 
Review Date: 21-Aug-2018 
Intended Status: Standards Track

Summary: 

This document is basically ready for publication, but has a couple of minor 
issues and nits that should be resolved prior to publication.

Minor Issues:
Figure 1 seems to indicate that the MSD-Type and the MSD-Value are 2 octets 
long each, whereas according to the text afterwards each of the two fields is 1 
octet long.
Figure 2 – same comment.
Nits:
“provisioned..” --> “provisioned.” (extra period)
“Acknowledgements” --> “Acknowledgments”
“capabilites” --> “capabilities”
“the the” --> “the”
 

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

Re: [Lsr] New Version Notification for draft-wu-lsr-pce-discovery-security-support-00.txt

[Jeff Tantsura]

+1
Having actual key in the protocol  - similar issues as with BGP(see recent BGP 
discussion with Linda), would be a severe security risk.

Regards,
Jeff

> On Aug 25, 2018, at 10:41, Acee Lindem (acee) 
>  wrote:
> 
> Hi Qin, 
> 
> I believe it is a significant security exposure to include the actual keys in 
> IGPs. What I was suggesting was to include an identifier of the key to be 
> used.
> 
> Thanks,
> Acee
> 
> On 8/24/18, 10:56 PM, "Qin Wu"  wrote:
> 
>Hi, Acee:
>-邮件原件-
>发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
>发送时间: 2018年8月24日 22:23
>收件人: Qin Wu; lsr@ietf.org
>主题: Re: New Version Notification for 
> draft-wu-lsr-pce-discovery-security-support-00.txt
> 
>Hi Qin, 
> 
>On 8/23/18, 11:03 PM, "Qin Wu"  wrote:
> 
>Hi, Folks:
>draft-wu-pce-discovery-pceps-support-07 has been resubmitted to LSR as 
> draft-wu-lsr-pce-discovery-security-support-00 based on Chairs' suggestion.
>
> https://tools.ietf.org/html/draft-wu-lsr-pce-discovery-security-support-00
>This draft define IGP extension for PCEP security support, 
>1.TCP AO which has been published as RFC5295.
>2.PCEP over TLS which has been published as RFC8253 recently.
> 
>One issue raised by chair is shared key support for TCP-AO, how do you 
> get shared key?
> 
>I guess my point was is that if you are distributing shared keys, you 
> probably know whether or not TCP-AO is supported. Having said that, possibly 
> the draft should include some sort of key-id for TCP-AO or TLS usage. For 
> example, the key-chain name from RFC 8177. We don't need to decide now. 
> 
>[Qin]: RFC5088 " OSPF Protocol Extensions for PCE discovery" said:
>"
>   PCE discovery information is, by nature, fairly static and does not
>   change with PCE activity.  Changes in PCE discovery information may
>   occur as a result of PCE configuration updates, PCE
>   deployment/activation, PCE deactivation/suppression, or PCE failure.
>   Hence, this information is not expected to change frequently.
>"
>So security capability as part of PCE discovery information should also be 
> static. 
> 
>RFC5926 section 3.1 said:
>"
>In TCP-AO's manual key mode, this is a key shared by both peers, entered 
> via some interface to their
>respective configurations.  The Master_Key is used as the seed for the KDF.
>"
>My impression TCP-AO relies on manual installation for shared key. But TLS 
> has key management protocol to exchange shared key,e.g., one defined in 
> RFC4279.
>We can either negotiate shared key for TCP-AO in the PCE discovery phase 
> or during PCE configuration phase. For TLS usage, this is not needed, in my 
> opinion.
>To support shared key negotiation during PCE discovery phase, we need to 
> define a IGP PCED Sub-TLV for TCP-AO, I am not sure this is allowed according 
> to RFC5088,
>It looks this new IGP PCEP TLV is a companion Sub-TLV for PCE-CAP-FLAGS 
> Sub-TLV. 
>If adding a new Sub-TLV is allowed, we can add algorithm identifier and 
> key chain name,key identifier altogether.
> 
>If negotiating shared key during PCE configuration phase, it is clearly 
> beyond scope of this draft.
>Thanks,
>Acee 
> 
> 
>we believe to support TCP-AO, RFC5296 should also be implemented, 
> which provide PSK and associated ciphersuit.
>Let us know if you have any other opinion?
> 
>-Qin
>-邮件原件-
>发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
>发送时间: 2018年8月24日 10:57
>收件人: Daniel King; wangzitao; Dhruv Dhody; wangzitao; Diego R. Lopez; 
> Diego Lopez; Qin Wu
>主题: New Version Notification for 
> draft-wu-lsr-pce-discovery-security-support-00.txt
> 
> 
>A new version of I-D, 
> draft-wu-lsr-pce-discovery-security-support-00.txt
>has been successfully submitted by Qin Wu and posted to the IETF 
> repository.
> 
>Name:draft-wu-lsr-pce-discovery-security-support
>Revision:00
>Title:IGP extension for PCEP security capability support in 
> the PCE discovery
>Document date:2018-08-23
>Group:Individual Submission
>Pages:6
>URL:
> https://www.ietf.org/internet-drafts/draft-wu-lsr-pce-discovery-security-support-00.txt
>Status: 
> https://datatracker.ietf.org/doc/draft-wu-lsr-pce-discovery-security-support/
>Htmlized:   
> https://tools.ietf.org/html/draft-wu-lsr-pce-discovery-security-support-00
>Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-wu-lsr-pce-discovery-security-support
> 
> 
>Abstract:
>   When a Path Computation Element (PCE) is a Label Switching Router
>   (LSR) participating in the Interior Gateway Protocol (IGP), or even 
> a
>   server participating in IGP, its presence and path computation
> 

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

[Jeff Tantsura]

Gents,

Thanks for the great review!

Both drafts are on the Telechat tomorrow, would be great to come to the 
agreement, so ospf draft could be updated before tomorrow’s call.

Regards,
Jeff

> On Sep 26, 2018, at 13:21, Les Ginsberg (ginsberg)  wrote:
> 
> Julien -
> 
> Thanx for the additional comments.
> V17 has been published to address these - subject to my responses below.
> See Les2
> 
>> -Original Message-
>> From: rtg-dir  On Behalf Of Julien Meuric
>> Sent: Monday, September 24, 2018 8:12 AM
>> To: Les Ginsberg (ginsberg) ; rtg-...@ietf.org
>> Cc: lsr@ietf.org; rtg-...@ietf.org; draft-ietf-isis-segment-routing- 
>> m...@ietf.org
>> Subject: Re: [RTG-DIR] RtgDir Review: 
>> draft-ietf-isis-segment-routing-msd-15
>> 
>> Hi Les,
>> 
>> Thanks for you feedback. Please find some responses, marked [JM] below.
>> You may consider the trimmed ones as resolved. For others, please keep 
>> in mind that the directorate's purpose is to improve documents'
>> readability before publication, as opposed to store clarification in 
>> mailing list archives.
>> 
> [Les2:]  I fully appreciate both the purpose of the review and the effort you 
> have put in. Yours is one of the better reviews I have seen in my years...
> If I push back it is not because I do not value your input - but simply 
> because I disagree. :-)
> 
>> Julien
>> 
>> 
>> Sep. 24, 2018 - ginsb...@cisco.com:
>>> Julien -
>>> 
>>> Thanx for your detailed review - and your patience in waiting for a
>> response (I returned from vacation only a few days ago).
>>> 
>>> I have published V16 of the draft which addresses your comments 
>>> except
>> as noted inline below.
>>> 
>>> 
 -Original Message-
 From: Julien Meuric 
 Sent: Monday, September 10, 2018 8:28 AM
 
>> 
 
 - The abstract uses the acronym "SID", however:
* It should be expanded at first use,
* It should be defined, e.g. by adding a (normative) reference 
 to RFC 8402 (at least in the introduction),
* The SR context is missing and should be explicitly mentioned 
 (adding a phrase such as "in a Segment Routing-enabled network" 
 would
>> be enough).
>>> 
>>> [Les:] SID has been added to the terminology section and a reference 
>>> to
>> RFC 8402 added.
>>> However, I don’t think "SR context" is missing. The first sentence 
>>> of the Introduction starts with
>>> 
>>> " When Segment Routing (SR) paths are computed..."
>>> 
>> [JM] I fully agree about the introduction, but my comment was about 
>> the abstract where the SR context needs to be guessed from the use of 
>> the "SID" terminology: an explicit phrase would be welcome to a rookie 
>> reading the abstract.
>> 
> [Les2:] I have modified the abstract.
> 
 
 - OLD
   Path Computation Element Protocol (PCEP) SR extensions draft
   [I-D.ietf-pce-segment-routing] signals MSD in SR Path 
 Computation
   Element (PCE) Capability TLV and METRIC Object.
  NEW
   The Path Computation Element communication Protocol (PCEP) SR
   extension document [I-D.ietf-pce-segment-routing] defines how to
   signal MSD using the SR-PCE-CAPABILITY sub-TLV (per node) and
   the METRIC object (per request).
 
>>> [Les:] I have updated this and included a reference to RFC 5440 
>>> where
>> METRIC object was first defined.
>>> 
>> [JM] Even better about METRIC. Consistently, "SR Path Computation 
>> Element
>> (PCE) Capability TLV" still remains a loose phrase, the technical name 
>> from [I- D.ietf-pce-segment-routing] is "SR-PCE-CAPABILITY", which 
>> avoids ambiguity.
>> 
> 
> [Les2:] I removed naming the specific TLVs and replaced it with " Path  
> Computation Element Protocol (PCEP)".
> I think this is better than mentioning specific TLV names - particularly 
> since one of them is part of a draft and the TLV name might change before the 
> document becomes an RFC. So any possible naming inconsistency is now 
> eliminated.
> 
>>> 
 - The introduction says that the solution to complement BGP-LS lies 
 in IS-IS (the OSPF draft claiming the counterpart on its side). 
 This is a bit rough, the sentence 2 paragraph below already does 
 the necessary scoping job: "This document defines an extension to 
 >>> here>". I suggest to temper the early sentence by rephrasing the
 beginning of page 3 into: "MSD capabilities should be advertised by 
 every router in the network involved in the IGP."
 
>>> [Les:] The draft says
>>> 
>>> " MSD capabilities should be
>>>   advertised by every Intermediate System to Intermediate System(IS-IS)
>>>   router in the network."
>>> 
>>> which I believe meets your suggestion.
>>> 
>> [JM] My comment was exactly starting from there. Let me rephrase:
>> - This I-D says "should be advertised by every IS-IS router";
>> - draft-ietf-ospf-segment-routing-msd says "should be advertised by 
>> every OSPF router".
>> Now that we have a single LSR WG, I suggest to drop these competing 
>> wo

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

[Jeff Tantsura]

Gents,

I’m 100% with Les here, going into platform/asic specifics within this document 
would inevitably create ambiguity.

Cheers,
Jeff
On Oct 2, 2018, 11:20 AM -0700, Les Ginsberg (ginsberg) , 
wrote:
> Bruno –
>
> Trimming the thread…
>
> [Les2:] Label imposition is meant to cover both the SWAP operation and the 
> PUSH operation. In the example you provided above where a label stack of “12” 
> is replaced by a label stack of “14,15” the number of labels “imposed” is 2.
> [Bruno2] In that case, I definitely think that the discussion was useful and 
> that this point needs to be clarified in the document.
> Whether you choose to call that (1 POP, 2 PUSH) or (1 SWAP, 1 PUSH)  or 
> simply a SWAP isn’t relevant here (though it might matter to folks like the 
> RFC 3031 authors).
>
> With that ibn mind, here is proposed text:
>
> “Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
>    labels which can be imposed, including all service/transport/special
>    labels.  Imposition includes swap and/or push operations.
>
> If the advertising router performs label imposition in the context of
>    the ingress interface, it is not possible to meaningfully advertise
>    per link values.  In such a case only the Node MSD SHOULD be
>    advertised.”
>
> [Bruno2] Given that the term “imposition” does not seem to be defined within 
> the IETF, I would still favor a formal definition not using it. e.g. “BMI-MSD 
> advertises the ability to increase the depth of the label stack by BMI-MSD 
> labels”.
> Alternatively, I’d propose the following rewording which seems clearer to me:
> OLD: Imposition includes swap and/or push operations.
> NEW: A swap operation counts as an imposition of one label; just like one 
> push operation.
>
> [Les3:] This gets into implementation specific issues that I would really 
> like to avoid.
> For example, some implementations perform one and only one  “operation”. 
> Conceptually that may involve a swap and a push – but from the internal 
> implementation POV it is simply one operation. And this may be true 
> regardless of how many labels are involved. Other implementations might 
> perform this in several discrete steps. The language we use here should not 
> imply anything about how many labels are associated with a specific operation.
>
> The term “increase” isn’t accurate because in the case of a swap there is no 
> increase, yet the label which is replaced is counted.
>
> https://tools.ietf.org/html/rfc3031#section-3.10 is relevant here.
>
> The term “imposition” is generic – and as Alvaro has pointed out is used in 
> RFC 4221. And the language proposed above does define the relationship 
> between “swap and push” and “imposition”.
>
> I appreciate your desire for clarity – and I am still open to new language – 
> but at this point I still think what I proposed is  the most accurate.
>
>    Les
>
>
>
> Thanks,
> --Bruno
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] FW: New Version Notification for draft-ginsberg-lsr-isis-invalid-tlv-00.txt

[Jeff Tantsura]

Great stuff, long time due!

Cheers,
Jeff
On Oct 19, 2018, 12:23 PM -0700, Les Ginsberg (ginsberg) , 
wrote:
> Folks -
>
> This new draft discusses IS-IS protocol behaviors related to handling TLVs 
> that are either:
>
> o Not recognized/supported by an implementation
> o Present in a PDU where they are disallowed
> o The TLV encoding is invalid in some ways
>
> Inconsistent handling of these cases has been known to cause interoperability 
> issues.
>
> Comments are most welcome.
>
> Les
>
>
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Friday, October 19, 2018 11:46 AM
> To: Paul Wells (pauwells) ; Les Ginsberg (ginsberg) 
> 
> Subject: New Version Notification for 
> draft-ginsberg-lsr-isis-invalid-tlv-00.txt
>
>
> A new version of I-D, draft-ginsberg-lsr-isis-invalid-tlv-00.txt
> has been successfully submitted by Les Ginsberg and posted to the IETF 
> repository.
>
> Name: draft-ginsberg-lsr-isis-invalid-tlv
> Revision: 00
> Title: Invalid TLV Handling in IS-IS
> Document date: 2018-10-19
> Group: Individual Submission
> Pages: 7
> URL: 
> https://www.ietf.org/internet-drafts/draft-ginsberg-lsr-isis-invalid-tlv-00.txt
> Status: https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-invalid-tlv/
> Htmlized: https://tools.ietf.org/html/draft-ginsberg-lsr-isis-invalid-tlv-00
> Htmlized: 
> https://datatracker.ietf.org/doc/html/draft-ginsberg-lsr-isis-invalid-tlv
>
>
> Abstract:
> Key to the extensibility of the Intermediate System to Intermediate
> System (IS-IS) protocol has been the handling of unsupported and/or
> invalid Type/Length/Value (TLV) tuples. Although there are explicit
> statements in existing specifications, in some cases the expected
> behavior is "well known" but not explicitly stated.
>
> This document discusses the "well known behaviors" and makes them
> explicit in order to insure that interoperability is maximized.
>
> This document when approved updates RFC3563, RFC5305, and RFC6233.
>
>
>
>
>
> 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] 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

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] 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