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

2021-03-01 Thread Jeff Tantsura
In ol’ good RSVP-TE days we already used “severity/relevance indicator” to 
decide whether changes in link  attributes (BW/etc) are significant enough and 
should be propagated in into TED and trigger re-optimization/rerouting, this is 
no different,  define your threshold for a trigger.
Note - flex-also requires contiguous topology to work, self isolation as the 
result of (dynamic) topology re-computation would not be a great thing.

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


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

2021-02-17 Thread Jeff Tantsura
Yes/support

Cheers,
Jeff
On Feb 17, 2021, 7:30 AM -0800, Christian Hopps , wrote:
> Hi LSR and TEAS,
>
> This begins a joint WG last call for:
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/
>
> Please discuss any issues on the LSR mailing list. The WGLC will end March 3, 
> 2021.
>
> Authors, please indicate wether you are aware of any IPR related to this 
> document to the list.
>
> Thanks,
> Chris, Acee, (Lou and Pavan).
>
> ___
> Teas mailing list
> t...@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2021-01-22 Thread Jeff Tantsura
support adoption.

Cheers,
Jeff
On Jan 5, 2021, 1:20 AM -0800, Christian Hopps , wrote:
> This begins a 2 week WG adoption call for the following draft:
>
> https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/
>
> Please indicate your support or objection by January 19th, 2021.
>
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.
>
> Thanks,
> Chris.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2021-01-08 Thread Jeff Tantsura
yes/support

Cheers,
Jeff
On Jan 5, 2021, 1:17 AM -0800, Christian Hopps , wrote:
> This begins a 2 week WG adoption call for the following draft:
>
> https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-admin-tags/
>
> Please indicate your support or objection by January 19th, 2021.
>
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.
>
> Thanks,
> Chris.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2020-12-07 Thread Jeff Tantsura
Zhenqiang,

please see inline

Cheers,
Jeff


4. I want to know the path for a specific IP Flex-Algorithm is calculated 
distributedly by each nodes paticipating this Flex-Algorithm or calculated 
centralized by an controller? I wonder we can guarantee the loop free  path 
with IP Flex-Algorithm especially when the path is calculated distributedly?

The valid topology must consist of a set of connected routers sharing a common 
Calc-Type, then loop-free calculation is done accordingly


Best Regards,
Zhenqiang Li
li_zhenqi...@hotmail.com

From: Jeff Tantsura
Date: 2020-12-04 09:18
To: Tony Li; Robert Raszuk
CC: lsr; Acee Lindem \(acee\)
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Anything else than IGP metric based SPT is considered TE. Looking holistically 
- topology virtualization (or similar) could have been a better name.

Cheers,
Jeff
On Dec 3, 2020, 4:25 PM -0800, Robert Raszuk , wrote:
Hi Tony,

The moment I hit "Send" I knew that this response may be coming as it really 
depends what is one's definition of TE.

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

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

Best,
R.


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


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

2020-12-03 Thread 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.
>>>> 
>>>> 
>>>> It’s absolu

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

2020-12-03 Thread 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

2020-12-03 Thread Jeff Tantsura
Anything else than IGP metric based SPT is considered TE. Looking holistically 
- topology virtualization (or similar) could have been a better name.

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


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

2020-12-01 Thread 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

2020-12-01 Thread Jeff Tantsura
Yes/support - very useful work!

Cheers,
Jeff
On Dec 1, 2020, 1:13 PM -0800, Acee Lindem (acee) 
, wrote:
> This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
> and deployment prior to IETF 109 and there was generally support for WG 
> adoption. This begins a two week WG adoption call. Please indicate your 
> support or objection to WG adoption on this list prior to 12:00 AM UTC on 
> December 16th, 2020. Also, review comments are certainly welcome.
> Thanks,
> Acee
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] Prefix Unreachable Announcement Use Cases

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

Very simple logic:

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

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

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


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

2020-11-16 Thread 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 reference to the ISIS Trill specificatio

Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-16 Thread Jeff Tantsura
+1 with Robert.

So you expect the following RIB state after PUA has been advertised:
10.0.0.1 - drop
10/24 - forward 

Unless there’s a recursively discarded next-hop (ala RTBH )  - how do you 
envision it?

Regards,
Jeff

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


Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-15 Thread 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

2020-11-15 Thread Jeff Tantsura
As RIFT chair - I’d like to respond to Robert’ comment -  the example is rather 
 unfortunate, in RIFT disaggregation is conditional and well contained within 
its context, it doesn’t  affect overall scalability.

Regards,
Jeff

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


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

2020-11-13 Thread 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.
>  
> As the end of 12 days of the 14 day WG LC, t

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

2020-11-04 Thread 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.
>
> 

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

2020-10-23 Thread Jeff Tantsura
Yes/support 

Regards,
Jeff

> On Oct 23, 2020, at 07:43, Acee Lindem (acee) 
>  wrote:
> 
> 
> This is simple BIS update to RFC 5316 is required to support IS-IS Inter-AS 
> TE in IPv6 only networks. The authors have asked for WG adoption.
>  
> This begins a two week LSR Working Group Adoption Poll for “ISIS Extensions 
> in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic 
> Engineering” - draft-chen-lsr-isis-rfc5316bis-02. The poll will end at 12:00 
> AM UTC on November 7th, 2020. Please indicate your support of objection on 
> this list prior to the end of the adoption poll.
>  
> Thanks,
> Acee
>  
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2020-10-15 Thread Jeff Tantsura
+1

Regards,
Jeff

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

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


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

2020-10-15 Thread Jeff Tantsura
Yes/support

Regards,
Jeff

> On Oct 14, 2020, at 23:16, Christian Hopps  wrote:
> 
> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:
> 
>  https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/
> 
> The following IPR has been filed https://datatracker.ietf.org/ipr/3448/
> 
> Authors,
> 
>  Please indicate to the list, your knowledge of any other IPR related to this 
> work.
> 
> Thanks,
> Chris.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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


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

2020-10-12 Thread 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 

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

2020-10-11 Thread 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 try 

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

2020-10-11 Thread 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 Tantsura 

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

2020-10-10 Thread 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.
>>>> 
>>>> So, IP Fle

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

2020-10-02 Thread 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%2Flsrdata=02%7C01%7Cyingzhen.qu%40futurewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637372537869296887sdata=R%2FI%2BAUkcw12FmgDtsh%2FBOL7zLjPF%2BwwRpqwnE2Ndv%2Fg%3Dreserved=0
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2020-10-02 Thread 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

2020-10-01 Thread Jeff Tantsura
Hi Ron,

the readers would benefit if the draft would state that in order for the 
technology to work properly, there must be a contiguous set of connected 
routers that support it between the S/D, since lookup (route installed in 
context of the algo it is associated with) is done per hop.

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


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

2020-08-14 Thread Jeff Tantsura
In general, I agree with what Ketan said, what’s important - it is the value 
that is being used in forwarding, even if multiple control plane entries exist, 
think about IGP migrations, or LDP to SR, where more than 1 protocol could be 
distributing the labels/SIDs. I’m not sure the FIB is the right place to 
collect this data though, since most of meta-data has already been lost 
(flattened FIB structures often contain bare minimum) and really heavily 
depends on the implementation.

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


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

2020-06-18 Thread Jeff Tantsura
+1 to “Application-Specific”

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

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

2020-06-12 Thread Jeff Tantsura
yes/support the adoption

Cheers,
Jeff
On Jun 11, 2020, 12:04 PM -0700, Jordan Head 
, wrote:
> Support.
>
> The draft identifies and addresses the problem, and quite cleanly I might add.
>
> Jordan Head
>
> On 6/10/20, 3:29 PM, "Lsr on behalf of Christian Hopps"  on behalf of cho...@chopps.org> wrote:
>
> [External Email. Be cautious of content]
>
>
> This begins a 2 week WG adoption call for the following draft:
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection__;!!NEt6yMaO-gk!WcIjGwXb7biFdhbdSv8WhQa86HqfdhAiVT-T4gE68NjQ9_Uii9O_HMCdksRshic$
>
> The draft would be adopted on the Experimental track.
>
> Please indicate your support or objection by June 24, 2020.
>
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.
>
> Thanks,
> Chris and Acee.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!WcIjGwXb7biFdhbdSv8WhQa86HqfdhAiVT-T4gE68NjQ9_Uii9O_HMCdWR4R6q4$
>
>
> Non-Juniper
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2020-06-06 Thread Jeff Tantsura
Thanks Chris/Tony,

I wish we’d have more of this kind of discussions on the list, discussing 
pro/cons of the solutions proposed!

Have a great weekend!

Regards,
Jeff

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

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

2020-06-04 Thread Jeff Tantsura
yes/support

Cheers,
Jeff
On Jun 4, 2020, 11:05 AM -0700, Tony Przygienda , wrote:
> I would like to officially call out for adoption of 
> https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01 as WG 
> document
>
> At this point in time flood reflection has been implemented and works meeting 
> use case requirements of multiple customers which neither TTZ nor draft-proxy 
> is addressing or can satisfy in terms of deployment realities. While we would 
> love to not squat on codepoints and ideally have an interoperable solution 
> between vendors it will be the customer reality that will drive deployment 
> and ultimately what runs in their networks.
>
> thanks
>
> --- tony
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2020-05-09 Thread Jeff Tantsura
Weibin,

One could have an algo with MSD/ERLD as optimizations constrains, would be 
quite similar to colored links. Note - ERLD has implemented node capabilities 
only, so all links on a node will have to be pruned.
The tradeoffs are - having centralized controller with global view computing a 
path that meets the constraints(classical BGP-LS + PCEP scenario) vs building a 
dynamic topology of connected nodes that meet a set of constrains, in first 
case, change in topology/capabilities would cause path 
recalculation/reoptimization on the PCE while in the second - IGP would 
recompute the topology locally.

Regards,
Jeff

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


Re: [Lsr] Flooding across a network

2020-05-06 Thread Jeff Tantsura
Robert,

Assuming C and E provide access to the same set of destinations, that are 
closer of further away from C and E.
B (which is fast), after it notifies A that it can’t reach C directly will 
cause A to send traffic to D. D - dependent on total cost would start happily 
sending some traffic towards destinations behind C to B so LFA on B wouldn’t 
really help.

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

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

2020-04-17 Thread Jeff Tantsura
Very well written draft, 02 has significantly improved readability and 
addressed some missing details.
Would support adoption.

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


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

2020-04-06 Thread Jeff Tantsura
+1
Please do not take my comments about link vs node capabilities, as support for 
the solution, they are semantical.

Cheers,
Jeff
On Apr 6, 2020, 8:58 AM -0700, Tony Li , wrote:
>
>
> > This discussion is interesting, but please do not ignore the considerable 
> > feedback from multiple folks indicating that this advertisement does not 
> > belong in the IGP at all (regardless of scope).
> > My opinion on that has not changed.
>
>
> +1
>
> IS-IS is not the correct place to implement Service Discovery mechanisms. The 
> management plane already has ample mechanisms for service and capability 
> discovery.
>
> Tony
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2020-04-05 Thread Jeff Tantsura
Very valid comment - When working on MSD - we had exactly same considerations, 
since path computation could use different links over different line cards that 
may have different capabilities, hence we decided to have per link granularity, 
details in RFC 8491

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


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

2020-04-03 Thread Jeff Tantsura
Same here

Regards,
Jeff

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


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

2020-04-03 Thread Jeff Tantsura
Hi Aijun,

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

Regards,
Jeff

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


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

2020-04-02 Thread Jeff Tantsura
Robert, 

We are deviating ;-)

There’s no feedback loop from telemetry producers back to the TE headend.
The telemetry, either end2end or postcards is sent to a  collector that has the 
context of the data and normalizes it so it can be consumed by an external 
system, being centralized or distributed PCE or anything else that could make 
use of it. Do you see IGP anywhere in between?


Regards,
Jeff

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


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

2020-04-02 Thread Jeff Tantsura
Robert,

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

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

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

2020-04-02 Thread Jeff Tantsura
Robert,

This is unnecessary leakage of management plane into control plane.
The role of a routing protocol is to distribute: reachability (doh :-)) and any 
additional data that could influence routing decision wrt reachability.
There are precedences of using IGP’s for different tasks, e.g. RFC 5088 and 
similar, however should we do it again?

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

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

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

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

2020-01-13 Thread Jeff Tantsura
Agree with Acee and Les

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


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

2020-01-02 Thread Jeff Tantsura
yes/support

Happy New Year all!

Cheers,
Jeff
On Jan 2, 2020, 11:07 AM -0800, Christian Hopps , wrote:
> This begins a 2 week WG Last Call, ending after Jan 16th, 2020, for 
> draft-ietf-lsr-isis-invalid-tlv.
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/
>
> Tony P (other authors already responded during the adoption poll), please 
> indicate your knowledge of any IPR related to this work to the list as well.
>
> Thanks,
> Chris & Acee.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2019-12-13 Thread Jeff Tantsura
I support the adoption, finally OSPF would catch up with IS-IS ;-)

Cheers,
Jeff
On Dec 13, 2019, 3:28 AM -0800, Christian Hopps , wrote:
> Hi LSR WG and Draft Authors,
>
> This begins a 2 week WG adoption poll for the following draft:
>
> https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-reverse-metric/
>
> Please indicate your support or objection by Dec 27th.
>
> Authors, please respond indicating whether you are aware of any IPR that 
> applies to this draft.
>
> Thanks,
> Chris & Acee.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2019-12-13 Thread Jeff Tantsura
I support the adoption

Cheers,
Jeff
On Dec 13, 2019, 3:54 AM -0800, Christian Hopps , wrote:
> Hi LSR WG and Draft Authors,
>
> This begins a 2 week WG adoption poll for the following draft:
>
> https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-bfd-strict-mode/
>
> Please indicate your support or objection by Dec 27th.
>
> Authors, please respond indicating whether you are aware of any IPR that 
> applies to this draft.
>
> Thanks,
> Chris & Acee.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2019-11-25 Thread Jeff Tantsura
Yes/support

Regards,
Jeff

> On Nov 25, 2019, at 21:27, Acee Lindem (acee)  wrote:
> 
> 
> This begins a two week LSR Working Group adoption call for the subject 
> document.
>  
> https://datatracker.ietf.org/doc/draft-hopps-lsr-yang-isis-reverse-metric/
>  
> Please indicate your support or objection to adoption to the LSR list 
> (lsr@ietf.org) prior to 12:00 AM UTC on December 10th, 2019.
>  
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2019-10-02 Thread Jeff Tantsura
yes/support, missing pieces that need to be added

Cheers,
Jeff
On Oct 2, 2019, 2:28 PM -0700, Christian Hopps , wrote:
> Hi Folks,
>
> This begins a 2 week WG adoption poll for the following:
>
> https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-yang-augmentation-v1/
>
> Please send any comments to the list by Wednesday Oct 16th, 2019.
>
> Thanks,
> Chris.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2019-10-02 Thread Jeff Tantsura
yes/support

Cheers,
Jeff
On Oct 2, 2019, 2:27 PM -0700, Christian Hopps , wrote:
> Hi Folks,
>
> This begins a 2 week WG adoption poll for the following:
>
> https://datatracker.ietf.org/doc/draft-acee-lsr-ospfv3-extended-lsa-yang/
>
> Please send any comments to the list by Wednesday Oct 16th, 2019.
>
> Thanks,
> Chris.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2019-09-02 Thread Jeff Tantsura
Yes/support

Cheers,
Jeff
>  
>  
> From: Lsr  On Behalf Of Acee Lindem (acee)
> Sent: Friday, August 30, 2019 12:44 PM
> To: lsr@ietf.org
> Cc: m...@ietf.org; lsr-...@ietf.org; draft-ietf-isis-mpls-...@ietf.org
> Subject: [Lsr] Working Group Last Call for "Signaling Entropy Label 
> Capability and Entropy Readable Label-stack Depth Using ISIS" - 
> draft-ietf-isis-mpls-elc-07
>  
> We’ve gone through a number of iterations with these ELC drafts and I believe 
> they are ready and meets all the use case requirements. Note that “Entropy 
> Label for Spring tunnels” – draft-ietf-mpls-spring-entropy-label-12 is on the 
> RFC editor’s queue.  
> This begins a two week last call for the subject draft. Please indicate your 
> support or objection on this list prior to 12:00 AM UTC on Sept 14th, 2014. 
> Also, review comments are certainly welcome.
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2019-09-02 Thread Jeff Tantsura
Yes/support 

Cheers,
Jeff

>  
>  
> From: Lsr  On Behalf Of Acee Lindem (acee)
> Sent: Friday, August 30, 2019 12:42 PM
> To: lsr@ietf.org
> Cc: m...@ietf.org; lsr-...@ietf.org; draft-ietf-ospf-mpls-...@ietf.org
> Subject: [Lsr] Working Group Last Call for "Signaling Entropy Label 
> Capability and Entropy Readable Label-stack Depth Using OSPF" - 
> draft-ietf-ospf-mpls-elc-08
>  
> We’ve gone through a number of iterations with these ELC drafts and I believe 
> they are ready and meets all the use case requirements. Note that “Entropy 
> Label for Spring tunnels” – draft-ietf-mpls-spring-entropy-label-12 is on the 
> RFC editor’s queue.  
> This begins a two week last call for the subject draft. Please indicate your 
> support or objection on this list prior to 12:00 AM UTC on Sept 14th, 2014.
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2019-08-28 Thread Jeff Tantsura
Acee,

I agree with your statement.
We (MSD DE’s) have OKed temporary allocation.
I believe WGLC would be in place.

Regards,
Jeff

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


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

2019-08-13 Thread Jeff Tantsura
Support 

Regards,
Jeff

> On Aug 13, 2019, at 13:18, Jeff Tantsura  wrote:
> 
> +1
> 
> Cheers,
> Jeff
>> On Aug 13, 2019, 8:07 AM -0700, Robert Raszuk , wrote:
>> > lsr-isis-extended-hierarchy 
>> 
>>  Sounds great !
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2019-08-13 Thread Jeff Tantsura
+1

Cheers,
Jeff
On Aug 13, 2019, 8:07 AM -0700, Robert Raszuk , wrote:
> > lsr-isis-extended-hierarchy
>
>  Sounds great !
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2019-07-25 Thread Jeff Tantsura
+1 Ketan

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


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

2019-07-25 Thread Jeff Tantsura
Sue,

I support progress of this draft, it addresses real problem.
On Redback side of things we have implemented this around 2013, logic 
(proprietary) kept in BFD indeed, so +1 Ketan. I’d document it as an informal 
feature, that is recommended (same for YANG)

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


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

2019-06-14 Thread Jeff Tantsura
Yes/support

Cheers,
Jeff

> On Jun 12, 2019, at 15:04, Christian Hopps  wrote:
> 
> This begins a 2 week WG adoption call for draft-ginsberg-lsr-isis-invalid-tlv.
> 
> https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-invalid-tlv/
> 
> Please express your support or non-support.
> 
> Authors: Please indicate your knowledge of any IPR related to this work
> to the list as well.
> 
> Thanks,
> Chris & Acee.
> 
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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


Re: [Lsr] Adjacency SID and Passive Interface

2019-05-10 Thread Jeff Tantsura
+1

Regards,
Jeff

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

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


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

2019-05-09 Thread Jeff Tantsura
Acee,

Prem is not with BF anymore, I’ll contact him OOB.
I believe Hani is in the similar situation. Will ping him too.

Regards,
Jeff

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


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

2019-04-12 Thread Jeff Tantsura
Olivier,

+1 Peter.
There’s has been significant amount of discussions on the topic some time ago, 
mostly with Chris Bowers. Please take a look, should provide more context.

Regards,
Jeff

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

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


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

2019-04-11 Thread Jeff Tantsura
Acee,

I’m not aware of any IPR that applies to the draft.

Regards,
Jeff

> On Apr 11, 2019, at 18:09, Acee Lindem (acee)  wrote:
> 
> Authors, Contributors,
>  
> Are you aware of any IPR that applies to 
> draft-ietf-ospf-te-link-attr-reuse-07?
>  
> If so, has this IPR been disclosed in compliance with IETF IPR rules 
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
>  
> If you are listed as a document author or contributor please respond
> to this email regardless of whether or not you are aware of any
> relevant IPR. *The response needs to be sent to the LSR WG mailing
> list.* The document will not advance to the next stage until a
> response has been received from each author and contributor.
>  
> If you are on the LSR WG email list but are not listed as an author or
> contributor, then please explicitly respond only if you are aware of
> any IPR that has not yet been disclosed in conformance with IETF rules.
>  
> Thanks,
> Acee 
>  
>  
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2019-04-10 Thread Jeff Tantsura
Yes/support 

Regards,
Jeff

> On Apr 10, 2019, at 23:24, Acee Lindem (acee)  wrote:
> 
>  LSR Working Group,
>  
> This begins a two week  WG last call for the subject document. Please enter 
> your support or objection to the document before 12:00 AM (EDT) on Wednesday, 
> April 25th, 2019.
>  
> Thanks,
> Acee 
>  
>  
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] Flooding Path Direction

2019-04-04 Thread Jeff Tantsura
+1 Les


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


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

2019-03-19 Thread Jeff Tantsura
yes/support


Cheers,
Jeff
On Mar 19, 2019, 7:30 AM -0700, Acee Lindem (acee) , wrote:
> This begins a 3 WG last call for the subject document. The extra week is 
> since the IETF is next week. Please enter your support or objection to the 
> document before 12:00 AM (EDT) on Wednesday, April 3rd, 2019.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2019-03-11 Thread Jeff Tantsura
+1 Les.

In general - in ECMP cases LFA is meaningless (any ECMP member is loop-free per 
definition) so commonly used technology is fast-rehash, where in case of 
failure all the flows that would use the link in question are rehashed over 
other links in the bundle and that is done in HW.

Regards,
Jeff

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


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

2019-02-11 Thread Jeff Tantsura
Yes/support

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


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

2019-02-01 Thread Jeff Tantsura
In favor!

Regards,
Jeff

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

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

2018-12-02 Thread Jeff Tantsura
Yes/support

Regards,
Jeff

> On Dec 1, 2018, at 16:54, Acee Lindem (acee)  wrote:
> 
> This begins a two-week WG adoption call for the subject draft. As anyone who 
> has been following the topic knows, there are a lot of proposal in this 
> space. However, as WG co-chair, I believe this simple IS-IS extension doesn’t 
> really conflict with any of the other more disruptive flooding proposals. 
> Also, it is more mature and there is some implementation momentum. Note that 
> I’m making every attempt to be transparent and it is perfectly ok to disagree 
> with me. Please post your comments to this list before 12:00 AM, December 
> 16th, 2018.
>  
> With respect to the more disruptive proposals, we are discussing our next 
> steps.
>  
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2018-11-19 Thread Jeff Tantsura
Yes/support 

Regards,
Jeff

> On Nov 19, 2018, at 14:22, Acee Lindem (acee)  wrote:
> 
> The begins a Working Group Last Call for the subject document. Please post 
> for review comments and/or support/objection to this document before 12:00 AM 
> UTC on Tuesday, December 4th, 2018.
>  
> Other than some RFC boiler plate changes, the RFC 5306 BIS document really 
> only adds the PR/PA bit handling in section 2.2.3 and the addition of the 
> Planned Restart State to sections 3.1 and 3.2.
>  
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2018-11-16 Thread Jeff Tantsura
Robert,

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

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

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

Now tell me - why again DSCP?

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

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

> Jeff,
>
> > What architecture?
> > PBR is a form of:
> > match DSCP X
> > set next-hop Y
> > needs no interoperability...
>
> That's pretty narrow view. I could say the worst possible example :)  You
> would have to either encapsulate or apply your sample config consistently
> on every hop. Br.
>
> To me DSCP can be used to map packets to different routing context,
> different plane or can be used as a parameter in flex-algorithm.
>
> Thx,
> R.
>
>
>
>
>
> On Fri, Nov 16, 2018 at 8:19 AM Jeff Tantsura 
> wrote:
>
>> Tony,
>>
>> What architecture?
>> PBR is a form of:
>> match DSCP X
>> set next-hop Y
>> needs no interoperability...
>> If someone wants to describe how they use a particular vendor feature to
>> solve a particular problem in a BCP, sure, the more BCPs - the better.
>>
>> Wrt using DSCP in routing decision process - it was a bad idea back then,
>> hasn’t got any better now... besides - now we have got a toolbox that
>> wasn’t available then.
>>
>> Cheers,
>> Jeff
>> On Thu, Nov 15, 2018 at 22:56 Tony Li  wrote:
>>
>>>
>>>
>>> On Nov 15, 2018, at 8:47 PM, Jeff Tantsura 
>>> wrote:
>>>
>>> The question is really - what is here to standardize?
>>>
>>>
>>>
>>> There’s a fine architectural BCP here: this is how we are solving
>>> problem XYZ.  Please don’t break this.
>>>
>>> Tony
>>>
>>>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2018-11-15 Thread Jeff Tantsura
+1 Rob
I have seen number of MBH networks using DSCP to change forwarding - AKA PBR..

The question is really - what is here to standardize?

RSVP-TE use cases mentioned by Rob (CBTS/PBTS in IOS realm) are classical 
examples of Policy Based Routing and as such are subject to implementation 
details, not standardization.

Am I missing something?


Regards,
Jeff

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


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

2018-11-13 Thread Jeff Tantsura
Yes/support
On Tue, Nov 13, 2018 at 16:53 Qin Wu  wrote:

> I support this work as one of coauthors.
>
>
>
> -Qin
>
> *发件人:* Lsr [mailto:lsr-boun...@ietf.org] *代表 *Acee Lindem (acee)
> *发送时间:* 2018年11月14日 6:11
> *收件人:* lsr@ietf.org
> *主题:* [Lsr] WG Adoption Poll for IGP extension for PCEP security
> capability support in the PCE discovery -
> draft-wu-lsr-pce-discovery-security-support-00
>
>
>
> At the LSR WG meeting in Bangkok, there was general agreement that we
> should adopt this draft given that the PCE WG believes it is useful. Please
> indicate your support or objection prior to 12:00 AM UT, Wednesday November
> 26th, 2018. Note the authors may refresh the draft to address some
> comments prior to that time.
>
>
>
>
>
> Thanks,
>
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2018-10-23 Thread 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] FW: New Version Notification for draft-ginsberg-lsr-isis-invalid-tlv-00.txt

2018-10-19 Thread 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] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-10-02 Thread 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] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

2018-09-26 Thread 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 
>> 

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

2018-08-24 Thread 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] LSR Flooding Reduction Drafts - Moving Forward

2018-08-23 Thread 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] LSR Flooding Reduction Drafts - Moving Forward

2018-08-22 Thread 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

2018-08-22 Thread 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 could start with a docu

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

2018-08-22 Thread 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 Working Last Call for draft-ietf-ospf-yang

2018-08-22 Thread 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 Working Last Call for draft-ietf-ospf-yang

2018-08-17 Thread 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-isis-segment-routing-msd-13

2018-08-15 Thread 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.

 

[Les:

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

2018-07-25 Thread 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 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 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 on 

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

2018-07-08 Thread 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 clear

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

2018-07-03 Thread 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] [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS)

2018-06-13 Thread 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] IPR Poll draft-ietf-isis-segment-routing-msd.

2018-06-13 Thread 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=draft-ietf-isis-segment-routing-msd

Thanks,
Chris.



___
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

2018-06-12 Thread 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 

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

2018-06-11 Thread 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] IGP TE Metric Extensions

2018-05-31 Thread 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] LSR Working Group Last Call for "OSPFv3 Extensions for Segment Routing" - draft-ietf-ospf-ospfv3-segment-routing-extensions-13

2018-05-23 Thread 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] LSR WG Last Call for "Signaling MSD (Maximum SID Depth) using OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

2018-05-10 Thread Jeff Tantsura
Hi Ketan,

 

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

 

Cheers,

Jeff

From: "Ketan Talaulikar (ketant)" <ket...@cisco.com>
Date: Thursday, May 10, 2018 at 08:05
To: Jeff Tantsura <jefftant.i...@gmail.com>, "Acee Lindem (acee)" 
<a...@cisco.com>, "lsr@ietf.org" <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 <jefftant.i...@gmail.com> 
Sent: 08 May 2018 04:53
To: Ketan Talaulikar (ketant) <ket...@cisco.com>; Acee Lindem (acee) 
<a...@cisco.com>; 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 <lsr-boun...@ietf.org> on behalf of "Ketan Talaulikar (ketant)" 
<ket...@cisco.com>
Date: Thursday, April 12, 2018 at 05:04
To: "Acee Lindem (acee)" <a...@cisco.com>, "lsr@ietf.org" <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 S

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

2018-05-07 Thread 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
   

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

2018-05-07 Thread 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 <tal.mizrahi@gmail.com>
Date: Sunday, April 29, 2018 at 04:08
To: <draft-ietf-ospf-segment-routing-...@ietf.org>, <ospf-cha...@ietf.org>, 
<lsr@ietf.org>
Cc: <rtg-...@ietf.org>, <rtg-...@ietf.org>
Subject: Re: RtgDir Early review: draft-ietf-ospf-segment-routing-msd.txt
Resent-From: <alias-boun...@ietf.org>
Resent-To: Jeff Tantsura <jefftant.i...@gmail.com>, <uma.chund...@huawei.com>, 
<aldrin.i...@gmail.com>, <ppse...@cisco.com>
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 <tal.mizrahi@gmail.com> 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

2018-04-29 Thread 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] WG Last Call for draft-ietf-isis-segment-routing-extensions-16

2018-04-23 Thread 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=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] LSR Working Group Secretary

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

2018-04-06 Thread Jeff Tantsura
Sold!

Cheers,
Jeff
On 4/6/18, 14:45, "Acee Lindem (acee)" <a...@cisco.com> 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" <jefftant.i...@gmail.com> 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) <a...@cisco.com> 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)" <ginsb...@cisco.com> 
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 <ie...@btconnect.com>
>> Sent: Friday, April 06, 2018 3:43 AM
>> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Christian Hopps
>> <cho...@chopps.org>
>> Cc: lsr@ietf.org; Acee Lindem (acee) <a...@cisco.com>
>> Subject: Re: [Lsr] FW: New Version Notification for 
draft-ginsberg-isis-
>> rfc7810bis-00.txt
>> 
>> - Original Message -
>> From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com>
>> Sent: Thursday, April 05, 2018 5:26 PM
>> 
>>> Chris -
>>> 
>>>> -Original Message-
>>>> From: Christian Hopps <cho...@chopps.org>
>>>> 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.
>> 
>&

  1   2   >