Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-20 Thread Robert Raszuk
Hey Tony,

>  people somehow implying a map of RIFT negative disaggregation in
relation to this work

I think those people just made a subtle point that considering IGP alone if
you want to influence your data plane forwarding by advertising PUA in
today's hardware you really need to install more specific blocks of the
summary routes which PUA punched the hole in as sent by say one of the
ABR's. Analogy made to RIFT was just limited to this data plane fragment
only.

And that comment was not to compare PUA to RIFT negative routing in any
way. It was just to a) realize what could be required if such a use case
continues and more importantly b) highlight that if we just use PUA in the
control plane to for example invalidate BGP next hops or other overlay
service routes the disaggregation piece does not apply.

Cheers,
R.





On Fri, Nov 20, 2020 at 9:09 PM Tony Przygienda  wrote:

>
>
> On Fri, Nov 20, 2020 at 6:27 AM Aijun Wang 
> wrote:
>
>> Hi, Tony:
>>
>> Aijun Wang
>> China Telecom
>>
>> On Nov 20, 2020, at 17:45, Tony Przygienda  wrote:
>>
>> 
>> Yes, acknowledging the idea of negative disaggregation is inspired by
>> RIFT work is fine (and normally, when inspired by an idea at least in
>> research cycles it is considered basic courtesy to refer to the according
>> source, something has been lost more and more in IETF over time I dare to
>> observe which in itself reflects on the community IMO) but please do not
>> try to compare the two beyond that.
>>
>> [WAJ] PUA has no relation with RIFT. I have not yet study what’s problem
>> it encountered, but welcome the experts have such design experience to
>> point out the pitfall that PUA can bypass.
>>
>>
> aha, ok, I just chimed in because I saw people somehow implying a map of
> RIFT negative disaggregation in relation to this work but if this is a
> completely different mechanism than I just watch from the sidelines
>
> thanks
>
> -- tony
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-20 Thread Robert Raszuk
Gyan,

I like and support your use case #1

For use case #2 I have doubts. Imagine indeed an area which get's
partitioned such that ABR will loose connectivity to bunch of nodes. Does
this mean that now such ABR will be blasting globally perhaps 1000s of PUAs
? How would the ABR be able to send PUA summary provided some disconnected
POPs within area could be nicely summarized ? Isn't it better to design
your area such that ABRs are interconnected with redundancy ?

Thx,
R.



On Fri, Nov 20, 2020 at 3:28 AM Gyan Mishra  wrote:

>
> Aijun
>
> I am thinking per the feedback received let’s keep it really simple.  We
> need a solid use case to move the ball forward were the PUA data plane
> convergence capabilities can fills a gap that exists today.
>
> I have two simple solutions to start that I will update the presentation
> with to start and present to the WG and we can go from there.
>
> 1.  BGP NH tracking via PUA of NH component prefix to converge the data
> plane
>
> 2.  Area partitioned scenario where PUA is used for data plane convergence
> to ABR that has reachability to component prefixes.
>
> I will send out tomorrow.
>
> Thanks
>
> Gyan
>
> On Wed, Nov 18, 2020 at 9:37 PM Aijun Wang 
> wrote:
>
>> Hi, Acee:
>>
>>
>>
>> OK, we will try to improve this document to meet this criteria.
>>
>> And, as this topic has been discussed intensely on the mail list, we are
>> also eager to invite more interested experts to join us as co-authors to
>> refine the solutions for more scenarios.
>>
>>
>>
>> Thanks in advance.
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>>
>>
>> *From:* Acee Lindem (acee) 
>> *Sent:* Thursday, November 19, 2020 12:42 AM
>> *To:* Aijun Wang ; 'Robert Raszuk' <
>> rob...@raszuk.net>; 'Jeff Tantsura' 
>> *Cc:* 'Gyan Mishra' ; 'lsr' ; 'Acee
>> Lindem (acee)' 
>> *Subject:* Re: [Lsr] Prefix Unreachable Announcement Use Cases
>>
>>
>>
>> Speaking as WG Co-Chair:
>>
>>
>>
>> *From: *Aijun Wang 
>> *Date: *Wednesday, November 18, 2020 at 3:05 AM
>> *To: *Robert Raszuk , Jeff Tantsura <
>> jefftant.i...@gmail.com>
>> *Cc: *'Gyan Mishra' , Acee Lindem ,
>> 'lsr' , "'Acee Lindem (acee)'" <
>> acee=40cisco@dmarc.ietf.org>
>> *Subject: *RE: [Lsr] Prefix Unreachable Announcement Use Cases
>>
>>
>>
>> Hi, Robert:
>>
>>
>>
>> The trigger and propagation of PUA info can be standardized, the actions
>> based on the PUA can be different in different situation.
>>
>> We can discuss and describe the actions based on different scenarios
>> after its WG adoption?
>>
>>
>>
>> There will be no adoption call until there is a coherent draft with use
>> case(s) and viable actions.
>>
>>
>>
>> Thanks,
>>
>> Acee
>>
>>
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> *From:* Robert Raszuk 
>> *Sent:* Wednesday, November 18, 2020 3:49 PM
>> *To:* Jeff Tantsura 
>> *Cc:* Gyan Mishra ; Acee Lindem (acee) <
>> a...@cisco.com>; lsr ; Aijun Wang <
>> wangai...@tsinghua.org.cn>; Acee Lindem (acee) <
>> acee=40cisco@dmarc.ietf.org>
>> *Subject:* Re: [Lsr] Prefix Unreachable Announcement Use Cases
>>
>>
>>
>> Jeff,
>>
>>
>>
>> Please notice that WAN is not an IX.
>>
>>
>>
>> While you can have full mesh of BFD sessions among all IXP participants
>> each bombarding each over over TB fabric every 100 ms or so to map the same
>> over global WAN is a different game. If nothing else RTT between IXP
>> participants in healthy IX is around 1 ms while RTT between PEs distributed
>> globally is often 100-200 ms.
>>
>>
>>
>> Just imagine 1000 PEs in 10 areas distributed all over the world. That
>> means that in worst case scenario (say same mgmt VPN present on each PE)
>> you will establish 1000*999 BFD sessions. Now for this to make sense timer
>> needs to be 100 ms or so with 3x or 5x multiplier. Anything slower will
>> defeat the purpose as BGP withdraw will be faster.
>>
>>
>>
>> Then we go into queuing issues. If BFD packets are queued at any
>> interface meltdowns may occur which can be far worse in consequences then
>> waiting for BGP service route removal. Such meltdowns often result in

Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-17 Thread Robert Raszuk
Jeff,

Please notice that WAN is not an IX.

While you can have full mesh of BFD sessions among all IXP participants
each bombarding each over over TB fabric every 100 ms or so to map the same
over global WAN is a different game. If nothing else RTT between IXP
participants in healthy IX is around 1 ms while RTT between PEs distributed
globally is often 100-200 ms.

Just imagine 1000 PEs in 10 areas distributed all over the world. That
means that in worst case scenario (say same mgmt VPN present on each PE)
you will establish 1000*999 BFD sessions. Now for this to make sense timer
needs to be 100 ms or so with 3x or 5x multiplier. Anything slower will
defeat the purpose as BGP withdraw will be faster.

Then we go into queuing issues. If BFD packets are queued at any interface
meltdowns may occur which can be far worse in consequences then waiting for
BGP service route removal. Such meltdowns often result in cascading effects
to the applications itself.

So this is not at all about autodiscovery with which address to setup the
BFD session. It is much more about operational aspects of going that
direction.

With that I am supportive of this work even if we label it as experimental
for some time. As each network is different what is optimal solution for
one design and deployment may not be optimal for the other.

Many thx,
Robert


On Wed, Nov 18, 2020 at 4:34 AM Jeff Tantsura 
wrote:

> 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 <
> hayabusa...@gmail.com>
> *Date:* Tuesday, November 17, 2020 at 4:02 AM
> *To:* Robert Raszuk 
> *Cc:* lsr , Jeff Tantsura , Aijun
> Wang , "Acee Lindem (acee)"  40cisco@dmarc.ietf.org>
> *Subject:* Re: [Lsr] Prefix Unreachable Announcement Use Cases
>
>
>
>
>
>
>
> On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk  wrote:
>
>
>
>
>
>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.
>
>
>
> Please present us a picture indicating before and after ABRs behaviour.
>
>
>
>  Gyan> will do
>
>
>
>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

Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-17 Thread Robert Raszuk
Hi Zhibo,

> However, if there is a summary or default route in the area, FIB Miss
cannot be triggered.

If PUA is a /dev/null route this is not a FIB miss. It's a FIB hit.

Thx,
R.

On Wed, Nov 18, 2020 at 3:36 AM Huzhibo  wrote:

> Hi Tony:
>
>
>
> In fact, this protection use case protects the SRv6 mid-point.
> https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/.
> When the SRv6 mid-point fails, the PLR node can perform the next SID
> operation, which is triggered by FIB miss. However, if there is a summary
> or default route in the area, FIB Miss cannot be triggered.
>
>
>
> Thanks
>
>
>
> Zhibo
>
>
>
> *From:* Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *tony...@tony.li
> *Sent:* Tuesday, November 17, 2020 2:31 PM
> *To:* Aijun Wang 
> *Cc:* lsr ; Jeff Tantsura ; Robert
> Raszuk ; Acee Lindem (acee)  40cisco@dmarc.ietf.org>
> *Subject:* Re: [Lsr] Prefix Unreachable Announcement Use Cases
>
>
>
>
>
> And how would that help connectivity restoration ?
>
> *[WAJ] This action will trigger the path protection procedures, which will
> divert the traffic to other backup path.*
>
>
>
>
>
> This seems to be making some major assumptions about how path protection
> features operate. Those assumptions need to be
>
> very explicitly called out.
>
>
>
> The path protection features that I’m familiar with are triggered by
> topological changes along the existing operable path. A PUA
>
> does not provide that.  Rather, it’s something of a temporary signal
> saying ’this broke’. Without more specifics about the failure, it’s
> difficult to
>
> understand exactly what path protection should make of this.  If a prefix
> is unreachable, the obvious implication is that the associated link has
>
> failed.  Path protection in a remote area is highly unlikely to have the
> topological details necessary to find an alternate path to that prefix.
>
>
>
> Tony
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-17 Thread Robert Raszuk
Yes that is the case where I see some potential use case.

Especially considering also https://tools.ietf.org/html/rfc5283 - which by
many network operators is very desired, but not configured due to "slow BGP
convergence" - pls let's not go there :)

But again if someone knows how to configure BGP properly I think IGP
speedup would be marginal or even null hence a grain of hesitation if we
should use IGP flooding for it. Maybe in some scenarios ... which PUA
authors need to spell out to move fwd I suppose.

Cheers,
R.








On Tue, Nov 17, 2020 at 9:40 PM Gyan Mishra  wrote:

>
> Robert
>
> I am recalling now the BGP use case you mentioned.
>
> If the next hop is being summarized between areas which it would be, the
> next hop failure component prefix is now hidden in the summary and now you
> have to wait for BGP timer to pop and route withdrawal.
>
> So for this failure scenario one option is multihop BFD but that does get
> way complicated.
>
> So here the obvious and best use case for PUA would be for the data plane
> detection of the next hop component down at which time PUA is sent flooded
> and the routers in the other area now set next hop to null for that next
> hop and are forced to converge on alternate next hop.
>
> Let me update the presentation to add this use case.
>
> Thanks
>
> Gyan
>
> On Tue, Nov 17, 2020 at 2:09 PM Gyan Mishra  wrote:
>
>> Agreed.
>>
>> Robert
>>
>> Can you explain the BGP scenario you had in mind that you have mentioned
>> a number of times that you think this PUA feature would pertain?
>>
>> I will respond to your other email separately.  I was trying to guess  as
>> to the BGP next hop use case you were referring to but apparently was way
>> off.
>>
>> Thank you
>>
>> Gyan
>>
>> On Tue, Nov 17, 2020 at 9:43 AM 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 <
>>> hayabusa...@gmail.com>
>>> *Date: *Tuesday, November 17, 2020 at 4:02 AM
>>> *To: *Robert Raszuk 
>>> *Cc: *lsr , Jeff Tantsura ,
>>> Aijun Wang , "Acee Lindem (acee)" >> 40cisco@dmarc.ietf.org>
>>> *Subject: *Re: [Lsr] Prefix Unreachable Announcement Use Cases
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk  wrote:
>>>
>>>
>>>
>>>
>>>
>>>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.
>>>
>>>
>>>
>>> Please present us a picture indicating before and after ABRs behaviour.
>>>
>>>
>>>
>>>  Gyan> will do
>>>
>

Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-17 Thread Robert Raszuk
Hi Gyan,

  Gyan>. We could use Aijun’s passive interface new top level TLV to
> link the next hop rewrite loopback to the PE-CE links all being set to
> passive. So if any PE-CE link goes down a PUA is sent and the next hop
> converges PIC core PE-CE link which is now associated with the Loopback.
> This would be a major benefit of PUA for PIC core convergence when
> next-hop-self is used which applies to MPLS and SR and IP based core.
>

I have read the above three sentences five times and came with two basic
observations:

* You are mixing PIC Core with PIC Edge - Please do not. Those are
completely separate features and it is a feature not a bug to keep them
that way.

* You are mixing external PE-CE interfaces with IGP passive interfaces -
Please do not. There should be no IGP flooding of any sort associated with
state of PE-CE interface. No need.

Thx a lot,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-17 Thread Robert Raszuk
   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.

Please present us a picture indicating before and after ABRs behaviour.

   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 ?



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

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


Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-17 Thread Robert Raszuk
> Moreover it seems that it will just also prevent any local protection to
> locally bypass the failed destination.
>
> *[WAJ] No, It will trigger the local protection instead, not prevent.*
>
>
You missed my point.

I am talking about *local* protection in a sense of adjacent node(s) to the
PE/ASBR which failed. *Local* to the failure.

You are talking about *local* protection on ingress to the network. Let's
focus on this:

Q1 - You are installing a /dev/null route in a router. That means that any
packet sent to this destination will be dropped. How is this of any
protection ?

Q2 - What you may be actually trying to say is that by installing such PUA
into RIB you will via RIB let know those clients (ex: BGP) which track this
route that it is gone and that their possibly best path is no longer valid.
Sure that is one way to share such information between IGP and BGP. But
this needs to be described in the document that this is your intention.
Otherwise when you say you are installing a drop route in RIB & FIB I am
not sure how helpful that is (well other then transiently relaxing the
network to drop some traffic few router hops away).

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


Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-16 Thread Robert Raszuk
>
> 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 Robert Raszuk
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 Robert Raszuk
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


Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-15 Thread Robert Raszuk
Hi Aijun,

As I think what you are proposing overall is useful let me in turn comment
on some of your statements ...

[WAJ] It is common, for example, ISIS level1-2 router will announce the
>> default route to the level 1 area. And, also in the OSPF totally stubby
>> area.
>>
>
Well let's just take OSPF and imagine:

 Area1 --- ABR1 --- Area0 ---ABR2 --- Area2

So you are saying that unreachable should be always flooded/leaked domain
wide. That's news - I was always thinking of this functionality only in the
case when a summary route covering such more specific is present. Default
should not count ... at least I am not sure if this is safe or makes sense
at this point.


[WAJ] The tunnel soultions described in section 6 is the last resort of the
>> path switch procedure. If we deploy the PUA mechanism, normally the routers
>> within another area will switch automatically to other ABR when it receives
>> the PUA from one ABR.  Only in the critical scenario that described in
>> beginning of section 6, the solution described in section 6.1 or 6.2 will
>> be used.
>>
>
I think this is where you are starting to confuse people. In my option this
solution should have nothing to do with selecting which ABR to use to cross
area boundary.

The cases when one ABR has full remote reachability and the other one
partial one in my view are symptoms of a very poorly designed network and
to stretch protocol thin to cover for those mistakes with a patch is not a
good thing.

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.

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


Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-14 Thread Robert Raszuk
Hi Acee,

> 3.1 *Inter-Area Node Failure Scenario – *With respect to this use case,
the node
> in question is actually unreachable. In this case, the ABRs will normally
install a
> reject route for the advertised summary and will send an ICMP unreachable
when
> the packets are received for the unreachable prefix.

And what will the network do with such ICMP unreachable ? Is there some
draft I missed where encapsulating PE will choose a path with different
tunnel endpoint upon reception of ICMP unreachable message ?

See the entire idea behind this draft is to trigger faster switchover to
other PEs in the case of a multihomed attached site.

Option 1 - withdraw a service route in BGP. Use aggregate withdraw to speed
this up (say withdraw just RDs)

Option 2 - signal next hop unreachability (aka negative route) of more
specific prefix then the aggregate itself.

While I think just option 1 is ok for the vast majority of services your
answer seems to be talking about ICMP unreachable which IMO would not help
much with the issue. The proposal is not about failing ... the proposal is
about faster connectivity restoration.

> If faster detection is required, BFD or other mechanisms are available.

Now running a full mesh of BFD multihop sessions from each PE to each other
PE may be ok in theory but rather no-op in practice. Just think 1000 PEs
with 100 ms BFD timers in a full mesh of BFD sessions. Then rethink the
same with  BFD packets maxed to 1500 or 4K bytes packets as per some
proposals floating around.

If we want to move that way I would rather suggest we define a local BFD
anchor explorers (one per area) which will probe all "interesting" next
hops in a given area. Upon failure it would signal to those remote PEs
which indicated interest in such tracking the event of failure.

Again using BFD for this in any form or shape needs to be weighed for
cost/benefit against option 1 and option 2 above.

Thx,
Robert.

PS . Now option 1 can easily be sub second if BFD is enabled on IBGP
sessions between RRs and PEs. However I think there was some concerns
expressed in the past by a vendor for this type of deployment of BFD
between loopbacks. Maybe it would be beneficial for this discussion to
better understand this concern. If valid I think the option 2 which IMO is
the objective of this draft does present a valid problem to be solved.
Today practically speaking networks flood in IGPs globally 1000s of /32
prefixes instead of summarizing them as this is the only way they can
signal liveness of the remote PEs.




On Sat, Nov 14, 2020 at 10:34 PM Acee Lindem (acee)  wrote:

> Speaking as WG member…
>
>
>
> With respect to the use cases in section 3:
>
>
>
>   3.1 *Inter-Area Node Failure Scenario – *With respect to this use case,
> the node in question is actually unreachable. In this case, the ABRs will
> normally install a reject route for the advertised summary and will send an
> ICMP unreachable when the packets are received for the unreachable prefix.
> This is the expected behavior and there really isn’t that much of advantage
> to move the point of unreachable detection a couple hops closer. If faster
> detection is required, BFD or other mechanisms are available.
>
>
>
>   3.3 *Intra-Area Node Failure Scenario *– In the first place, multiple
> areas with overlapping summaries is just a bad network design. If the
> prefix is unreachable, the case digresses to getting the ICMP unreachable
> from the ABR with the invalid overlapping summary.
>
>
>
> 3.2 *Inter-Area Links Failure Scenario – *This is the case where the
> prefix is reachable but only through a subset of the area ABRs. This is
> really the only valid use case. IMO, it is better to solve this case with
> intra-area tunnels through the backbone as described in section 6.1. I
> think this is preferable to the complexity proposed in this draft and
> especially section 6. It is “interesting” when non-implementors specify
> implementation details.
>
>
>
> 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] 答复: WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

2020-11-14 Thread Robert Raszuk
Hi Huzhibo,

I would like to highlight another aspect of this draft independent in which
(if any) WG it will end up with.

Many network operators today to interconnect their routers purchase
circuits. However those circuits in vast majority use brilliant technology
of VPWS, L2VPN, EVPN ... you name it. So effectively the circuit is just an
illusion and what is really sold is an emulated circuit running as IP
encapsulated L2 packets on someone IP backbone.

And here comes the crux of the issue - depending on the time of the day,
state and events in the carrier's underlay real MTU changes. And today what
is worse routers have no good way to even detect it. Some attempts pop up
here and there (like stuff BFD to 1500 or so), but the point is that what
could be promised, sold and configured on the interface may not be what is
really under the hood.

Things get even more colorful when only some discrete packet sizes fail
while smaller and bigger go through just fine - Swiss-MTU if you will :)

Sure your proposal just uses static MTU like any other mentioned in your
draft consumer of that information but I am bringing it here for two
reasons:

A) Draft needs to consider this problem and discuss dynamics related to
real MTU changes

B) A discussion needs to be started if it would not be much more effective
to simply detect MTU at the data plane between the src and dst in an end to
end fashion rather then using it in control plane as a atomic piece of
assumed truth used to make any path calculation.

Kind regards,
R.
___
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-19 Thread Robert Raszuk
Aijun,

Regarding your appendix A -

* How can we "rebuild" topology based on comparison of prefixes and rtr-id
?

* If link between S1 & S2 is not in LSDB there may be a valid operational
reasons for it. "Rebuilding it" will be actually harmful from all points of
view.

* You should be exporting topology from all areas not just from backbone
and guessing the topology based on the prefix to rtr_id associations

* Imaging someone is using multiaccess in areas. Are you also going to
rebuild DR & BDR ?

I must agree with comments from Peter & Les here.

Cheers,
R.





On Mon, Oct 19, 2020 at 12:11 PM Aijun Wang  wrote:

> Hi. Peter, Les:
>
> We have defined many extensions for protocol, but only a small part of
> them are deployed. Have you ever considered the reason?
>
> Adding more contents for their  potential usages can certainly be helpful
> for their influences, or else, they will just stay at the IETF repository.
>
> More replies inline below.
>
>
>
> Aijun Wang
> China Telecom
>
> > On Oct 19, 2020, at 17:14, Peter Psenak  40cisco@dmarc.ietf.org> wrote:
> >
> > Aijun,
> >
> >> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
> >> Aijun -
> >> I am not going to continue these side discussions with you.
> >> The primary purpose of the protocol extensions are as stated in the
> draft Introduction. This is analogous to the use cases for the equivalent
> extensions for IS-IS already approved in RFC 7794. We need the equivalent
> in OSPF.
> >> You can show that you are listening to the concerns of WG members by
> removing the Appendices - in which case you have (I believe) broad support
> for moving the draft forward.
> >
> > I agree with Les.
> >
> > As a co-author, I have asked you several times to get rid of the use
> case described in appendix.
> [WAJ] Moving the expansion of this use case from body part of this draft
> to its appendix is our initial consensus, not remove it totally. We have
> discussed intensely for its application in vary situations. The discussion
> results are stated clearly in the appendix.
> Wish to hear more technical analysis/comments for the current statements
> of this part from other experts, or from you if you have fresh
> consideration.
>
> > Trying to use prefix advertisement to derive topological data is simply
> broken. The reason we are adding the prefix originator extension to OSPF is
> NOT the broken use case in the appendix of the draft.
> >
> > thanks,
> > Peter
> >
> >
> >
> >> You can then write a separate draft to discuss other use cases and
> allow the WG to discuss those other use cases w/o preventing the extensions
> from being approved and deployed for the use cases which have already been
> demonstrated as useful by IS-IS.
> >> If you remove the Appendices I can support the draft.
> >> If you do not remove the Appendices I cannot support the draft.
> >> Please discuss this with your co-authors and come to consensus on your
> next step.
> >>Les
> >>> -Original Message-
> >>> From: Aijun Wang 
> >>> Sent: Monday, October 19, 2020 12:06 AM
> >>> To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
> >>> 
> >>> Cc: 'John E Drake' ; lsr-cha...@ietf.org;
> lsr@ietf.org;
> >>> 'Jeff Tantsura' ; draft-ietf-lsr-ospf-prefix-
> >>> origina...@ietf.org; lsr-...@ietf.org
> >>> Subject: RE: [Lsr] WG Last Call
> draft-ietf-lsr-ospf-prefix-originator-06
> >>>
> >>> Hi, Les:
> >>>
> >>> As I stated clearly before, the appendix described in the draft is not
> the new
> >>> use case. It is the start point of this draft.
> >>> Have you noticed that the introduction part is not the final usage of
> such
> >>> protocol extension information?
> >>> Certainly, we will not expand all the possible use cases in very
> detail, but
> >>> putting some of them(some interesting, prominent use cases) in the
> >>> appendix will not hamper the protocol extension itself.
> >>>
> >>> If the statements/descriptions in the appendix are not correct, we can
> fix it,
> >>> or remove it finally.  If not, why not let it be for reference to the
> user of such
> >>> protocol extension?
> >>> For the body part of this draft, we are also welcome comments.
> >>>
> >>> More replies inline below[WAJ]
> >>>
> >>> Best Regards
> >>>
> >>> Aijun Wang
> >>> China Telecom
> >>>
> >>> -Original Message-
> >>> From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of
> Les
> >>> Ginsberg (ginsberg)
> >>> Sent: Monday, October 19, 2020 2:15 PM
> >>> To: Aijun Wang ; 'Christian Hopps'
> >>> 
> >>> Cc: 'John E Drake' ; lsr-cha...@ietf.org; 'Les
> Ginsberg
> >>> (ginsberg)' ; lsr@ietf.org; 'Jeff
> >>> Tantsura' ; draft-ietf-lsr-ospf-prefix-
> >>> origina...@ietf.org; lsr-...@ietf.org
> >>> Subject: Re: [Lsr] WG Last Call
> draft-ietf-lsr-ospf-prefix-originator-06
> >>>
> >>> Aijun -
> >>>
> >>> The "use case" for the protocol extensions is clearly stated in the
> >>> Introduction:
> >>>
> >>> "The primary use case for the extensions proposed in this document is
> >>>to be able 

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

2020-10-13 Thread Robert Raszuk
Peter,

If this is per app how are the constraints shared across apps ?

See we have single physical resources (for example links) and single
interface outbound queues. If I use per app flex-algo and do not have
central controller how is this going to work in practice for any network
which attempts to use more then one forwarding schema with dynamic
constraints ?

Many thx,
R.



On Tue, Oct 13, 2020 at 10:52 AM Peter Psenak  wrote:

> Hi Jimmy,
>
> On 13/10/2020 10:02, Dongjie (Jimmy) wrote:
> > Hi Peter,
> >
> > Thanks for your reply. Please see further inline:
> >
> >> -Original Message-
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> >> Sent: Monday, October 12, 2020 4:39 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 10/10/2020 05:05, Dongjie (Jimmy) wrote:
> >>> 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?
> >>
> >> correct.
> >>
> >>>
> >>> 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.
> >>
> >> just to use the correct terminology, we should use "participate"
> instead of
> >> "support".
> >
> > Agree.
> >
> >>
> >>> 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? If so, how could this node know
> the
> >> binding of FA to different data planes on other nodes?
> >>
> >> again, it is the participation problem.
> >>
> >> Nodes that participate in the SR Flex-algo 128 will advertise the
> participation
> >> using the SR-Algorithm Sub-TLV. Only these nodes will be used during
> the SR
> >> flex-algo computation for algo 128.
> >>
> >> Nodes that participate in IP flex-algo 128 will advertise the
> participation using
> >> the IGP Algorithm Sub-TLV. Only these nodes will be used during the IP
> flex-algo
> >> computation for algo 128.
> >
> > Agree that if participation to Flex-Algo is advertised in a data plane
> specific manner, then path computation with Flex-Algo constraints could be
> done only using nodes which bind the Flex-Algo to the same data plane.
>
> it's per app, not per data plane, but yes, that is what the base
> flex-algo spec mandates.
>
> >
> > As Robert asked and you confirmed, this implies each data plane needs to
> be treated as an independent application of Flex-Algo. We have SR-Algorithm
> sub-TLV and IP Algorithm sub-TLV, while there are actually more data planes
> to be considered: SR-MPLS, SRv6, IPv4, IPv6, etc., does this mean that
> Flex-Algo participation needs to be advertised for SR-MPLS, SRv6, IPv4,
> IPv6, etc. separately?
>
> yes, it needs to be advertised per app. We have SR specific algo
> participation, we need one for IP as proposed in Ron's draft.
>
> Regarding IPv4 vs IPv6, it's up to the authors whether they want to make
> the participation for IP flex-algo topology specific or topology
> independent, both could work.
>
> Here's the text from the base flerx-algo draft:
>
> 10.2.  Advertisement of Node Participation for Other Applications
>
> This section describes considerations related to how other
> applications can advertise their participation in a specific Flex-
> Algorithm.
>
> Application-specific Flex-Algorithm participation advertisements MAY
> be topology specific or MAY be topology independent, depending on the
> application itself.
>
> Application-specific advertisement for Flex-Algorithm participation
> MUST be defined for each application and is outside of the scope of
> this document.
>
> thanks,
> Peter
>
>
> >
> > Best regards,
> > Jie
> >
> >>
> >> thanks,
> >> Peter
> >>
> >>>
> >>> 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 

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

2020-10-12 Thread Robert Raszuk
Hey Peter,

To me the application here is "avoid red links" regardless of choice of
encap in the data plane.

Does it really make sense to separate advertisements of SR flex-algo vs IP
flex-algo into separate TLVs ?

Along the same linkes even for SR data plane can be SR-MPLS or SRv6. So in
the network running all three data planes you will need to compute SPT for
each flex-algo three times which may or may not be desired especially if
each algorithm would be as simple as to avoid certain link color.

That goes to the point can dataplanes interwork in flex algo and it seems
that currently they can not if section 10.2 is interpreted as application
to be a tuple of data plane + topological constraints (instead of only
topological constraints).

Thx,
R.







On Mon, Oct 12, 2020 at 10:47 AM Peter Psenak  wrote:

> Hi Jimmy.
>
> On 12/10/2020 09:12, Dongjie (Jimmy) wrote:
> > Hi Jeff,
> >
> > Thanks for your explanation. I understand that for different data plane
> the SIDs or IP addresses have different scope, and will not conflict in
> normal cases.
> >
> > My question is more about whether a computation node needs to know and
> check which data plane is used by the intermediate nodes to bind to the
> Flex-Algo? In another word, can an SR path computed using Flex-Algo 128 go
> through an intermediate node which bind Flex-Algo 128 to IP data plane?
>
> computation node MUST check the application specific participation in
> flex-algo and participation advertisement is application specific. SR
> and IP are different applications from flex-algo perspective.
>
>
> draft-ietf-lsr-flex-algo-12, section 10.2:
>
>
> Application-specific advertisement for Flex-Algorithm participation
> MUST be defined for each application
>
> thanks,
> Peter
>
> >
> > Best regards,
> > Jie
> >
> >> -Original Message-
> >> From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
> >> Sent: Sunday, October 11, 2020 3:14 AM
> >> 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
> >>
> >> 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 

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

2020-10-03 Thread Robert Raszuk
> Can two nodes that run two different flex algo become ospf or isis
neighbors?

It is my understanding that those nodes always will become ospf neighbours
as you still run default topology on all of them. I have not seen a case
where flex algo topology can be enabled without default topology.

Thx,
R.

On Sat, Oct 3, 2020 at 2:14 AM Gyan Mishra  wrote:

>
> Hi  Jeff
>
> From a domain perspective where you have a group of nodes and associated
> IP addressed and SID are part of a discrete underlay instance flex algo
> topology.  On those same set of nodes you could have another topology and
> associated address and SIDs for a different flex algo.  How this would work
> is that the topologies would have to be segregated from each other as
> different MT instances or routing process instances.  Is that correct?
>
> Can two nodes that run two different flex algo become ospf or isis
> neighbors?
>
> Kind Regards
>
> Gyan
>
> On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura 
> wrote:
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 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" <
>> lsr-boun...@ietf.org on 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>
> 
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr 

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

2020-09-30 Thread Robert Raszuk
Peter,

Granted - you can do this with MPLS encapsulation.

But if you are doing native IP forwarding or SRv6 I am still unclear.

Imagine you get allocated by RIR say IPv4 /16 or IPv6  /32.

So you take some part of that block and use it for flex algo next hops ..
flood it via IGP and have flex algo F1 running/enabled on some nodes. So
far so good.

But what prevents the non enabled nodes to still use for those next hops
less specific say /8 from someone else in the Internet ?

Sure in some implementations (we both are a bit familiar with) we have a
way to track that next hop is declared unreachable if it was learned from
prefix shorter then /X. But this constrain seems to be not documented
anywhere in respect to flex algo. At min I think IP flex algo use should
make it clear and make it also a MUST.

So my point is that for SRv6 or Ron's proposal next hop MUST be only
learned via local IGP or be of no less then /X to be used for BGP next hop
resolution.

Many thx,
R,







On Wed, Sep 30, 2020 at 5:18 PM Peter Psenak  wrote:

> Robert,
>
> On 30/09/2020 16:28, Robert Raszuk wrote:
> > Peter,
> >
> > Let's see if we are talking about the same thing ...
> >
> > Take SRv6 as example ... You can run flex algorithm only on selected
> > segment endpoints as you do encap and dst rewrite. So rest of the
> > network (P/transit routers) do not need to have a clue about any
> > flex-algo other then plain old SPF.
>
> if all transit nodes do not participate/understand flex-algo, you will
> not be able to route the traffic between the segment endpoints based on
> the flex-algo, in other words algo specific locators will not be reachable.
>
> >
> > Now in Ron's case where there is no encap and you are applying flex-algo
> > to naked packets don't you think there is a difference and a bit of
> > deployment difficulty to make it work ?
>
> it is the same as with SRv6 locator - prefix associated with algorithm,
> with some additional SRv6 data. From the flex-algo calculation and
> forwarding perspective there is no difference.
>
> >
> > So assume one P node will not support it. This is native IP switching so
> > BGP advertises routes with new flex-algo next hop. If that next hop is
> > unreachable as signalling to that flex algo loopback was not understood
> > by P (new signalling extension) packets will be dropped.
>
> such P node would never ever be in the flex-algo forwarding path for
> prefix associated with flex-algo. We are talking underlay here, not BGP.
> BGP service allocates the SRV6 SID from the algo specific locator in
> case of SRv6. It can pick the NH as algo specific prefix I assume and
> the rest is the same.
>
> >
> > But what if that next hop would happen to be covered by some aggregate
> > route not subject perhaps to intended IP TE ?
>
> aggregation needs to be algo aware for it to work.
>
> thanks,
> Peter
>
>
> >
> > Cheers,
> > R.
> >
> >
> >
> > On Wed, Sep 30, 2020 at 2:11 PM Peter Psenak  > <mailto:ppse...@cisco.com>> wrote:
> >
> > Hi Robert,
> >
> > On 30/09/2020 09:28, Robert Raszuk wrote:
> >  > Hi,
> >  >
> >  >  > It uses the HBH option
> >  >
> >  > Currently Ron's proposal seems to work well for both IPv4 and IPv6
> >  > addresses. I hope this discussion will not try to derail it to
> > IPv6 only
> >  > track.
> >  >
> >  > I see no issue with loopback to flexible algorithm mapping in 1:1
> > fashion.
> >  >
> >  > I do however see some issues in deploying such technology as it
> will
> >  > only work well if *all* nodes in the network support this new
> >  > functionality. In contrast in SR world or control plane based TE I
> >  > proposed or any encapsulation based proposal only anchor nodes
> > need to
> >  > support the new functionality while rest of the network does not
> > need to
> >  > be even aware about it.
> >
> > above is not really true.
> >
> > Algo participation needs to be signaled, one way or the other. It's
> > done
> > for SR as well. There is no need for all routers to understand
> > flex-algo, as only those that participate (and as a result also
> > understand it) will be used during the flex-algo path computation and
> > consequently flex-algo specific forwarding. This applies to
> > flex-algo in
> > general, regardless of the data plane being used.
> >
> > thanks,
> > Peter
> >
>

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

2020-09-30 Thread Robert Raszuk
Peter,

Let's see if we are talking about the same thing ...

Take SRv6 as example ... You can run flex algorithm only on selected
segment endpoints as you do encap and dst rewrite. So rest of the network
(P/transit routers) do not need to have a clue about any flex-algo
other then plain old SPF.

Now in Ron's case where there is no encap and you are applying flex-algo to
naked packets don't you think there is a difference and a bit of deployment
difficulty to make it work ?

So assume one P node will not support it. This is native IP switching so
BGP advertises routes with new flex-algo next hop. If that next hop is
unreachable as signalling to that flex algo loopback was not understood by
P (new signalling extension) packets will be dropped.

But what if that next hop would happen to be covered by some aggregate
route not subject perhaps to intended IP TE ?

Cheers,
R.



On Wed, Sep 30, 2020 at 2:11 PM Peter Psenak  wrote:

> Hi Robert,
>
> On 30/09/2020 09:28, Robert Raszuk wrote:
> > Hi,
> >
> >  > It uses the HBH option
> >
> > Currently Ron's proposal seems to work well for both IPv4 and IPv6
> > addresses. I hope this discussion will not try to derail it to IPv6 only
> > track.
> >
> > I see no issue with loopback to flexible algorithm mapping in 1:1
> fashion.
> >
> > I do however see some issues in deploying such technology as it will
> > only work well if *all* nodes in the network support this new
> > functionality. In contrast in SR world or control plane based TE I
> > proposed or any encapsulation based proposal only anchor nodes need to
> > support the new functionality while rest of the network does not need to
> > be even aware about it.
>
> above is not really true.
>
> Algo participation needs to be signaled, one way or the other. It's done
> for SR as well. There is no need for all routers to understand
> flex-algo, as only those that participate (and as a result also
> understand it) will be used during the flex-algo path computation and
> consequently flex-algo specific forwarding. This applies to flex-algo in
> general, regardless of the data plane being used.
>
> thanks,
> Peter
>
>
> >
> > Many thx,
> > R.
> >
> >
> > On Wed, Sep 30, 2020 at 6:10 AM Huzhibo  > <mailto:huzh...@huawei.com>> wrote:
> >
> > Hi Joel:
> >
> >  For details about the method defined in RFC 6550. It uses the
> > HBH option to carry the RPLInstaceID. The RPLInstaceID and
> > FlexAlgoID are similar.
> >
> > Thanks
> >
> > Zhibo
> >
> > -Original Message-
> > From: Lsr [mailto:lsr-boun...@ietf.org
> > <mailto:lsr-boun...@ietf.org>] On Behalf Of Joel M. Halpern
> > Sent: Wednesday, September 30, 2020 12:05 PM
> > Cc: lsr@ietf.org <mailto:lsr@ietf.org>
> > Subject: Re: [Lsr] New Version Notification for
> > draft-bonica-lsr-ip-flexalgo-00.txt
> >
> > I am missing something in this discussion of multiple algorithms.
> >
> > My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6,
> > is that you need to associated a forwarding label (e.g. MPLS label
> > or IPv6
> > address) with a specific algorithm so that you can compute the next
> > hope for the forwarding label using the proper algorithm.  Then when
> > a packet arrives, it is simply forwarded according to the forwarding
> > table (e.g.
> > FIB, LIB, ..)
> >
> > If that is so, then I do not understand how a given prefix can be
> > safely associated with more than one algorithm.  I could imagine
> > doing several calculations according to different algorithms.  But
> > how do you decide which one applies to the packet?  As far as I
> > know, flex-algo does not look at the QoS/CoS/ToS bits.
> >
> > Yours,
> > Joel
> >
> > PS: I will admit that it took until  an operator described some
> > "interesting" constraints before I understood why one would even do
> > this.
> >
> > On 9/29/2020 11:50 PM, Huzhibo wrote:
> >  > Hi.
> >  >
> >  > Associating multiple algorithms with a given prefix is an
> > interesting topic, and I think this can simplify the complexity of
> > FlexAlgo. I wonder if the author would consider using cases with
> > multiple algorithms with a given prefix.
> >  >
> >  > Thanks
> >  >
> >  > ZHibo
> >  >
> >  > -Original Message-
> >  > Fro

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

2020-09-30 Thread Robert Raszuk
Hi,

> It uses the HBH option

Currently Ron's proposal seems to work well for both IPv4 and IPv6
addresses. I hope this discussion will not try to derail it to IPv6 only
track.

I see no issue with loopback to flexible algorithm mapping in 1:1 fashion.

I do however see some issues in deploying such technology as it will only
work well if *all* nodes in the network support this new functionality. In
contrast in SR world or control plane based TE I proposed or any
encapsulation based proposal only anchor nodes need to support the new
functionality while rest of the network does not need to be even aware
about it.

Many thx,
R.


On Wed, Sep 30, 2020 at 6:10 AM Huzhibo  wrote:

> Hi Joel:
>
> For details about the method defined in RFC 6550. It uses the HBH
> option to carry the RPLInstaceID. The RPLInstaceID and FlexAlgoID are
> similar.
>
> Thanks
>
> Zhibo
>
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Joel M. Halpern
> Sent: Wednesday, September 30, 2020 12:05 PM
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
>
> I am missing something in this discussion of multiple algorithms.
>
> My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6, is
> that you need to associated a forwarding label (e.g. MPLS label or IPv6
> address) with a specific algorithm so that you can compute the next hope
> for the forwarding label using the proper algorithm.  Then when a packet
> arrives, it is simply forwarded according to the forwarding table (e.g.
> FIB, LIB, ..)
>
> If that is so, then I do not understand how a given prefix can be safely
> associated with more than one algorithm.  I could imagine doing several
> calculations according to different algorithms.  But how do you decide
> which one applies to the packet?  As far as I know, flex-algo does not look
> at the QoS/CoS/ToS bits.
>
> Yours,
> Joel
>
> PS: I will admit that it took until  an operator described some
> "interesting" constraints before I understood why one would even do this.
>
> On 9/29/2020 11:50 PM, Huzhibo wrote:
> > Hi.
> >
> > Associating multiple algorithms with a given prefix is an interesting
> topic, and I think this can simplify the complexity of FlexAlgo. I wonder
> if the author would consider using cases with multiple algorithms with a
> given prefix.
> >
> > Thanks
> >
> > ZHibo
> >
> > -Original Message-
> > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
> > Sent: Tuesday, September 29, 2020 10:05 PM
> > To: Ron Bonica 
> > Cc: lsr@ietf.org
> > Subject: Re: [Lsr] New Version Notification for
> > draft-bonica-lsr-ip-flexalgo-00.txt
> >
> >
> > Ron,
> >
> > This is nice. It makes it clear that constraint based path computation
> need not have MPLS overhead for those that don’t want it.
> >
> > One thing that you don’t talk about is how this gets used, tho that may
> be blindingly obvious: you’ll need all nodes placing their prefixes in the
> RIB/FIB, where it will need to be selected over other path computation for
> the same prefixes.  This somewhat precludes the possibility of a given
> prefix being useful in multiple flex-algos.
> >
> > More text on application would be most welcome, just to ensure that
> we’re on the same page.
> >
> > Tony
> >
> >
> >> On Sep 29, 2020, at 6:37 AM, Ron Bonica  40juniper@dmarc.ietf.org> 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-b
> >>> o
> >>> nica-lsr-
> >>> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
> >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
> >>> Htmlized:
> >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr
> >>> a
> >>> ft-
> >>> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
> >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
> >>> Htmlized:
> 

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-09-09 Thread Robert Raszuk
Hi,

Intra area ?

If we are flooding host routes I have never seen a case where intra area
those are not flooded.

Where would you summarise ? On a node within area ?

Very unreal scenario IMHO.

Thx
R.

On Wed, Sep 9, 2020, 03:22 Aijun Wang  wrote:

> Hi, Robert:
>
>
>
> PUA covers both the intra-area and inter-area scenarios.
>
> For inter-area scenario, it covers the situation that the next-hop is
> reachable via one ABR but unreachable via another ABR.
>
> For such situation, BGP nexthop tracking, route withdraw or aggregate
> withdraw will not work.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of 
> *Robert
> Raszuk
> *Sent:* Monday, September 7, 2020 5:36 PM
> *To:* Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra <
> hayabusa...@gmail.com>; Peter Psenak ;
> Huzhibo ; Aijun Wang ; lsr <
> lsr@ietf.org>; Acee Lindem (acee) ; Xiaoyaqun <
> xiaoya...@huawei.com>; Tony Przygienda 
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> Hi Aijun,
>
>
>
> > the BGP next-hop is reachable
>
>
>
> Nope you missed the crux of the message.
>
>
>
> The next hop will be unreachable in the *source area/level. *That would
> be where the BGP service route withdraw or aggregate withdraw would
> originate at. Same as PUA.
>
>
>
> Best,
>
> Robert.
>
>
>
>
>
> On Mon, Sep 7, 2020 at 11:31 AM Aijun Wang 
> wrote:
>
> Hi, Robert:
>
> For BGP next-hop tracking, it will help when the BGP next-hop is
> unreachable. But in our situation, the BGP next-hop is reachable, but
> should pass another ABR.
>
> Then, in such situation, the mechanism of BGP next-hop tracking will not
> take effect?
>
> And thanks for your draft information, maybe we can refer to it later J
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of 
> *Robert
> Raszuk
> *Sent:* Monday, September 7, 2020 4:54 PM
> *To:* Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra <
> hayabusa...@gmail.com>; Peter Psenak ;
> Huzhibo ; Aijun Wang ; lsr <
> lsr@ietf.org>; Acee Lindem (acee) ; Xiaoyaqun <
> xiaoya...@huawei.com>; Tony Przygienda 
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> Hi Aijun,
>
> *[WAJ] If necessary, we can advertise the MAX_T_PUA(configurable time for
> the hold of PUA information on the nodes) among the area.*
>
> *If one node connect to the network after the disappearance of the PUA
> destination,  there will be no services can be established/run on these
> failure node/link prefix. *
>
> *It**’s the same as the beginning, as not all of the prefixes can be
> reachable within the summary address.*
>
>
>
> From my pov the only advantage of negative routes in IGP would be to very
> quickly invalidate service routes (within the IGP domain) typically carried
> by BGP.
>
>
>
> When this is accomplished the PUA can indeed time out with no harm.
>
>
>
> Said this - now considering tools like next hop tracking which can trigger
> withdraw or aggregated withdraw(*) proposal in src area I am  really
> curious how much (if anything) we would be gaining here.
>
>
>
> (*) The original proposal for this was written over 15 years ago:
> https://tools.ietf.org/html/draft-raszuk-aggr-withdraw-00  We could
> extend it with next hop which would be the same as IGP PUA prefix.
>
>
>
> Kind regards,
> Robert
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-09-07 Thread Robert Raszuk
Hi Aijun,

> the BGP next-hop is reachable

Nope you missed the crux of the message.

The next hop will be unreachable in the *source area/level. *That would be
where the BGP service route withdraw or aggregate withdraw would originate
at. Same as PUA.

Best,
Robert.


On Mon, Sep 7, 2020 at 11:31 AM Aijun Wang 
wrote:

> Hi, Robert:
>
> For BGP next-hop tracking, it will help when the BGP next-hop is
> unreachable. But in our situation, the BGP next-hop is reachable, but
> should pass another ABR.
>
> Then, in such situation, the mechanism of BGP next-hop tracking will not
> take effect?
>
> And thanks for your draft information, maybe we can refer to it later J
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of 
> *Robert
> Raszuk
> *Sent:* Monday, September 7, 2020 4:54 PM
> *To:* Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra <
> hayabusa...@gmail.com>; Peter Psenak ;
> Huzhibo ; Aijun Wang ; lsr <
> lsr@ietf.org>; Acee Lindem (acee) ; Xiaoyaqun <
> xiaoya...@huawei.com>; Tony Przygienda 
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> Hi Aijun,
>
> *[WAJ] If necessary, we can advertise the MAX_T_PUA(configurable time for
> the hold of PUA information on the nodes) among the area.*
>
> *If one node connect to the network after the disappearance of the PUA
> destination,  there will be no services can be established/run on these
> failure node/link prefix. *
>
> *It**’s the same as the beginning, as not all of the prefixes can be
> reachable within the summary address.*
>
>
>
> From my pov the only advantage of negative routes in IGP would be to very
> quickly invalidate service routes (within the IGP domain) typically carried
> by BGP.
>
>
>
> When this is accomplished the PUA can indeed time out with no harm.
>
>
>
> Said this - now considering tools like next hop tracking which can trigger
> withdraw or aggregated withdraw(*) proposal in src area I am  really
> curious how much (if anything) we would be gaining here.
>
>
>
> (*) The original proposal for this was written over 15 years ago:
> https://tools.ietf.org/html/draft-raszuk-aggr-withdraw-00  We could
> extend it with next hop which would be the same as IGP PUA prefix.
>
>
>
> Kind regards,
> Robert
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-09-07 Thread Robert Raszuk
Hi Aijun,

> *[WAJ] If necessary, we can advertise the MAX_T_PUA(configurable time for
> the hold of PUA information on the nodes) among the area.*
>
> *If one node connect to the network after the disappearance of the PUA
> destination,  there will be no services can be established/run on these
> failure node/link prefix. *
>
> *It’s the same as the beginning, as not all of the prefixes can be
> reachable within the summary address.*
>
>
>From my pov the only advantage of negative routes in IGP would be to very
quickly invalidate service routes (within the IGP domain) typically carried
by BGP.

When this is accomplished the PUA can indeed time out with no harm.

Said this - now considering tools like next hop tracking which can trigger
withdraw or aggregated withdraw(*) proposal in src area I am  really
curious how much (if anything) we would be gaining here.

(*) The original proposal for this was written over 15 years ago:
https://tools.ietf.org/html/draft-raszuk-aggr-withdraw-00  We could extend
it with next hop which would be the same as IGP PUA prefix.

Kind regards,
Robert
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-09-03 Thread Robert Raszuk
Hi Huaimo,


> > Users can define a zone (a block of an area) and the zone can be any
> block of the area that users decide. Thus, using TTZ seems simpler than
> using Areas for scalability. It uses less planning effort and less
> configurations.
>
>
Q1 - Can zones overlap ? IE. can any node be in the same time in
multiple zones ?

Q2 - Can zones be nested ?

Q3 - Can zone boundary span across two or more areas ?

> [HC]:  The requirement for flooding of host routes domain wide is
considered in section 4.1.3 of TTZ draft.

Well all it says that loopbacks can be included. That in no way addresses
the scalability aspect if those loopbacks are to be flooded domain wide
anyway.

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


Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-09-02 Thread Robert Raszuk
> - The transition mechanisms

Hmmm maybe I missed some explanations by authors, but to me concept of
zones is positioned as an addition to the concept of areas or levels - not
a replacement of those.

So when you say "transition" means that something existing no longer would
be in place after successful deployment of a new thing.

Here I am actually not sure if IGP domain could be only constructed with
zones without areas ?

Of course said all of the above I am still not seeing any value in the
proposed new abstraction regardless if such abstraction would be positioned
to exist in parallel to areas/levels or by definition be nested within the
area/level.

r.

On Wed, Sep 2, 2020 at 4:48 PM  wrote:

>
> Hi Xueson,
>
> My intension was not to talk about math/engineering/marketing or compare
> the size of marketing department. Them are not relevant to this thread.
>
>
>
> You are the one who suggested we leave it up to the market…
>
> I want to make clear about IETF process. In my understanding the document
> does not need to be perfect at this stage, as long as it is in the right
> direction to solve some acknowledged problem( IGP scalability). Comments
> will be helpful if it could provide ideas about how to improve.
>
>
>
> That’s what we’ve been trying to tell you all along:
>
> - If there is a benefit to zones, it’s not clear to us.  You need to do a
> better job articulating that.
>
> - The transition mechanisms seem awkward and painful. Can you reduce the
> complexity?
>
> But IMO the discussion in the mailing list about this draft has gone off
> the rails of technology, including keeping challenging tradeoff between
> value and complexity, which seems reasonable at the first sight, but at
> this stage, has turned out to be a question with no right answer and may
> bring endless argument.
>
>
>
> Technology is all about maximizing benefits while minimizing costs.  This
> is why we don’t wire houses using gold and silver.
>
> Yes, this does seem to be an endless argument.  Welcome to the IETF.
>
> 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 WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-09-02 Thread Robert Raszuk
>  acknowledged problem (IGP scalability)

Great so we see the problem description. This is progress !

Allow me to observe two points:

* IGP scalability can be easily solved with the additional levels of
current abstraction instead of introducing new types of abstraction into
it. Ref: draft-ietf-lsr-isis-extended-hierarchy

* Most scaling aspects I have seen in practical deployments with IGPs are
not caused by the suboptimal protocol design. Those are caused by
requirements introduced by some transport technologies which (at least
originally) required flooding of host routes domain wide for exact match of
FECs to prefixes. I do not see how TTZs would address that aspect in any
better way than areas can.

Thx,
R.


On Wed, Sep 2, 2020 at 10:00 AM Gengxuesong (Geng Xuesong) <
gengxues...@huawei.com> wrote:

> Hi Tony,
>
>
>
> My intension was not to talk about math/engineering/marketing or compare
> the size of marketing department. Them are not relevant to this thread.
>
> I want to make clear about IETF process. In my understanding the document
> does not need to be perfect at this stage, as long as it is in the right
> direction to solve some acknowledged problem( IGP scalability). Comments
> will be helpful if it could provide ideas about how to improve.
>
> But IMO the discussion in the mailing list about this draft has gone off
> the rails of technology, including keeping challenging tradeoff between
> value and complexity, which seems reasonable at the first sight, but at
> this stage, has turned out to be a question with no right answer and may
> bring endless argument.
>
>
>
>
>
> Thanks
>
> Xuesong
>
>
>
> *From:* Tony Li [mailto:tony1ath...@gmail.com] *On Behalf Of *
> tony...@tony.li
> *Sent:* Wednesday, September 2, 2020 12:07 PM
> *To:* Gengxuesong (Geng Xuesong) 
> *Cc:* Huaimo Chen ; Les Ginsberg (ginsberg)
> ; Les Ginsberg ;
> Acee Lindem (acee) ; lsr@ietf.org
> *Subject:* Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent
> Zone" - draft-chen-isis-ttz-11.txt
>
>
>
>
>
> Hi Xuesong,
>
>
>
> Apologies first if I have missed any history of this discussion. But I’m
> not sure that we have to evaluate whether a method is “optimal” before WG
> adoption. Why not adopt some alternative solutions and leave the choice to
> industry/market?
>
>
>
>
>
> First off, this is engineering, not theoretical math.  Optimal is not the
> issue. Heck, optimal isn’t even a goal.
>
>
>
> What we are looking for is value and value that outweighs the complexity.
>
>
>
> Leaving the choice to the market is a bad idea. The market does NOT make
> sound technical decisions. It makes pseudo-random decisions not based on
> technical merits. The canonical example here is VHS vs Betamax. Better
> technology lost.
>
>
>
> Second, the market is unduly influenced by marketing. The size of your
> marketing department exceeds the size of my entire (not tiny) company. And
> it’s still second to that of Cisco.
>
>
>
> Marketing does not make good technical and architectural decisions. That’s
> our job.
>
>
>
> 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 WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-09-02 Thread Robert Raszuk
> people need to spend their time in deciding where is the boundary between
the two areas

Oh then I perhaps completely missed the value and power of TTZ.

It seems that in TTZ instead of careful planning of your abstractions the
plan is to randomly create zones and see what happens - is this right
reading of your explanation ?

Many thx,
R.

On Wed, Sep 2, 2020 at 6:58 AM Huaimo Chen 
wrote:

> Hi Tony,
>
> It seems that splitting L1 area A1 into two L1 areas A11 and A12
> cannot be automated without people's planning. Some people need to spend
> their time in deciding where is the boundary between the two areas and
> selecting a router in the backbone domain for Attach bit for one of the two
> areas. These corresponds to step 1) and 3) for using Areas.
>
> Best Regards,
> Huaimo
> --
> *From:* Tony Li  on behalf of tony...@tony.li <
> tony...@tony.li>
> *Sent:* Wednesday, September 2, 2020 12:09 AM
> *To:* Huaimo Chen 
> *Cc:* Les Ginsberg ; Les Ginsberg (ginsberg)
> ; Acee Lindem (acee)  40cisco@dmarc.ietf.org>; lsr@ietf.org 
> *Subject:* Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent
> Zone" - draft-chen-isis-ttz-11.txt
>
>
> Hi Huaimo,
>
> Assume that a big L1 area (say Area A1) is connected to backbone
> domain.
> Let us compare TTZ and Areas for scalability.
>
> Using TTZ, we need two steps below:
> 1) configure a piece of Area A1, named P1, as a zone; and
> 2) transfer P1 to a virtual node using one command or two.
>
> Using Areas, we need four steps below to split Area A1 into two L1
> areas A11 and A12:
> 1) configure the edges between A11 and A12 as L2/L1 to backbone domain;
> 2) add/configure a new area address on the routers in target Area A12;
> 3) configure Attach bit for A11 or A12; and
> 4) delete the old area address from the routers in Area A12.
>
> Using TTZ is simpler than using Areas.
>
>
>
> I’m not quite sure I follow you.  Are you arguing that simplicity is
> achieved through the minimum number of configuration steps?
>
> If so, I’d like to introduce you to Arista CVP, our management platform,
> where all of this can be easily automated: 1 step.
>
> 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 WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-09-01 Thread Robert Raszuk
>
> [HC]: IS-IS TTZ or say Zone is one of a few drafts which
> experiment/explore new ways for scalability. These new ways may be simpler
> and have some other features.
>

While Tony very well explained the "may" part let me ask the "simpler"
part.

Simpler then what ?

Simpler when combined with existing levels of abstraction or when
taken alone in vaccume ?

The draft in question defines a new abstraction. But I would like to go
back to a very basic question:

What problem(s) are you solving ?

You say "new ways for scalability" - can you enumerate what is unscalable
in current areas or levels ?

Many thx,
Robert
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-08-25 Thread Robert Raszuk
Hi Tony & WG,

The changes which went into sections 4.3.2 & 4.4.13 do address my
suggestions made earlier to the list. So I do support the current version.

With the option of having a configurable area prefix this delivers quite a
powerful extension.

Also the current text says:

"Other uses of the Area SID are outside the scope of this document. "

Maybe we could state instead:

Other uses of the Area SID and area prefix are outside the scope of this
document.

Many thx,
R.


On Mon, Aug 24, 2020 at 7:02 PM  wrote:

>
> Hi folks,
>
> This updated draft has been published for a few weeks now.  We would like
> to solicit your opinion on this.  In particular, we have changed the
> encoding of the Area SID.  Do you find this encoding adequate and
> appropriate?
>
> Thanks,
> Tony
>
>
> Begin forwarded message:
>
> *From: *internet-dra...@ietf.org
> *Subject: **I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt*
> *Date: *August 5, 2020 at 1:17:39 PM PDT
> *To: *
> *Cc: *lsr@ietf.org
> *Reply-To: *internet-dra...@ietf.org, lsr@ietf.org
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Link State Routing WG of the IETF.
>
>Title   : Area Proxy for IS-IS
>Authors : Tony Li
>  Sarah Chen
>  Vivek Ilangovan
>  Gyan S. Mishra
> Filename: draft-ietf-lsr-isis-area-proxy-03.txt
> Pages   : 19
> Date: 2020-08-05
>
> Abstract:
>   Link state routing protocols have hierarchical abstraction already
>   built into them.  However, when lower levels are used for transit,
>   they must expose their internal topologies to each other, leading to
>   scale issues.
>
>   To avoid this, this document discusses extensions to the IS-IS
>   routing protocol that would allow level 1 areas to provide transit,
>   yet only inject an abstraction of the level 1 topology into level 2.
>   Each level 1 area is represented as a single level 2 node, thereby
>   enabling greater scale.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-03
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-08-19 Thread Robert Raszuk
Hi Richard,

I understand that these days you say "5G" and you are done for any use
case. :)

So I read this paper:
https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp28_mec_in_5G_FINAL..pdf

There is nothing there which would indicate a need for zone or even area
separation to effectively deploy MEC. To me MEC data path can be
constructed with a form of encapsulation in an arbitrary fashion. In fact I
could say the more underlay walls you implement the harder it becomes to
construct arbitrary MEC mesh.

At least for LSR WG if I were to justify any work here like TTZ I would
explain why Multi access edge computing requires IGP/underlay type of
separation and moreover why such separation can not be constructed with
areas or levels.

Thx,
R.

On Wed, Aug 19, 2020 at 5:18 AM Richard Li  wrote:

> This is a use case:
>
>
>
> The user plane of 5G is distributed, and MEC is deployed as part of the
> user plane to provide some functions at Access Aggregation Ring or Regional
> Aggregation Ring or at the border between Regional Aggregation Ring and the
> National Core. Using TTZ, MEC or part of it can be virtualized and
> topologically simplified. Note that the outside really doesn’t care about
> the internals of MEC.
>
>
>
>
>
> Thanks,
>
>
>
> Richard
>
>
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * Robert Raszuk
> *Sent:* Tuesday, August 18, 2020 2:25 PM
> *To:* Acee Lindem (acee) 
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent
> Zone" - draft-chen-isis-ttz-11.txt
>
>
>
> Dear WG,
>
>
>
> The draft in question does not describe even a single practical use case.
>
>
>
> While it describes the mechanics on how to construct the new model of the
> abstraction it fails to prove we need it.
>
>
>
> Not everything which can be invented should be standardized or implemented
> therefore until the document extensively describes the real use cases with
> justification why use of areas may not be sufficient for such use cases I
> don't think LSR WG should adopt it.
>
>
>
> Regards,
> Robert.
>
>
>
> On Tue, Aug 18, 2020 at 4:17 PM Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
>
>
>
> Based on the discussions in the last meeting and on the mailing list
> regarding draft-chen-isis-ttz-11, the chairs feel that there are enough
> differences with draft-ietf-lsr-isis-area-proxy-03 and in the community to
> consider advancing it independently on the experimental track.
>
>
>
> These differences include abstraction at arbitrary boundaries and IS-IS
> extensions for smooth transition to/from zone abstraction.
>
>
>
> We are now starting an LSR WG adoption call for
> draft-chen-isis-ttz-11.txt. Please indicate your support or objection to
> adoption prior to Tuesday, September 2nd, 2020.
>
>
>
> Thanks,
>
> Acee and Chris
>
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr=02%7C01%7Crichard.li%40futurewei..com%7Ccfd66b6c7fc54591ec0408d843bd4046%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637333827425070909=UgI0%2Bd6TyQtenEEoyU97R2qQJBlzRYuqS4XxhFjjcYA%3D=0>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-08-18 Thread Robert Raszuk
Dear WG,

The draft in question does not describe even a single practical use case.

While it describes the mechanics on how to construct the new model of the
abstraction it fails to prove we need it.

Not everything which can be invented should be standardized or implemented
therefore until the document extensively describes the real use cases with
justification why use of areas may not be sufficient for such use cases I
don't think LSR WG should adopt it.

Regards,
Robert.

On Tue, Aug 18, 2020 at 4:17 PM Acee Lindem (acee)  wrote:

>
>
> Based on the discussions in the last meeting and on the mailing list
> regarding draft-chen-isis-ttz-11, the chairs feel that there are enough
> differences with draft-ietf-lsr-isis-area-proxy-03 and in the community to
> consider advancing it independently on the experimental track.
>
>
>
> These differences include abstraction at arbitrary boundaries and IS-IS
> extensions for smooth transition to/from zone abstraction.
>
>
>
> We are now starting an LSR WG adoption call for
> draft-chen-isis-ttz-11.txt. Please indicate your support or objection to
> adoption prior to Tuesday, September 2nd, 2020.
>
>
>
> 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] WG Last Call for draft-ietf-lsr-flex-algo

2020-08-18 Thread Robert Raszuk
Les,

> and conclude that this is really “Unidirectional Link Delay” is a leap
that I cannot follow.

I would never suggest to do that.

My suggestion was to rename "Min Unidirectional Link Delay" to "minimum
value of Min/Max Unidirectional Link Delay" and move on.

Cheers,
R.



On Tue, Aug 18, 2020 at 9:18 PM Les Ginsberg (ginsberg) 
wrote:

> Tony/Robert –
>
>
>
> Whatever clarification Peter may choose to make would be fine – but I do
> question your casual ignoring of adjectives. 
>
>
>
> There are three values being advertised:
>
>
>
> 33 - Unidirectional Link Delay
>
> 34 – Min/Max Unidirectional Link Delay
>
>  Meaning two values are advertised in this codepoint:
>
>  Min Unidirectional Link Delay
>
>  Max Unidirectional Link Delay
>
>
>
> Now, the flex algo draft states: Min Unidirectional Link Delay
>
>
>
> If you want to argue that “Min Unidirectional Link Delay” != “Min/Max
> Unidirectional Link Delay” – I think you are pedantically correct.
>
>
>
> But how that leads you to simply truncate “Min” and conclude that this is
> really “Unidirectional Link Delay” is a leap that I cannot follow.
>
>
>
> Perhaps you don’t really like the fact that RFC 8570 encoding combined
> Min/Max in a single codepoint – but that ship sailed years ago.
>
>
>
> Given that RFC 8570 is very clear in showing that the encoding includes:
>
>
>
> 
>
>0   1   2   3
>
>  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|
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |A| RESERVED|   Min Delay   |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |   RESERVED|   Max Delay   |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> 
>
>
>
> my ability to see your POV is somewhat limited.
>
>
>
> Perhaps you could own that a more careful reading is possible?
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * tony...@tony.li
> *Sent:* Tuesday, August 18, 2020 10:03 AM
> *To:* Robert Raszuk 
> *Cc:* Christian Hopps ;
> draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org>; lsr@ietf.org; lsr-...@ietf.org; Acee Lindem
> (acee) ; Peter Psenak (ppsenak) 
> *Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
>
>
>
>
>
> Robert,
>
>
>
> Thank you, exactly.
>
>
>
> We just need a clarification of the document.  I don’t understand why this
> is such a big deal.
>
>
>
> Tony
>
>
>
>
>
> On Aug 18, 2020, at 9:22 AM, Robert Raszuk  wrote:
>
>
>
> Les,
>
>
>
> I think this is not very obvious as Tony is pointing out.
>
>
>
> See RFC 8570 says:
>
>
>
>   TypeDescription
>
>   
>
>33 Unidirectional Link Delay
>
>
>
>34 Min/Max Unidirectional Link Delay
>
>
>
> That means that is someone implementing it reads text in this draft
> literally (meaning Minimum value of Unidirectional Link Delay) it may pick
> minimum value from ULD type 33 :)
>
>
>
> If you want to be precise this draft may say minimum value of Min/Max
> Unidirectional Link Delay (34) and be done.
>
>
>
> That's all.
>
>
>
> Cheers,
> R.
>
>
>
>
>
>
>
> On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
> Tony –
>
>
>
> As an author of both RFC 8570 and I-D.ietf-isis-te-app, I am not sure why
> you are confused – nor why you got misdirected to code point 33.
>
>
>
> RFC 8570 (and its predecessor RFC 7810) define:
>
>
>
> 34   Min/Max Unidirectional Link Delay
>
>
>
> This sub-TLV contains two values:
>
>
>
> “Min Delay:  This 24-bit field carries the minimum measured link delay
>
>   value (in microseconds) over a configurable interval, encoded as
>
>   an integer value.
>
>
>
>Max Delay:  This 24-bit field carries the maximum measured link delay
>
>   value (in microseconds) over a configurable interval, encoded as
>
>   an integer value.”
>
>
>
> It seems clear to me that the flex-draft is referring to Min
> Unidirectional Link Delay in codepoint 34.
>
>
>
> I agree it is

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

2020-08-18 Thread Robert Raszuk
Hi Tony,

I am not sure what the deal is :)

But fact is that we never defined a type which this draft is referring to

"Min Unidirectional Link Delay" just does not exist in any IANA registry so
even any search for that will fail.

Perhaps authors assumed that:

Min/Max Unidirectional Link Delay means both "Min Unidirectional Link
Delay" & "Max Unidirectional Link Delay" but this is just asking
for ambiguity.

Cheers,
R.

On Tue, Aug 18, 2020 at 7:02 PM  wrote:

>
> Robert,
>
> Thank you, exactly.
>
> We just need a clarification of the document.  I don’t understand why this
> is such a big deal.
>
> Tony
>
>
> On Aug 18, 2020, at 9:22 AM, Robert Raszuk  wrote:
>
> Les,
>
> I think this is not very obvious as Tony is pointing out.
>
> See RFC 8570 says:
>
>   TypeDescription
>   
>33 Unidirectional Link Delay
>
>34 Min/Max Unidirectional Link Delay
>
>
> That means that is someone implementing it reads text in this draft
> literally (meaning Minimum value of Unidirectional Link Delay) it may pick
> minimum value from ULD type 33 :)
>
> If you want to be precise this draft may say minimum value of Min/Max
> Unidirectional Link Delay (34) and be done.
>
> That's all.
>
> Cheers,
> R.
>
>
>
> On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
>> Tony –
>>
>>
>>
>> As an author of both RFC 8570 and I-D.ietf-isis-te-app, I am not sure why
>> you are confused – nor why you got misdirected to code point 33.
>>
>>
>>
>> RFC 8570 (and its predecessor RFC 7810) define:
>>
>>
>>
>> 34   Min/Max Unidirectional Link Delay
>>
>>
>>
>> This sub-TLV contains two values:
>>
>>
>>
>> “Min Delay:  This 24-bit field carries the minimum measured link delay
>>
>>   value (in microseconds) over a configurable interval, encoded as
>>
>>   an integer value.
>>
>>
>>
>>Max Delay:  This 24-bit field carries the maximum measured link delay
>>
>>   value (in microseconds) over a configurable interval, encoded as
>>
>>   an integer value.”
>>
>>
>>
>> It seems clear to me that the flex-draft is referring to Min
>> Unidirectional Link Delay in codepoint 34.
>>
>>
>>
>> I agree it is important to be unambiguous in specifications, but I think
>> Peter has been very clear.
>>
>> Please explain how you managed to end up at code point 33??
>>
>>
>>
>>Les
>>
>>
>>
>>
>>
>>
>>
>> *From:* Lsr  *On Behalf Of * tony...@tony.li
>> *Sent:* Tuesday, August 18, 2020 7:44 AM
>> *To:* Peter Psenak (ppsenak) 
>> *Cc:* lsr@ietf.org; lsr-...@ietf.org; Christian Hopps ;
>> Acee Lindem (acee) ;
>> draft-ietf-lsr-flex-algo@ietf.org
>> *Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
>>
>>
>>
>>
>>
>> Hi Peter,
>>
>>
>>
>>
>>
>> section 5.1 of the draft-ietf-lsr-flex-algo says:
>>
>>
>> Min Unidirectional Link Delay as defined in [I-D.ietf-isis-te-app].
>>
>> We explicitly say "Min Unidirectional Link Delay", so this cannot be
>> mixed with other delay values (max, average).
>>
>>
>>
>>
>>
>> The problem is that that does not exactly match “Unidirectional Link
>> Delay” or “Min/Max Unidirectional Link Delay”, leading to the ambiguity.
>> Without a clear match, you leave things open to people guessing. Now, it’s
>> a metriic, so of course, you always want to take the min.  So type 33 seems
>> like a better match.
>>
>>
>>
>>
>>
>> section 7.3. of ietf-isis-te-app says:
>>
>> Type   Description  Encoding
>>Reference
>> -
>> 34  Min/Max Unidirectional Link DelayRFC8570
>>
>>
>>
>>
>>
>> And it also says:
>>
>>
>>
>> 33  Unidirectional Link DelayRFC8570 
>> <https://tools.ietf..org/html/rfc8570>
>>
>>
>>
>>
>>
>> This does not help.
>>
>>
>>
>>
>>
>> So, IMHO what we have now is correct and sufficient, but I have no issue
>> adding the text you proposed below.
>>
>&g

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

2020-08-18 Thread Robert Raszuk
Les,

I think this is not very obvious as Tony is pointing out.

See RFC 8570 says:

  TypeDescription
  
   33 Unidirectional Link Delay

   34 Min/Max Unidirectional Link Delay


That means that is someone implementing it reads text in this draft
literally (meaning Minimum value of Unidirectional Link Delay) it may pick
minimum value from ULD type 33 :)

If you want to be precise this draft may say minimum value of Min/Max
Unidirectional Link Delay (34) and be done.

That's all.

Cheers,
R.



On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg (ginsberg)  wrote:

> Tony –
>
>
>
> As an author of both RFC 8570 and I-D.ietf-isis-te-app, I am not sure why
> you are confused – nor why you got misdirected to code point 33.
>
>
>
> RFC 8570 (and its predecessor RFC 7810) define:
>
>
>
> 34   Min/Max Unidirectional Link Delay
>
>
>
> This sub-TLV contains two values:
>
>
>
> “Min Delay:  This 24-bit field carries the minimum measured link delay
>
>   value (in microseconds) over a configurable interval, encoded as
>
>   an integer value.
>
>
>
>Max Delay:  This 24-bit field carries the maximum measured link delay
>
>   value (in microseconds) over a configurable interval, encoded as
>
>   an integer value.”
>
>
>
> It seems clear to me that the flex-draft is referring to Min
> Unidirectional Link Delay in codepoint 34.
>
>
>
> I agree it is important to be unambiguous in specifications, but I think
> Peter has been very clear.
>
> Please explain how you managed to end up at code point 33??
>
>
>
>Les
>
>
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * tony...@tony.li
> *Sent:* Tuesday, August 18, 2020 7:44 AM
> *To:* Peter Psenak (ppsenak) 
> *Cc:* lsr@ietf.org; lsr-...@ietf.org; Christian Hopps ;
> Acee Lindem (acee) ; draft-ietf-lsr-flex-algo@ietf.org
> *Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
>
>
>
>
>
> Hi Peter,
>
>
>
>
>
> section 5.1 of the draft-ietf-lsr-flex-algo says:
>
>
> Min Unidirectional Link Delay as defined in [I-D.ietf-isis-te-app].
>
> We explicitly say "Min Unidirectional Link Delay", so this cannot be mixed
> with other delay values (max, average).
>
>
>
>
>
> The problem is that that does not exactly match “Unidirectional Link
> Delay” or “Min/Max Unidirectional Link Delay”, leading to the ambiguity.
> Without a clear match, you leave things open to people guessing. Now, it’s
> a metriic, so of course, you always want to take the min.  So type 33 seems
> like a better match.
>
>
>
>
>
> section 7.3. of ietf-isis-te-app says:
>
> Type   Description  Encoding
>Reference
> -
> 34  Min/Max Unidirectional Link DelayRFC8570
>
>
>
>
>
> And it also says:
>
>
>
> 33  Unidirectional Link DelayRFC8570 
> 
>
>
>
>
>
> This does not help.
>
>
>
>
>
> So, IMHO what we have now is correct and sufficient, but I have no issue
> adding the text you proposed below.
>
>
>
>
>
> What you have now is ambiguous. We have a responsibility, as writers of
> specifications, to be precise and clear.  We are not there yet.
>
>
>
>
>
> BTW, before I posted 09 version of flex-algo draft, I asked if you were
> fine with just referencing ietf-isis-te-app in 5.1. I thought you were, as
> you did not indicate otherwise.
>
>
>
>
>
> My bad, I should have pressed the issue.
>
>
>
>
>
> Anyway, I consider this as a pure editorial issue and hopefully not
> something that would cause you to object the WG LC of the flex-algo draft..
>
>
>
>
>
> I’m sorry, I think that this is trivially resolved, but important
> clarification.
>
>
>
> You also have an author’s email that is bouncing, so at least one more
> spin is required.
>
>
>
> Sorry,
>
> 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] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Robert Raszuk
Les,

>  You need to allow that not everything in the world is identified by an
IP/IPv6 address.

Thought we are talking about WAN networks here and not about the world :)

>  assign a common anycast address on all nodes.

First not all nodes need to participate here. At most ABRs.

Then if you already have a summary route from a given area - you do not
need to invent anything else - area summary routes are effectively area
prefixes. And in fact last time I checked routable too.

>  I can associate the SID with an identifier

Do you ping SID or IP address ?

Maybe time for examples.

What would be your MPLS area SID format ? How about SRv6 SID format for the
same ?

Bottom line I think we must not lock ourselves into single transport
technology - that's all I am after here.

Thx,
Robert.


On Mon, Aug 3, 2020 at 7:56 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> You need to allow that not everything in the world is identified by an
> IP/IPv6 address.
>
>
>
> If you want an IP address shared by all nodes in an area there is already
> a mean of doing that: assign a common anycast address on all nodes.
>
>
>
> The value add (if there is any) of an Area SID is that I don’t have to
> assign an anycast address to all nodes. I can associate the SID with an
> identifier that is already shared and known by all nodes in the area.
>
> If you don’t see that as worthwhile, fine, let’s abandon the Area SID idea.
>
>
>
>Les
>
>
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Monday, August 03, 2020 10:47 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; tony...@tony.li; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-ietf-lsr-isis-area-proxy-02.txt
>
>
>
> Hi Les,
>
>
>
> Well I am talking about IP routable identifier which I can place on the
> front of the packet and which can assure that the packet will arrive at
> given area.
>
>
>
> Then Area SID becomes analogy of Node SID :)
>
>
>
> Thx
>
>
>
> On Mon, Aug 3, 2020 at 7:40 PM Les Ginsberg (ginsberg) 
> wrote:
>
> Robert –
>
>
>
> Both OSPF and IS-IS have area identifiers which are advertised.
>
> Why would we need to invent another identifier for an area?
>
>
>
>Les
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Monday, August 03, 2020 10:31 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; tony...@tony.li; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-ietf-lsr-isis-area-proxy-02.txt
>
>
>
> *Les,*
>
>
>
> *> But currently the draft is defining a SID which is NOT associated with
> a prefix.*
>
> +
>
> > *But if the proposal is to use a SID associated with a prefix then I
> see no need to invent a new SID advertisement.*
>
>
>
> How about we first define an "Area Prefix" (IP address being a property of
> an area) then assign SID to it ?
>
>
>
> - - -
>
>
>
> How odd it may sound I would like to still be able to direct traffic (read
> ip tunnel) traffic to an area without any SID.
>
>
>
> Thx,
> R.
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Robert Raszuk
Hi Les,

Well I am talking about IP routable identifier which I can place on the
front of the packet and which can assure that the packet will arrive at
given area.

Then Area SID becomes analogy of Node SID :)

Thx

On Mon, Aug 3, 2020 at 7:40 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> Both OSPF and IS-IS have area identifiers which are advertised.
>
> Why would we need to invent another identifier for an area?
>
>
>
>    Les
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Monday, August 03, 2020 10:31 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; tony...@tony.li; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-ietf-lsr-isis-area-proxy-02.txt
>
>
>
> *Les,*
>
>
>
> *> But currently the draft is defining a SID which is NOT associated with
> a prefix.*
>
> +
>
> > *But if the proposal is to use a SID associated with a prefix then I
> see no need to invent a new SID advertisement.*
>
>
>
> How about we first define an "Area Prefix" (IP address being a property of
> an area) then assign SID to it ?
>
>
>
> - - -
>
>
>
> How odd it may sound I would like to still be able to direct traffic (read
> ip tunnel) traffic to an area without any SID.
>
>
>
> Thx,
> R.
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Robert Raszuk
Hi Tony,

If I am not mistaken that additional overhead would only need to happen on
participating in this game ABRs. If so I think this is worthwhile.

> Well, that becomes an anycast tunnel endpoint

Endpoint ? Not midpoint ? Or better sort of ski lift transit point with
embedded direction in the original dst ?

Thx
R.



On Mon, Aug 3, 2020 at 7:37 PM  wrote:

>
> Hi Robert,
>
> How about we first define an "Area Prefix" (IP address being a property of
> an area) then assign SID to it ?
>
>
>
> That’s effectively what Bruno is proposing.  It adds some additional
> configuration and management overhead.  Do you think it’s worthwhile?
>
>
>
> How odd it may sound I would like to still be able to direct traffic (read
> ip tunnel) traffic to an area without any SID.
>
>
>
>
> Well, that becomes an anycast tunnel endpoint, which is actually not one
> of the goals for Area Proxy.
>
> Tony
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Robert Raszuk
*Les,*

*> But currently the draft is defining a SID which is NOT associated with a
prefix.*
+
> *But if the proposal is to use a SID associated with a prefix then I see
no need to invent a new SID advertisement.*

How about we first define an "Area Prefix" (IP address being a property of
an area) then assign SID to it ?

- - -

How odd it may sound I would like to still be able to direct traffic (read
ip tunnel) traffic to an area without any SID.

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


Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-31 Thread Robert Raszuk
>
> [WAJ] Such information is for underlay link state and should be flooded
> via IGP? The ambiguity arises from IGP summary behavior and should be
> solved by itself?
>

Well if we look at this problem from a distance while on surface it seems
like an IGP issue (not to mention some which use BGP as IGP :) IMO it is
only hurting when you have some service overlay on top utilizing the IGP.

So typically today if I am running any service with BGP I do count on BGP
to remove routes which are no longer reachable. IGP just tells me how to
get to the next hop, which direction to go and not if the endpoint (service
CPE or PE connected to given CE) is up or down.

So today smart BGP implementations in good network design can use RD based
withdraws to very fast (milliseconds) remove the affected service routes.
When I said should we do it in BGP I meant to ask WG if this is good enough
to quickly remove service routes. If not maybe we should send such affected
next hop in BGP to even faster invalidate all routes with such next hop as
failing PE.

Bottom line if you think the problem is IGP then I think Acee's comments
apply.

Last - See today you are bringing the case to signal transition to DOWN ...
but for some people and applications it may be not enough. In fact UP/DOWN
they can get via BGP. But if you have two ABRs and one will due to topology
changes in its area suddenly will be forced to reach atomic destination
covered by summary over much higher metric path that for applications
running above may be much more severe case and not acceptable one too.

And BGP will not remove service routes nor modify best path in any way as
summary is masking the real metric to some next hops. So while in the
network you may have alternate better native transit paths with a lot of
free capacity if you only switch to a different bgp next hop (not talking
about any TE at all) you are stuck offering much worse service to your
customers.

Those cases are starting to be solved by performance routing both at the
service itself or at BGP nh levels. Should IGP assist here ... I am not
sure.

Many thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Robert Raszuk
Hi,

Imagine I have two ABRs connecting area 1 to area 0. One is signalling
transition to down for subset of summary and the other does not .. maybe it
is slow ... maybe it does not support this new feature.

So all routers in the area 0 are receiving a full summary from one ABR and
a summary with hole from the other one. Should that be logical AND or OR ?

Then on the other side there is area 2. Should the transition to down be
leaked ? If so in a nicely stable network we may see instead of few /20
summaries jump to 1M transitions to down yet summary continues - would that
not have a bit negative effect on the entire network ? Where would ABR
remove summary itself - when all atomic routes subsumed by the summary
transition to down ?

- - -

I am supportive of the idea to signal unreachable network elements. But I
am not sure if we should do it in IGP and BGP or only in BGP.

Thx,
R.


On Thu, Jul 30, 2020 at 6:08 PM Huzhibo  wrote:

> HI acee:
>
> PUA does not advertise reachable or unreachable details, it advertise
> events with prefix from up to down.
>
>
> thanks
>
> Zhibo
>
>
>
>
> --
> 胡志波 Hu Zhibo
> Mobile: +86-18618192287
> Email: huzh...@huawei.com
> *发件人:*Acee Lindem (acee) 
> *收件人:*Peter Psenak ;Robert Raszuk <
> rob...@raszuk.net>
> *抄 送:*Aijun Wang ;Xiaoyaqun 
> ;Huzhibo
> ;Aijun Wang ;lsr <
> lsr@ietf.org>
> *时 间:*2020-07-31 00:04:02
> *主 题:*Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
> So, how do we define a reachable route - is it any route subsumed by the
> summary LSA that we knew about in the past that becomes unreachable? When
> the PUA is withdrawn, how do we know whether it is because of expiration of
> the interval or the route becoming reachable again? This is a slippery
> slope.
> Thanks,
> Acee
>
> On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak" <
> lsr-boun...@ietf.org on behalf of ppsenak=40cisco@dmarc.ietf.org>
> wrote:
>
> On 30/07/2020 16:30, Robert Raszuk wrote:
> > Hey Peter,
> >
> > Not sure how smart you really want to be here but keep in mind that
> BGP
> > say option C may never hear about it all the way to the egress PE in
> > other domain or area ... It is almost always incongruent with IGP.
> >
> > So if the BGP path is installed it will indeed be at risk to resolve
> via
> > less specific when it is still active BGP path and you too quickly
> > remove info about unreachability.
>
> again, if you are smart you can use this info to your advantage, even
> without putting it in the forwarding and leaving the less specific
> stuff
> intact.
>
> Peter
>
>
> >
> > Thx
> > R.
> >
> > On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak  > <mailto:ppse...@cisco.com >> wrote:
> >
> > On 30/07/2020 16:14, Robert Raszuk wrote:
> >  >  > 2:For bgp example,when the pe node down,the bgp peer
> > must down
> >  > within
> >  >  > 30 mintus,It will not get it up via cancle advertise
> pua.
> >  >
> >  > for the above it is sufficient to advertise the
> > unreachability for few
> >  > seconds from each ABR independently. That would be a much
> > more solid
> >  > proposal.
> >  >
> >  >
> >  > Not sure about "few seconds" ... IBGP def hold time in number
> of
> >  > implementations is 180 sec :) .. but few minutes will work
> for sure.
> >
> > depends how you use it.
> >
> > If you can use the unreachable info in a smart way, it's
> sufficient if
> > it is present for a very short time interval.
> >
> > thanks,
> > Peter
> >
> >  >
> >  > Thx,
> >  > 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] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Robert Raszuk
Hey Peter,

Not sure how smart you really want to be here but keep in mind that BGP say
option C may never hear about it all the way to the egress PE in other
domain or area ... It is almost always incongruent with IGP.

So if the BGP path is installed it will indeed be at risk to resolve via
less specific when it is still active BGP path and you too quickly remove
info about unreachability.

Thx
R.

On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak  wrote:

> On 30/07/2020 16:14, Robert Raszuk wrote:
> >  > 2:For bgp example,when the pe node down,the bgp peer must down
> > within
> >  > 30 mintus,It will not get it up via cancle advertise pua..
> >
> > for the above it is sufficient to advertise the unreachability for
> few
> > seconds from each ABR independently. That would be a much more solid
> > proposal.
> >
> >
> > Not sure about "few seconds" ... IBGP def hold time in number of
> > implementations is 180 sec :) .. but few minutes will work for sure.
>
> depends how you use it.
>
> If you can use the unreachable info in a smart way, it's sufficient if
> it is present for a very short time interval.
>
> thanks,
> Peter
>
> >
> > Thx,
> > R.
> >
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Robert Raszuk
> > 2:For bgp example,when the pe node down,the bgp peer must down within
> > 30 mintus,It will not get it up via cancle advertise pua.
>
> for the above it is sufficient to advertise the unreachability for few
> seconds from each ABR independently. That would be a much more solid
> proposal.


Not sure about "few seconds" ... IBGP def hold time in number of
implementations is 180 sec :) .. but few minutes will work for sure.

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


Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-29 Thread Robert Raszuk
Not sure I follow your below comment or how it relates to my
deployment scenario ... I specifically said that 1.1.1.1/32 will be a
negative route (there is "-" minus there) advertised in BGP.

If you mean that reception of negative routes in the presence of summary
requires changes to RIB route tracking (or local RIB twist) it sure does.

Thx,
R.

On Wed, Jul 29, 2020 at 10:07 AM Huzhibo  wrote:

> Hi Robert:
>
>
>
> BGP next hop validation can solve some but not all problems. In your
> example, if PE1 has learned only 1.1.1.0/24 but not 1.1.1.1/32, BGP
> cannot detect the reachability of 1.1.1.1/32.
>
>
>
> Thanks
>
>
>
> Zhibo Hu
>
> *From:* Robert Raszuk [mailto:rob...@raszuk.net]
> *Sent:* Tuesday, July 28, 2020 5:18 PM
> *To:* Acee Lindem (acee) 
> *Cc:* Aijun Wang ; lsr@ietf.org; Huzhibo <
> huzh...@huawei.com>; Xiaoyaqun 
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> Hello Acee,
>
>
>
> I would like to question your assessment that signalling unreachable
> routes is unnecessary.
>
>
>
> Imagine hierarchical network with areas. Under no failures area 1
> advertises to area 0 summary LSA with 1.1.1.0/24. That block covers PE's
> loopbacks which within the area are /32s. Those loopbacks are also BGP next
> hops.
>
>
>
> Now imagine PE1 with 1.1.1.1/32 fails. Well till BGP reconverges all
> paths advertised by this PE with 1.1.1.1/32 are still valid as this next
> hop is still reachable entire network wide. That means that traffic is
> being sent to this failed PE1 for relatively long period of time.
>
>
>
> It seems natural that without breaking benefits of summarization across
> areas or domains in the above scenario we could continue to advertise
> 1.1.1.0/24 - 1.1.1.1/32. That is when I see most benefits of advertising
> unreachability aka negative routing.
>
>
>
> Of course said all of the above - if you search your employer's archives -
> you will see a proposal where the above mechanism can be done within BGP
> itself with no touch to the IGP - just using a bit of twisted next hop
> validation steps and BGP native recursion. I am not going to make any
> judgements here which method is better or easier - naturally I personally
> like BGP one more :).
>
>
>
> But I hope this is clear why at least discussion on the subject is
> important. It also illustrates why the below statement is not
> necessarily correct:
>
>
>
> "Note that the unreachability of a given summarized prefix is only
> relevant if it is reachable through another ABR. "
>
>
>
> Kind regards,
> Robert.
>
>
>
>
>
> On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
>
> Speaking as an LSR Working Group member:
>
> Asking the WG precisely how to advertise prefix unreachability is the
> wrong question - it is analogous to asking whether to use a car or truck to
> drive off the edge of a cliff. Rather than messing up OSPF and IS-IS with
> these complex and unnecessary mechanisms, it would be better to address the
> requirement in your network design. Note that the unreachability of a given
> summarized prefix is only relevant if it is reachable through another ABR..
> In this case, the network design should provide adequate intra-area
> redundancy to provide communications between the ABRs. If this cannot be
> accomplished, an intra-area adjacency should be established over a tunnel
> between the ABRs in the backbone. Contrary to section 6.1, Looping is
> normally not a problem as ABRs should add back hole routes for their
> advertised summaries.
>
> Acee
>
> On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang"  on behalf of wang...@chinatelecom.cn> wrote:
>
> Hi, LSR experts:
>
> We have uploaded the new version of this PUA(Prefix Unreachable
> Announcement) draft. The main updates are the followings:
> 1) Describes the solution that using tunnel to redirect traffic among
> ABRs, when all ABRs reaches the PUA limit.
> 2) Describe fast rerouting to avoid routing black hole.
> 3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS..
>
> There are also some arguments about the current solution for PUA, for
> example:
> 1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to
> indicate the prefix is unreachable?
> 2) if not, what's the consideration? What's the other convincible
> solution?
>
> Wish to hear comments and suggestions on the above issues. We will
> also have the presentation on the coming IETF LSR meeting.
>
> Best Regards
>
>  

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-28 Thread Robert Raszuk
Hello Acee,

I would like to question your assessment that signalling unreachable routes
is unnecessary.

Imagine hierarchical network with areas. Under no failures area 1
advertises to area 0 summary LSA with 1.1.1.0/24. That block covers PE's
loopbacks which within the area are /32s. Those loopbacks are also BGP next
hops.

Now imagine PE1 with 1.1.1.1/32 fails. Well till BGP reconverges all paths
advertised by this PE with 1.1.1.1/32 are still valid as this next hop is
still reachable entire network wide. That means that traffic is being sent
to this failed PE1 for relatively long period of time.

It seems natural that without breaking benefits of summarization across
areas or domains in the above scenario we could continue to advertise
1.1.1.0/24 - 1.1.1.1/32. That is when I see most benefits of advertising
unreachability aka negative routing.

Of course said all of the above - if you search your employer's archives -
you will see a proposal where the above mechanism can be done within BGP
itself with no touch to the IGP - just using a bit of twisted next hop
validation steps and BGP native recursion. I am not going to make any
judgements here which method is better or easier - naturally I personally
like BGP one more :).

But I hope this is clear why at least discussion on the subject is
important. It also illustrates why the below statement is not
necessarily correct:

"Note that the unreachability of a given summarized prefix is only relevant
if it is reachable through another ABR. "

Kind regards,
Robert.


On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee)  wrote:

> Speaking as an LSR Working Group member:
>
> Asking the WG precisely how to advertise prefix unreachability is the
> wrong question - it is analogous to asking whether to use a car or truck to
> drive off the edge of a cliff. Rather than messing up OSPF and IS-IS with
> these complex and unnecessary mechanisms, it would be better to address the
> requirement in your network design. Note that the unreachability of a given
> summarized prefix is only relevant if it is reachable through another ABR..
> In this case, the network design should provide adequate intra-area
> redundancy to provide communications between the ABRs. If this cannot be
> accomplished, an intra-area adjacency should be established over a tunnel
> between the ABRs in the backbone. Contrary to section 6.1, Looping is
> normally not a problem as ABRs should add back hole routes for their
> advertised summaries.
>
> Acee
>
> On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang"  on behalf of wang...@chinatelecom.cn> wrote:
>
> Hi, LSR experts:
>
> We have uploaded the new version of this PUA(Prefix Unreachable
> Announcement) draft. The main updates are the followings:
> 1) Describes the solution that using tunnel to redirect traffic among
> ABRs, when all ABRs reaches the PUA limit.
> 2) Describe fast rerouting to avoid routing black hole.
> 3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS..
>
> There are also some arguments about the current solution for PUA, for
> example:
> 1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to
> indicate the prefix is unreachable?
> 2) if not, what's the consideration? What's the other convincible
> solution?
>
> Wish to hear comments and suggestions on the above issues. We will
> also have the presentation on the coming IETF LSR meeting.
>
> Best Regards
>
> Aijun Wang
> China Telecom
>
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Monday, July 27, 2020 9:16 AM
> To: Zhibo Hu ; Aijun Wang ;
> Yaqun Xiao 
> Subject: New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
> A new version of I-D,
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
> has been successfully submitted by Aijun Wang and posted to the IETF
> repository.
>
> Name:   draft-wang-lsr-prefix-unreachable-annoucement
> Revision:   03
> Title:  Prefix Unreachable Announcement
> Document date:  2020-07-27
> Group:  Individual Submission
> Pages:  11
> URL:
> https://www.ietf.org/internet-drafts/draft-wang-lsr-prefix-unreachable-annoucement-03.txt
> Status:
> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
> Htmlized:
> https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-03
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-prefix-unreachable-annoucement-03
>
> Abstract:
>This document describes the mechanism that can be used to announce
>the unreachable prefixes for service fast convergence.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the 

[Lsr] Fwd: Devil's Advocate - Segment Routing, Why?

2020-06-18 Thread Robert Raszuk
Just FYI ...

An interesting discussion on nanog/cisco-nsp lists ... started innocent
with SRv6 bashing, now went into IGP - specifically ISIS territory  :)

-- Forwarded message -
From: Saku Ytti 
Date: Thu, Jun 18, 2020 at 12:43 PM
Subject: Re: Devil's Advocate - Segment Routing, Why?
To: Robert Raszuk 
Cc: Mark Tinka , na...@nanog.org ,
cisco-nsp NSP 


On Thu, 18 Jun 2020 at 13:28, Robert Raszuk  wrote:

> To your IGP point let me observe that OSPF runs over IP and ISIS does
not. That is first fundamental difference. There are customers using both
all over the world and therefore any suggestion to just use OSPFv3 is IMHO
quite unrealistic. Keep in mind that OSPF hierarchy is 2 (or 3 with super
area) while in IETF there is ongoing work to extend ISIS to 8 levels. There
is a lot of fundamental differences between those two (or three) IGPs and I
am sure many folks on the lists know them. Last there is a lot of
enterprise networks happily using IPv4 RFC1918 all over their global WAN
and DCs infrastructure and have no reason to deploy IPv6 there any time
soon.  If you are serious about converging to a single IGP I would rather
consider look towards OpenR type of IGP architecture with message bus
underneath.


On Thu, 18 Jun 2020 at 13:43, Saku Ytti  wrote:

I view the 802.3 and CLNS as liability, not an asset. People who
actually route CLNS are a dying breed,  think just DCN of a legacy
optical.

Many platforms have no facilities to protect ISIS, any connected
attacker can kill the box. Nokia handles generated packets
classification by assigning DSCP value to  application then DSCP to
forwarding-class, which precludes from configuring ISIS qos. Very few
people understand how ISIS works before ISIS PDU is handed to them,
world from 802.3 to that is largely huge pile of hacks, instead of
complete CLNS stack implementation. There is no standard way to send
large frames over 802.3, so there is non-standard way to encap ISIS
for those links. Also due to lack of LSP roll-over, ISIS is subject to
a horrible attack vector which is very difficult to troubleshoot and
solve.

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


Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-15 Thread Robert Raszuk
Tony P,

> or black-holing on aggregates since we cannot "back-off" generic LPM
packet forwarding when we
> realize we're @ a dead end due to aggregation.

I hope you are not stating that aggregation is a bad thing here and all we
should be distributing are host routes :)

But to your point - IGP is a servant to the application/service which is
BGP. So removal of BGP service routes in a topology independent fashion can
be really fast and take one or two hops. Assume we detect failure of a
remote node - I am not sure if BGP will withdraw service routes faster
across two RRs or IGP will remove next hop by flooding via area over N
nodes then crossing ABR or ASBR and flooding again over N nodes will be any
faster.

Last time I measured the speed of BGP transit of withdraw message via
control plane only RR with decent BGP implementation it was in ranges of
ms.

Thx,
R.

On Mon, Jun 15, 2020 at 7:57 PM Tony Przygienda  wrote:

>
>
> On Mon, Jun 15, 2020 at 10:37 AM  wrote:
>
>>
>> Hi Robert,
>>
>>
>> > > It’s very clear that this is inadequate.
>> >
>> > Doesn't this really depend how you architect multiple levels ? Sure you
>> have some physical topology - but it seems to me that the trick is in
>> properly laying out levels on top of them and between them.
>>
>>
>> The very pragmatic viewpoint is that network architects will construct
>> the physical topology that best suits their traffic pattern and that trying
>> to contort that physical topology into some kind of hierarchy will create
>> additional (and perhaps significant) cost.  People don’t want to do that.
>> They want scalable networks that match their physical topology.  For this
>> to work, our hierarchical abstractions need to be independent of the
>> topology and that forces us into having transit areas.
>>
>>
>>
> PNNI had transit areas in hierarchy working but the trick was connection
> setup cranck-back. Such a thing would work for RSVP or any of the stateful
> connection setups but alas, this is not fashionable right now.
> Unfortunately, generic hierarchy with reachability summarization ends up
> with very sub-optimal routing or black-holing on aggregates since we cannot
> "back-off" generic LPM packet forwarding when we realize we're @ a dead end
> due to aggregation. To prevent bi-furcation of topology or transit
> horizontals several solutions exist, one of which (configure hierarchy
> statically everywhere) the current draft has in now but alas, the topology
> is star of stars (you can actually see CLOS conceptually as something like
> this as well ;-)
>
> my meta 2c
>
> -- tony
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-15 Thread Robert Raszuk
Hi Tony,

> It’s very clear that this is inadequate.

Doesn't this really depend how you architect multiple levels ? Sure you
have some physical topology - but it seems to me that the trick is in
properly laying out levels on top of them and between them.

To my original question - how many levels can you run on the physical box ?
And can levels be locally and logically interconnected ?

Then of course if you have applications (MPLS exact FEC match or SR-MPLS
with SRLBs) which do not allow any aggregation you are pretty much stuck no
matter what :).

Rgs,
R.

On Mon, Jun 15, 2020 at 5:12 PM  wrote:

>
>
> On Jun 15, 2020, at 3:45 AM, Henk Smit  wrote:
>
> BTW, personally I think the proper solution to scale IS-IS to larger
> networks is 8 levels of hierarchy. Too bad that idea gets so little
> push from vendors and operators.
>
>
>
> Hi Henk,
>
> It’s very clear that this is inadequate.  The structure of legacy IS-IS
> areas effectively precludes a scalable network for using lower levels for
> transit. This constrains ISPs to ‘cauliflower’ topology where you have L1
> on the outside, L2 just inside of L1, L3 inside of L2, etc.
>
> We already see networks who are unwilling to use the two levels that we
> have today due to this constraint.
>
> Regards,
> Tony
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-11 Thread Robert Raszuk
Support.

Thx,
R.

On Wed, Jun 10, 2020 at 9:28 PM Christian Hopps  wrote:

> This begins a 2 week WG adoption call for the following draft:
>
>   https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/
>
> 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://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] Request for Working Group Adoption: Area Proxy

2020-06-04 Thread Robert Raszuk
Support.

Rgs,
R.

On Thu, Jun 4, 2020 at 6:42 PM  wrote:

>
> Dear Gentlebeings,
>
> I would like to formally request working group adoption of “Area Proxy for
> IS-IS” (https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03).
>
> The goal of this work is to improve scalability of IS-IS when transit L1
> areas are in use.  In legacy IS-IS, for the L1 area topology to be utilized
> by L2, part of the topology must be configured as both Level 1 and Level 2.
> In the case where the transit topology is most or all of the L1 area, this
> creates a scalability issue as the size of the L2 LSDB approaches that of
> the entire network.
>
> We propose to address this by injecting only a single LSP into Level 2. We
> call this the Proxy LSP and it contains all reachability information for
> the L1 area plus connectivity from the L1 area to L2 adjacencies. The
> result is that the L1 area is now opaque, reachable, and fully capable of
> providing L2 transit.
>
> Our use case is the deployment of Clos topologies (e.g., spine-leaf
> topologies) as transit nodes, allowing these topologies to replace
> individual routers. We also see applications of this approach to abstract
> entire data centers or POPs as single nodes within the L2 area.
>
> There are two other proposals of note before the working group.
>
> In Topology Transparent Zones (
> https://tools.ietf.org/html/draft-chen-isis-ttz-08), an area (or zone)
> may be represented by a single node or as a full mesh of tunnels between
> the edges of the zone. In addition, there is a mechanism to attempt to
> seamlessly enable and disable the effectiveness of the zone. Relative to
> our proposal and for our use cases, the full mesh of tunnels is not as
> effective at providing scalability. In the specific case of spine-leaf
> networks, the leaves are typically the majority of the nodes in the
> network. As they become the edges of the area, with the full mesh approach,
> the majority of the area is not abstracted out of the L2 LSDB. For our use
> case, we have concerns about enabling and disabling the abstraction
> mechanism. There is added complexity to support this mechanism. In networks
> at scale, disabling abstraction may cause scalability failures. Enabling
> abstraction may cause failures as LSPs age out at dissimlar times. We feel
> that establishing abstraction is fundamental to the architecture of the
> network and that changing it on the fly is a highly risky operation, best
> suited for maintenance windows. Accordingly, the additional complexity of
> the transition mechanism is not required.
>
> In IS-IS Flood Reflection (
> https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01),
> abstraction is achieved by mechanisms similar to ours, but transit service
> is achieved by tunneling transit traffic. That’s not necessary in our
> propsal.  In Flood Reduction, the also is coupled to the flooding
> reduction, whereas in our proposal, the two are independent, tho they do
> share the Area Leader mechanism.
>
> While both of these proposals are very worthy, we believe that our
> proposal has substantial merit. We ask that the WG adopt Area Proxy for
> further work.
>
> Regards,
> Tony & Sarah
> ___
> 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-07 Thread Robert Raszuk
Hey Jeff,

What if in your analysis A-D link metric is 1500 ? Still A will send to B !

See in all of this discussion from my pov it is not really about danger of
making LSDB inconsistent for much longer.

It is however about operator upgrading to new release a router, maybe even
reading release notes stating that flooding speed optimizations defined in
RFC ZZZ are implemented and final effect he sees are microloops lasting 10s
of seconds for his traffic.

Yes some vendors have good tools to protect from microloops, but those must
be enabled. Moreover those still require manual timer configuration how
long to keep loop free protection in place. And I am not aware any vendor
has a cli command showing how long it took in all routers in my area/level
to install in FIB result of various levels/cases of topology changes.

So I am not saying faster is not good. I am saying if you make car faster
do not forget to equip it with seat belts and make enough of warnings that
driver will actually fasten them.

Best,
R.

On Thu, May 7, 2020 at 6:41 AM Jeff Tantsura 
wrote:

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


Re: [Lsr] Flooding across a network

2020-05-06 Thread Robert Raszuk
Christian,

It is not about "hand-wringing and theorizing about being too-successful".

It is about impact to the overall network service when you make ISIS
convergence not consistent across nodes of the topology, I think our goal
is not to converge ISIS faster by improving flooding speed ... it is much
more about how to deliver user packets with minimal disruption upon
topology changes.

Best,
R.

On Wed, May 6, 2020 at 5:48 AM Christian Hopps  wrote:

> [as WG member]
>
> I think it would be more productive if we stay focused on trying to
> improve flooding speed/efficiency here. How about let's get some of the
> proposals being mulled over actually written, and provide some data, and
> leave all the hand-wringing and theorizing about being too-successful for
> after we've shown we could be? :)
>
> Thanks,
> Chris.
>
>
> > On May 5, 2020, at 8:03 PM, Robert Raszuk  wrote:
> >
> > 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.
> >
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] Flooding across a network

2020-05-05 Thread Robert Raszuk
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.
>
> >
>
> > - Let's call Dij the time needed to flood the LSP from node i to the
> adjacent
>
> > node j. Clearly Dij>0.
>
> > - Let's call k the node originating this LSP at t0=0s
>
> >
>
> > >From t0, the LSDB is inconsistent across the network as all nodes but k
> are
>
> > missing the LSP and hence only know about the 'old' topology.
>
> >
>
> > Let's call  SPT(k) the SPT rooted on k, using Dij as the metric between
>
> > adjacent nodes i and j. Let's call SP(k,i) the shortest path from k to
> i; and
>
> > D(k,i) the shortest distance between k and i..
>
> >
>
> > It seems that the time needed:
>
> > - for node j to learn about the LSP, and get in sync with k, is D(k,j)
>
> > - for all 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread Robert Raszuk
>
> > Perhaps such flag to "slow down guys" could be send by receiver
> uniformly to all peers when under LSP flooding congestion ?
>
> That’s effectively what we’re proposing, tho it need not be a binary
> flag.  It allows us to do simpler things saying “we’re running out of
> buffer space, please slow down a bit”. Again the goal is to find the
> optimal goodput.  Granularity in the feedback will be helpful.
>

Apologies if I missed it but so far I understood that the new signalling
from the receiver could be different per each LSP sender (per each Hello).

Above I am suggesting that such signalling to be "global" per receiver
(ie.sent identical to all LSP senders) under moments of stress/congestion.

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


Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread Robert Raszuk
Ahh ok.

I was under the assumption that flooding reduction is something we will
have sooner then LSP flow control. But maybe this was too optimistic.

- - -

For per peer flow control I do not get how receiver's ISIS process is to
come up with per peer timer if it may never see under congestion given
peer's LSPs (being dropped on the single RE cp queue or at the interface).

Perhaps such flag to "slow down guys" could be send by receiver uniformly
to all peers when under LSP flooding congestion ? And instead of
specifying an absolute number just mean: slow N times (ex: slow 2 times or
slow 4 times). Such timer could be either temporary with fixed duration or
in effect until relaxed explicitly.

LSP senders would still require to handle it on a per peer basis but as
indicated this is not an issue.

Thx.
R.

On Mon, Apr 27, 2020 at 8:57 PM  wrote:

>
> If we have 1000 of interfaces and all peers *all in the same time* will
> send us an LSP of max size of 1492 octets that our control plane buffer RAM
> size required to store them would be as huge as 1.5 MB. And that assumes we
> did not process any from arrival of the first to the arrival of the last
> one.
>
>
>
> And that’s only one LSP.  If they don’t stop there and each sends 1000
> LSPs, then you can have 10^6 incoming packets, requiring 1.6GB.
>
> Further, since the bottleneck is likely the queue of packet on the
> forwarding chip(s) to the CPU, this 1.6GB needs to exist on the forwarding
> silicon.  Needless to say, it doesn’t.
>
> Yes, the CPU can probably keep up with one of the peers. This implies that
> the forwarding plane queue grows at the rate that 999 peers are sending at.
> Thus, congestion.
>
> Tony
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread Robert Raszuk
> Meanwhile, buffering is finite and control planes really can’t keep up.
> Forwarding is a parallel activity. The control plane is not.  This presents
> us with a situation where congestion is pretty much inevitable. We need to
> deal with it.


At least we are lucky that ISIS LSPs are produced by some other control
plane not by a silicon chip :)

If we have 1000 of interfaces and all peers *all in the same time* will
send us an LSP of max size of 1492 octets that our control plane buffer RAM
size required to store them would be as huge as 1.5 MB. And that assumes we
did not process any from arrival of the first to the arrival of the last
one.

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


Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread Robert Raszuk
Hi Tony,


> You already have a per-interface flooding ‘queue' through the
> implementation of the SRM bit in the LSDB, which must be managed on a
> per-interface basis.
>

Today from what I see operators (if they even change the default) normally
apply same timer value on all interfaces. If the timer is static what would
be the incentive for any implementation not to group interfaces with
identical transmit delay ?

- - -

While this thread is very interesting I must observe that from my
experience the issue is usually on the receiver. If LSR would publish a one
page draft/rfc mandating that links state packets MUST or SHOULD be
recognized and separated from any other control plane traffic at the
ingress interface level (on their way to local RE/RP) we likely wouldn't be
having such debate.

Slowing senders just due to bad implementation of the receiving router is
IMHO a little suboptimal (not to say wrong) thing to do.

Kind regards,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread Robert Raszuk
> In both cases, this call, IMO a signaling capability from the receiver to
the sender.

So essentially you are asking for per peer flooding queue.

Now this get's a little bit of tricky (especially if you are dealing
with relatively small timers) if one peer sends you 1 ms, second 50 ms and
10th  250 ms.

Imagine that the LSP to be flooded to the 10th peer is already overwritten
due to new LSP but still sitting in the out queue ... do you drain that
queue and start over with new LSP or you in place replace the old one
keeping the running timer ?

I am just curious what will happen under the hood :)

Cheers,
R.




On Mon, Apr 27, 2020 at 3:02 PM  wrote:

> Hi Acee,
>
>
>
> Please see inline [Bruno2]
>
>
>
> *From:* Acee Lindem (acee) [mailto:a...@cisco.com]
> *Sent:* Monday, April 27, 2020 2:39 PM
> *To:* DECRAENE Bruno TGI/OLN; Robert Raszuk
> *Cc:* Les Ginsberg (ginsberg); lsr@ietf.org; Tony Przygienda
> *Subject:* Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
>
>
> Hi Bruno,
>
>
>
> *From: *Lsr  on behalf of Bruno Decraene <
> bruno.decra...@orange.com>
> *Date: *Monday, April 27, 2020 at 8:15 AM
> *To: *Robert Raszuk 
> *Cc: *"Les Ginsberg (ginsberg)" , "
> lsr@ietf.org" , Tony Przygienda 
> *Subject: *Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
>
>
> Robert,
>
>
>
> *From:* Robert Raszuk [mailto:rob...@raszuk.net]
> *Sent:* Monday, April 27, 2020 12:09 PM
> *To:* DECRAENE Bruno TGI/OLN
> *Cc:* Tony Przygienda; Les Ginsberg (ginsberg); lsr@ietf.org
> *Subject:* Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
>
>
>
>
> > Slow flooding increase the likelihood of multiple IGP SPF computations
>
>
>
> True.
>
>
>
> But if you keep your IGP nicely organized in area and levels, get rid of
> flooding anything incl. /32s domain wide to address bugs in MPLS
> architecture then your flooding radius is usually very small.
>
> [Bruno] First of all, the use of areas/levels brings tradeoffs. Then,
> after their initial design, networks grow and change.
>
>
>
> Coming back to flooding, if you have a core router with 50 IGP neighbors,
> the failure of this neighbor requires flooding 50 LSPs. At 33ms pacing
> between LSPs that’s a 1.6s delay/tax, before any computation & FIB update.
> As you see, it’s not related to the number of /32 nor the network diameter.
>
> Some may be fine with this additional 1.6s. Some may not.
>
>
>
> I’m not nearly as familiar with IS-IS deployments as OSPF. Are there any
> implementations that don’t offer configuration to override the 33ms
> inter-LSP interval?
>
> [Bruno2] AFAIK, all implementations allow the configuration of the
> inter-LSP interval.
>
> The question is which value do you set while not risking to overload your
> IS-IS neighbor. Which brings two issues:
>
> -  This depends on the receiver. E.g. High end router vs low end;
> PE with only 2 high adjacencies vs P with 50 adjacencies, router
> generation… While this is currently configured on the sender on a per
> receiver basis
>
> -  Even though the vendor know the design and how it is
> implemented, some vendors may not commit on scaling values supported by a
> given receiver.
>
>
>
> So there are two options:
>
> -  Have the receiver advertise static values (default but
> according to its platform capability=
>
> -  Use dynamic values. Flow control is likely to also require
> some signaling from the receiver to the sender.
>
>
>
> In both cases, this call, IMO a signaling capability from the receiver to
> the sender. The same signaling may then be used to advertise either
> static/default or dynamic values, depending on what the receiver prefer
> (some tend to prefer static values, some tend to prefer dynamic values)
>
>
>
> Thanks,
>
> BR
>
> --Bruno
>
> At Redback (circa 2000), our OSPF implementation defaulted to fast
> flooding and for the MinLSInterval and MinLSArrival OSPF values, you had to
> explicitly remove the fast flooding default if  you wanted to follow RFC
> 2328. Thanks,
> Acee
>
>
>
> Best
>
> --Bruno
>
>
>
>
>
> That in turn allows for both fast flooding and fast topology computation
> while only dealing with few external summaries. I am yet to see a
> practical case where a well designed network with today's ISIS requires
> flooding speedup.
>
>
>
> Best,
>
> R.
>
>
>
>
>
>
>
>
>
> On Mon, Apr 27, 2020 at 10:34 AM  wrote:
>
> Ø  ISIS flooding churn (and room for optimization) becomes a problem when
> node boots up (IMHO this is not a pro

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread Robert Raszuk
> Slow flooding increase the likelihood of multiple IGP SPF computations

True.

But if you keep your IGP nicely organized in area and levels, get rid of
flooding anything incl. /32s domain wide to address bugs in MPLS
architecture then your flooding radius is usually very small.

That in turn allows for both fast flooding and fast topology computation
while only dealing with few external summaries. I am yet to see a
practical case where a well designed network with today's ISIS requires
flooding speedup.

Best,
R.




On Mon, Apr 27, 2020 at 10:34 AM  wrote:

> Ø  ISIS flooding churn (and room for optimization) becomes a problem when
> node boots up (IMHO this is not a problem) and when node fails while having
> many neighbors attached. Yes maybe second case could be improved but well
> designed and operated network should have pre-programmed bypass paths
> against such cases so IMO stressing IGP to "converge" faster while great in
> principle may not be really needed in practice.
>
>
>
> I don’t think that FRR is a replacement for “fast” (I’d rather say
> adequate) IGP convergence & flooding.
>
> For multiple reasons such as:
>
> -  Multiple ‘things’ depends on the IGP, such as BGP best path
> selection, CSPF/TE/PCE computations, FRR computations
>
> -  Slow flooding increase the likelihood of multiple IGP SPF
> computations which is harmful for other computations which are typically
> heavier and manifolds (cf above)
>
> -  Multiple IGP SPF computations also create multiple transient
> forwarding loops. There are some techniques to remove forwarding loops but
> this is still an advanced topic and some implementations do not handle
> consecutives IGP SPF (with ‘overlapping’ convergences and combined
> distributed forwarding loops)
>
> -  For FRR, you mostly need to pre-decide/configure whether you
> want to protect link or node failures. Tradeoff are involved and given
> probability of events, link protection is usually enabled (hence not node
> protection)
>
> -  …
>
>
>
> Also, given the current “state of the art”, there is no stressing
> involved. Really. Using TCP, my 200€ mobile running on battery and over
> wifi+ADSL+Internet can achieve better communication throughput than a
> n*100k€ high end IS-IS router.
>
> I think many persons agree that IS-IS could do better in term of flooding..
> (possibly not as good as a brand new approach, but incremental improvement
> also have some benefits). Eventually, we don’t need everyone to agree on
> this.
>
>
>
> Ø  PS. Does anyone have a pointer to any real data showing that
> performance of real life WAN ISIS deployments is bad ?
>
>
>
> In some of our ASes, we do monitor IS-IS by listening to and recording
> flooded LSPs. I can’t share any data.
>
> Next question could be what is “good enough”. I guess this may depend on
> the size of your network, its topology, and your requirements.
>
>
>
> We also ran tests in labs. I may share some results during my
> presentation. (no names, possibly no KPI, but some high level outcomes).
>
>
>
> Regards,
>
> Bruno
>
>
>
>
>
> *From**:* Robert Raszuk [mailto:rob...@raszuk.net]
> *Sent:* Friday, April 24, 2020 12:42 PM
> *To:* DECRAENE Bruno TGI/OLN
> *Cc:* Tony Przygienda; Les Ginsberg (ginsberg); lsr@ietf.org
> *Subject:* Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
>
>
> Hi Bruno  & all,
>
>
>
> [Bruno] On my side, I’ll try once and I think the LSR WG should also try
> to improve IS-IS performance. May be if we want to move, we should first
> release the brakes.
>
>
>
> Well from my observations releasing the breaks means increasing the risks..
>
>
>
> Take BGP - breaks are off and see what happens :)
>
>
>
> My personal observation is that ISIS implementations across vendors are
> just fine for vast majority of deployments today. That actually also
> includes vast majority of compute clusters as they consists of max 10s of
> racks.
>
>
>
> Of course there are larger clusters with 1000+ or 10K and above network
> elements itself and x 20 L3 computes, but is there really a need to stretch
> protocol to accommodate those ? Those usually run BGP anyway. And also
> there is DV+LS hybrid too now.
>
>
>
> ISIS flooding churn (and room for optimization) becomes a problem when
> node boots up (IMHO this is not a problem) and when node fails while having
> many neighbors attached. Yes maybe second case could be improved but well
> designed and operated network should have pre-programmed bypass paths
> against such cases so IMO stressing IGP to "converge" faster while great in
> p

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-24 Thread Robert Raszuk
Hi Bruno  & all,

[Bruno] On my side, I’ll try once and I think the LSR WG should also try to
improve IS-IS performance. May be if we want to move, we should first
release the brakes.

Well from my observations releasing the breaks means increasing the risks.

Take BGP - breaks are off and see what happens :)

My personal observation is that ISIS implementations across vendors are
just fine for vast majority of deployments today. That actually also
includes vast majority of compute clusters as they consists of max 10s of
racks.

Of course there are larger clusters with 1000+ or 10K and above network
elements itself and x 20 L3 computes, but is there really a need to stretch
protocol to accommodate those ? Those usually run BGP anyway. And also
there is DV+LS hybrid too now.

ISIS flooding churn (and room for optimization) becomes a problem when node
boots up (IMHO this is not a problem) and when node fails while having many
neighbors attached. Yes maybe second case could be improved but well
designed and operated network should have pre-programmed bypass paths
against such cases so IMO stressing IGP to "converge" faster while great in
principle may not be really needed in practice.

Last I am worried that when IETF defines changes to core protocol behaviour
the quality of the implementations of those changes may really differ
across vendors overall resulting in much worse performance and stability as
compared to where we are today.

I am just not sure if possible gains for few deployments are greater
then risk for 1000s of today's deployments. Maybe one size does not fit all
and for massive scale ISIS we should define a notion of "ISIS-DC-PLUGIN"
which can be optionally in run time added when/if needed. If that requires
protocol changes to accommodate such dynamic plugins - that work should
take place.

Many thx,
R.

PS. Does anyone have a pointer to any real data showing that performance of
real life WAN ISIS deployments is bad ?


On Fri, Apr 24, 2020 at 11:26 AM  wrote:

> Tony
>
>
>
> *From:* Tony Przygienda [mailto:tonysi...@gmail.com]
> *Sent:* Thursday, April 23, 2020 7:29 PM
> *To:* DECRAENE Bruno TGI/OLN
> *Cc:* lsr@ietf.org; Les Ginsberg (ginsberg)
> *Subject:* Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
>
>
> I was refering to RFC4960. Bruno, for all practical purposes I think that
> seems to go down the path of trying to reinvent RFC4960 (or ultimately use
> it).
>
> [Bruno] I don’t think that SCTP (RC4960) is a better fit than TCP.. Many
> more features and options than TCP, way more than needed given existing
> IS-IS flooding mechanism. Much less implementations experience and
> improvement than TCP.
>
> Or, changing the packet formats heavily to incorporate all the control
> loop data you need to the point you have a different control channel along
> those lines since you'll find most of the problems RFC4960 is describing
> (minus stuff like multiple paths).
>
> [Bruno] Really, adding one sub-TLV in IS-IS is not “changing the packet
> formats heavily”.
>
> Nothing wrong with that but it's ambitious on a 30 years old anitque
> artefact we're nursing forward here ;-)
>
> [Bruno] I’m perfectly fine with revolution approaches. I think that we can
> also provide incremental improvement to IS-IS.
>
> As entertaining footnote, I saw in last 20 years at least 3 attempts to
> allow multiple TCP sessions in BGP between peers to speed/prioritize things
> up. All failed, after the first one I helped to push I smarted up ;-)
>
>  [Bruno] On my side, I’ll try once and I think the LSR WG should also try
> to improve IS-IS performance. May be if we want to move, we should first
> release the brakes. I’m seen some progress, e.g., from “there is no need to
> improve flooding” to “we all agree to improve flooding”, or from “Network
> operator just need to configure existing CLI” to “We agree that we need
> something more automated/dynamic”. But this has been very slow progress
> over a year.
>
>
>
> --Bruno
>
>
>
> As another footnote: I looked @ all the stuff in RIFT (tcp, quic, 4960,
> more ephemeral stuff). I ended up adding to rift bunch very rudimentary
> things and do roughly what Les/Peter/Acee started to write (modulo algorith
> I contributed and bunch things that would be helpful but we can't fit into
> existing packet format). This was as much decision as to "what's available
> & well debugged" as well as "does it meet requirements" as "how complex is
> that vs. rtx in flooding architecture  we have today + some feedback". Not
> on powerpoint, in real production code ;-) rift draft shows you the outcome
> of that as IMO best trade-off to achieve high flooding speeds ;-)
>
>
>
> my 2c
>
>
>
> -- tony
>
>
>
> On Thu, Apr 23, 2020 at 10:15 AM  wrote:
>
> Tony,
>
> Thanks for engaging.
>
> Please inline [Bruno2]
>
>
>
>
>
>
>
> *From:* Tony Przygienda [mailto:tonysi...@gmail.com]
> *Sent:* Wednesday, April 22, 2020 9:25 PM
> *To:* DECRAENE Bruno TGI/OLN
> *Cc:* lsr@ietf.org; Les 

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

2020-04-03 Thread Robert Raszuk
Ahh for the record I used that URL yesterday:

An email from the IESG secretary was sent on 2020-03-19, saying
"Information about remote participation: https://ietf.webex.com/meet/lsr "

On Fri, Apr 3, 2020 at 12:14 PM  wrote:

> Chris,
>
> Please see inline.
>
>
> > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> > Sent: Friday, April 3, 2020 12:00 AM
> > To: Robert Raszuk
> >
> >
> >
> > > 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.
> >
>
> So may be my experience may help for next time(s). See below.
>
> An email from the IESG secretary was sent on 2020-03-19, saying
> "Information about remote participation: https://ietf.webex.com/meet/lsr "
> Hence I used that URL.
> On this webex, the meeting did not start on time so I've waited for some
> time. Then 10-15 minutes past the start, I decided to 'notify the host',
> but never got accepted on the webex.
> At that point I assumed a technical issue with webex and monitored the
> mailing list, but no one was complaining, which is not inline with typical
> IETF reaction ;-) .
> So I assumed the error was only on my side and I searched for more emails
> and found one from Chris (2020-03-31) saying that the URL was
> https://ietf.webex.com/ietf/j.php?MTID=mbef20efa9e66c7e97f9d6b18ea84eca8
> And this one worked fine.
> My guess is that the 'interim' webex did not use the 'lsr' webex. Also the
> 'official' notification from the IESG secretary with the incorrect webex
> URL did not helped.
>
> --Bruno
>
> > 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
>
>
> _
>
> 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] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

2020-04-03 Thread Robert Raszuk
Hi Tony,

I think there is still some disconnect - so in an attempt to at least make
sure that we have difference of opinions let me try to restate what I was
suggesting.

IGP would only carry indication if tail can do inband telemetry or not - it
would *not* carry any telemetry data. IGP would not be running telemetry -
it will be just consumer of other subsystem product.
https://tools.ietf.org/html/draft-wang-lsr-ifit-node-capability-advertisement-00
just signals capability. It does not even have a trunk for any type of dump
:)

Global optimization makes a lot of sense for traffic spread across given
network - 100%. But it is not the best place to only select if one path is
eligible and the other is not in given topology. That decision should
happen on the headends and should be as much distributed as possible. And
the data here as input to the decision is only valid on specific headend
probes depart from. Besides it has usually a very short life.

Even if we move cspf to historic just very recently flexible algorithm was
proposed and I think is progressing fine. So my examples of use cases to
choose paths with min drops or bound jitter are real.

Hi Jeff,

If I look at one of the in situ data plane proposals it does send the
results to the sender/originator vs some
collector. draft-lapukhov-dataplane-probe-01 This is besides the point of
this discussion as we are not asking for IGP to carry the results. Hint:
Each headend can be a collector or nothing breaks in the design if headend
get's this data out of band from central collector.

Thx,
R.


On Fri, Apr 3, 2020 at 1:43 AM  wrote:

>
> Sure it is possible to discover if my tailends are capable of handling in
> band telemetry by off line means. But what I am struggling to see why we
> allowed so much TE stuff into IGPs and we do not want to make it easier for
> headends to operate without PCE at all for the purpose of delivering
> such type of services.
>
>
>
> AFAICT, we put a lot of effort into making headend path computation useful
> and, for the most part, it was and is not necessary.
>
> Even with legacy mechanisms, people decided that they need global
> optimization and that head-end path computation was Not That Interesting.
>
> It’s now 20 years later, the network is even more dynamic, the
> expectations about response time are that much higher, and concerns about
> link state database stability and scalability have increased.  Modern
> telemetry is definitely not suitable to be passed in the IGP anymore.
>
> Thus, it seems like the IGP can provide base topology information and
> traffic engineering constructs should leverage that and provide an
> independent telemetry collection plane. Within that plane, telemetry
> capabilities can and should be confined to the telemetry plane.
>
> As we’ve said many times before: BGP is not a dump truck. Analogously, the
> IGP isn’t even an SUV.
>
> ;-)
>
> Regards,
> Tony
>
>
___
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 Robert Raszuk
> "collected only on active paths" is not something I propose but is the
property of on-path
> telemetry collection method.

That is all fine. The point is that the notion of active paths in the
network may represent those in default topology over any path. That can be
computed by PCE.

So default topology may have N active paths while
application specific topologies M where M is a subset of N meeting required
end to end constraints.

Sure it is possible to discover if my tailends are capable of handling in
band telemetry by off line means. But what I am struggling to see why we
allowed so much TE stuff into IGPs and we do not want to make it easier for
headends to operate without PCE at all for the purpose of delivering
such type of services.

Kind regards,
R.

On Fri, Apr 3, 2020 at 1:22 AM Greg Mirsky  wrote:

> Hi Robert,
> "collected only on active paths" is not something I propose but is the
> property of on-path telemetry collection method.
>
> Regards,
> Greg
>
> On Thu, Apr 2, 2020 at 4:16 PM Robert Raszuk  wrote:
>
>> > collected only on active paths
>>
>> Here we clearly diverge :)
>>
>> The notion of default active paths in my view represents many more
>> alternative paths constructed based on the default topology while cspf or
>> flex algo products may consist only of subset of those per applied
>> constraints.
>>
>> Thx,
>> Robert
>>
>>
>> On Fri, Apr 3, 2020 at 1:13 AM Greg Mirsky  wrote:
>>
>>> And another note regarding the use of on-path collected telemetry
>>> information. I'd point that that information is collected only on active
>>> paths. Thus it characterizes the conditions experienced by already existing
>>> flows. Hence it might not be related to a path that the system intends to
>>> instantiate. One needs active OAM to collect such information.
>>>
>>> Regards,
>>> Greg
>>>
>>> On Thu, Apr 2, 2020 at 4:08 PM Greg Mirsky 
>>> wrote:
>>>
>>>> Hi Robert,
>>>> I think that there's no apparent requirement to collect performance
>>>> information form each node in the network in order to select a path with
>>>> bounded delay and packet loss. Would you agree?
>>>>
>>>> Regards,
>>>> Greg
>>>>
>>>> On Thu, Apr 2, 2020 at 4:03 PM 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

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

2020-04-02 Thread Robert Raszuk
> collected only on active paths

Here we clearly diverge :)

The notion of default active paths in my view represents many more
alternative paths constructed based on the default topology while cspf or
flex algo products may consist only of subset of those per applied
constraints.

Thx,
Robert


On Fri, Apr 3, 2020 at 1:13 AM Greg Mirsky  wrote:

> And another note regarding the use of on-path collected telemetry
> information. I'd point that that information is collected only on active
> paths. Thus it characterizes the conditions experienced by already existing
> flows. Hence it might not be related to a path that the system intends to
> instantiate. One needs active OAM to collect such information.
>
> Regards,
> Greg
>
> On Thu, Apr 2, 2020 at 4:08 PM Greg Mirsky  wrote:
>
>> Hi Robert,
>> I think that there's no apparent requirement to collect performance
>> information form each node in the network in order to select a path with
>> bounded delay and packet loss. Would you agree?
>>
>> Regards,
>> Greg
>>
>> On Thu, Apr 2, 2020 at 4:03 PM 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 Robert Raszuk
Hi Greg,

That is 100% correct. That in fact goes well against the main principle of
end to end path based measurements in the data plane.

Collecting information by all nodes would inherently not include their own
forwarding characteristics so in my books is of very marginal use.

Thx,
R.


On Fri, Apr 3, 2020 at 1:08 AM Greg Mirsky  wrote:

> Hi Robert,
> I think that there's no apparent requirement to collect performance
> information form each node in the network in order to select a path with
> bounded delay and packet loss. Would you agree?
>
> Regards,
> Greg
>
> On Thu, Apr 2, 2020 at 4:03 PM 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 Robert Raszuk
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


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

2020-04-02 Thread Robert Raszuk
Well I did not knock (notify the host and politely ask to join) as I
assumed IETF WG meeting doors should be open. I figured maybe host just
does not like me to join the party :-)

I think my mistake was that I did not expect password to be needed. Learned
something new then !

Cheers,
R.

On Fri, Apr 3, 2020 at 12:22 AM Acee Lindem (acee)  wrote:

> As host of the meeting, I didn’t see any indication that you were waiting
> in the lobby.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Robert Raszuk 
> *Date: *Thursday, April 2, 2020 at 6:10 PM
> *To: *Christian Hopps 
> *Cc: *"Les Ginsberg (ginsberg)" , "lsr@ietf.org" <
> lsr@ietf.org>, Jeff Tantsura , Tianran Zhou <
> zhoutian...@huawei.com>, Acee Lindem , wangyali <
> wangyal...@huawei.com>
> *Subject: *Re: [Lsr] problem joining interim [Re: A new version of I-D,
> draft-liu-lsr-isis-ifit-node-capability-02]
>
>
>
> 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


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

2020-04-02 Thread Robert Raszuk
Well Jeff if you would completely remove CSPF and Flex Algo from IGPs I am
fully with you.

But till we still have them running in the routers I am of the opinion that
we need both ... bigger and slower PCE based path computation and
sufficient information (not only static data) for routers itself to be able
to adjust forwarding state based on the live path constraints.

I realize I am thinking outside of the box here but hopefully one day this
will become a norm rather then abstraction :)

Best,
R.,

On Fri, Apr 3, 2020 at 12:24 AM Jeff Tantsura 
wrote:

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

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

2020-04-02 Thread Robert Raszuk
> > 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


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

2020-04-02 Thread Robert Raszuk
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


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

2020-04-02 Thread Robert Raszuk
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 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
>>

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

2020-04-02 Thread Robert Raszuk
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) ; lsr@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 mentioned
> > tools.
> > >
> > > Kind regards,
> > > R.
> > >
> > > On Thu, Apr 2, 2020 at 8:32 AM Les Ginsberg (ginsberg)
> >  wrote:
> > > Yali -
> > >
> > > There is a very significant difference between having IGPs advertise an
> > identifier for a service that they use as clients (BFD) and having IGPs
> > advertise a set of capabilities/options for a telemetry application
> which has
> > no direct bearing on the function of the routing protocol.
> > >
> > > You are not the first to find using IGPs to flood application
> information very
> > convenient.  But this is not the appropriate role for the IGPs and over
> the
> > years we have consistently resisted attempts to do so.
> > >
> > > Everything advertised in Router Capabilities today has some close
> > relationship with the operation of the protocol. Do some of the existing
> > advertisements "bend the rules" a bit more than I would prefer? Yes - but
> > there has always been at least a close relationship to routing protocol
> > function.
> > > Here there is none.
> > >
> > > If you feel compelled to use IGPs to advertise application
> information, you
>

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

2020-04-02 Thread Robert Raszuk
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 mentioned tools.

Kind regards,
R.

On Thu, Apr 2, 2020 at 8:32 AM Les Ginsberg (ginsberg)  wrote:

> Yali -
>
> There is a very significant difference between having IGPs advertise an
> identifier for a service that they use as clients (BFD) and having IGPs
> advertise a set of capabilities/options for a telemetry application which
> has no direct bearing on the function of the routing protocol.
>
> You are not the first to find using IGPs to flood application information
> very convenient.  But this is not the appropriate role for the IGPs and
> over the years we have consistently resisted attempts to do so.
>
> Everything advertised in Router Capabilities today has some close
> relationship with the operation of the protocol. Do some of the existing
> advertisements "bend the rules" a bit more than I would prefer? Yes - but
> there has always been at least a close relationship to routing protocol
> function.
> Here there is none.
>
> If you feel compelled to use IGPs to advertise application information,
> you have RF6823 available (at least for IS-IS). But it is a "high bar"
> since it requires you also to use a separate IS-IS instance dedicated to
> advertising the application information (see RFC8202).
> I think Chris Hopps's suggestion to use Netconf/YANG to configure/retrieve
> what you need is most likely more attractive - but I will leave that for
> you to decide.
>
> Using IGP Router Capabilities here is wrong in my view.
>
>Les
>
>
> > -Original Message-
> > From: wangyali 
> > Sent: Wednesday, April 01, 2020 8:12 PM
> > To: Acee Lindem (acee) ; Les Ginsberg (ginsberg)
> > ; Christian Hopps 
> > Cc: lsr@ietf.org; Tianran Zhou 
> > Subject: 答复: [Lsr] A new version of I-D,
> draft-liu-lsr-isis-ifit-node-capability-
> > 02
> >
> > Hi Acee, Chris and Les,
> >
> > This is Yali. Many thanks for your kind comments and suggestion.
> >
> > Besides of signaling MSD by IGP node CAPABILITY TLV, we learned that
> > there's another RFC7883 that advertising S-BFD discriminators in IS-IS.
> In my
> > understand, BFD is a protocol to detect faults in the bidirectional path
> > between two forwarding engines, including interface, data links, etc.
> >
> > Similarly, IFIT provides a complete framework of a family of on-path
> > telemetry techniques, which are used to monitoring performance metrics of
> > service flows, e.g. packet loss, delay. So we consider there's a same
> > methodology with S-BFD that advertising IFIT node capabilities.
> >
> > Please let us know your comments and opinion. Thanks.
> >
> > Best regards,
> > Yali
> >
> > -邮件原件-
> > 发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
> > 发送时间: 2020年4月1日 20:29
> > 收件人: Tianran Zhou ; Les Ginsberg (ginsberg)
> > ; Christian Hopps 
> > 抄送: lsr@ietf.org; wangyali 
> > 主题: Re: [Lsr] A new version of I-D,
> draft-liu-lsr-isis-ifit-node-capability-02
> >
> > Speak as WG Member...
> >
> > On 4/1/20, 8:08 AM, "Acee Lindem (acee)"  wrote:
> >
> > There is also a difference between some of the existing applications
> > advertised in IGP capabilities. For example, MSD is used with the routing
> > information to construct SR paths. The information for all these OAM
> > mechanisms doesn't share this affinity. Also, it seems like a slippery
> slope in
> > what is needed for each of the mechanism.
> > Thanks,
> > Acee
> >
> > On 4/1/20, 4:01 AM, "Lsr on behalf of Tianran Zhou" <
> lsr-boun...@ietf.org
> > on behalf of zhoutian...@huawei.com> wrote:
> >
> > Hi Les,
> >
> > Thanks very much for your suggestion. I have a quick look at
> rfc6823.
> > Sounds like a good idea. I will think about it.
> >
> > Cheers,
> > Tianran
> >
> > -Original Message-
> > From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> > Sent: Wednesday, April 1, 

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network

2020-03-30 Thread Robert Raszuk
Hi,

Out of pure curiosity here - how are you going to stop any other traffic
(SR or non SR) to take as much as it likes of any link being part of the
default topology ?

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


Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-02-19 Thread Robert Raszuk
Hi Les,

Yes this "small delay" of ACK aggregation is something which I am a bit
worried here from SNPs sender side.

Now as indeed draft mentioned prioritizing SNPs on reception let me
indicate that some platforms I have not so long ago dealt with do not even
prioritize any IGP packet over other packets at neither ingress LC nor
queue to RE/RP. If that channel takes 100s of ms within the box I am
afraid all bets for flooding improvement are off.

Thx
R,.


On Wed, Feb 19, 2020 at 6:48 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> Thanx for your input.
>
>
>
> Note that one of the suggestions in
> https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/
>  is to prioritize the reception of SNPs over LSPs so that we are less
> likely to drop ACKs.
>
> It is not clear to me why you think SNP generation would be an issue.
>
> Once a received LSP is processed one of the outputs is to set a per
> interface flag indicating that an ACK (PSNP) needs to be sent (SSN flag).
> Implementations usually implement some small delay so that multiple ACKs
> can be sent in a single PSNP – but I do not see why this should be viewed
> as a bottleneck.
>
>
>
> If your concern is that we need to emphasize the importance of sending
> timely ACKs, I think we could look at text that makes that point.
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * Robert Raszuk
> *Sent:* Wednesday, February 19, 2020 1:07 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
>
>
> Hi Les & all,
>
>
>
> Watching this discussion I would like to state that IMO going with
> transmitter based rate limiting (I would not call it flow control) is much
> easier option to deploy and operate. It also has no dependency across other
> side of p2p adj which is a very important factor. The only issue here is if
> generation of [P|C]SNPs is fast enough.
>
>
>
> Receiver based flow control is simple in flow theory however I have a
> feeling that if we are to go that path we would be much better to actually
> run ISIS flooding over DC-TCP and avoid reinventing the wheel.
>
>
>
> Thx,
>
> Robert.
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2020-01-10 Thread Robert Raszuk
Hi Tony,

I agree with you that essentially this is a link property (hence my earlier
hint towards 5029) so it makes it at least two of us recommending direction
towards 5029 now ;)

While we are at this perhaps it would be also useful to be able to
differentiate reachability on stub links vs virtual local interfaces. Today
in some implementations they are advertised after marking them as passive
int.

Thx
R.


On Fri, Jan 10, 2020, 08:26  wrote:

>
> Hi Aijun,
>
>
> For the link attributes that defined in RFC5029, as that stated in
> https://tools.ietf.org/html/rfc5029#section-2, this sub-TLV is included
> in the TLV 22(Extended IS Reachability).
> As I read the IANA code point
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223
> , it notes this sub-TLV can be included in all of these TLVs
> (22,23,25,141,222,223).
>
> But, when the interface is configured as passive/stub, it seems that the
> above TLVs will not be advertised, because there is no IS neighbor on this
> passive link.
>
>
>
> Fair point. Given that there is an IP address and prefix on that link, it
> would be very reasonable to advertise the Extended IP Reachability TLV
> (135). We would then need to make the link attributes sub-TLV applicable to
> this TLV (and it’s MT brother).
>
>
> TLV 141 “Inter-AS reachability information” seems be one appropriate TLV
> to include this sub-TLV, but it requires the IS-IS TE deployment, and is
> not suitable for describing the passive/stub link on edge router.
>
> In summary, it seems put this attribute into the “Prefix Attribute Flags”
> sub-TLV which can be included in TLV 135,235,236 and 237 (Extended IP
> reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs) is
> more applicable?
>
>
>
> It would seem to me that what you’re describing is an attribute of a link,
> not of a prefix, thus I would favor it remaining a link attribute.
>
> But that’s just me.  :-)
>
> Tony
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2020-01-07 Thread Robert Raszuk
Hi Aijun,

Right .. I took your email as an attempt/request to actually advertise
passive links in the first place.

May we know what difference does it make to you if reachable prefix is part
of an active vs passive interface from IGP point of view ?

Thx,
R.


On Tue, Jan 7, 2020 at 2:08 AM Aijun Wang  wrote:

> Hi, Robert:
>
>
>
> Thanks for your information.
>
> TLV-22 is used to describe the IS neighbor and the link between them. As
> for the passive interfaces, there may be no neighbor.
>
> It seems the sub-TLV within this TLV is not the appropriate place to put
> this information?
>
>
>
> P.S. I changed the thread to reflect the conversion topic.
>
>
>
> Best Regards.
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *发件人:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *代表 *Robert
> Raszuk
> *发送时间:* 2020年1月6日 18:58
> *收件人:* Aijun Wang
> *抄送:* Les Ginsberg (ginsberg); lsr@ietf.org
> *主题:* Re: [Lsr] 答复: Is it necessary to expand the IS-IS level to 8?
>
>
>
> Aijun,
>
>
>
> We just want to distinguish the passive interfaces from other normal
> interfaces within ISIS domain.  It seems that the “Attribute Flags” that
> described in https://tools.ietf.org/html/rfc7794#section-2.1 is the most
> appropriate place to extend to carry such information.
>
>
>
> Really ?
>
>
>
> IMO much better place is to define new sub-TLV of TLV-22 and mark it there
> as passive link.
>
>
>
> Ref: https://tools..ietf.org/html/rfc5029
> <https://tools.ietf.org/html/rfc5029>
>
>
>
> Now more interesting perhaps is to find out how ISIS is supposed to react
> to such information. Or is the intention to carry it just as an opaque info
> say for show commands use only ?
>
>
>
> Thx,
> R.
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] 答复: Is it necessary to expand the IS-IS level to 8?

2020-01-06 Thread Robert Raszuk
Aijun,


> We just want to distinguish the passive interfaces from other normal
> interfaces within ISIS domain.  It seems that the “Attribute Flags” that
> described in https://tools.ietf.org/html/rfc7794#section-2.1 is the most
> appropriate place to extend to carry such information.
>

Really ?

IMO much better place is to define new sub-TLV of TLV-22 and mark it there
as passive link.

Ref: https://tools.ietf.org/html/rfc5029

Now more interesting perhaps is to find out how ISIS is supposed to react
to such information. Or is the intention to carry it just as an opaque info
say for show commands use only ?

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


Re: [Lsr] [spring] IETF 106 - SPRING agenda

2019-11-07 Thread Robert Raszuk
*>   Once advertised in the network using a suitable link state protocol
>   (such as OSPF, ISIS or BGP-LS),*


Whow ... never imagined that BGP-LS would be called one day a "link
state protocol" and an equal sign would be made to OSPF and ISIS.


Best,
Robert.


PS. As to the proposal in draft itself it is clearly possible - but
then troubleshooting and operating such mixed network would be a
simple nightmare.



On Thu, Nov 7, 2019 at 3:25 AM Tarek Saad  wrote:

> Hi SPRING WG and Chairs,
>
>
>
> We would like to request a presentation time slot for
>
> - I-D: https://tools.ietf.org/html/draft-saad-sr-fa-link-00
>
> - Speaker: Tarek Saad
>
> - Desired time: 10 minutes
>
>
>
> Regards,
>
> Tarek
>
___
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-19 Thread Robert Raszuk
Hi Huaimo,

Ad 1 - Let me observe that constructing hierarchy is not always driven by
number of nodes in a given level can safely support. One could indeed build
a global flat link state network in single level/area if only looking at
number of nodes. But in number of cases benefits from hierarchy could be
seen in reduced flooding radius and enforced summarization. Hint:  me why
my routers in Sydney have to be aware about link flap in POP in Toronto ?

Ad 6 - Interesting .. I asked the same question to authors offline :)

Thx,
R.




On Mon, Aug 19, 2019 at 4:27 PM Huaimo Chen 
wrote:

> Support and have the following comments:
>
>
>
>1. It seems not necessary to have 8 levels of hierarchies. 3 or at
>most 4 levels of hierarchies should be enough. IS-IS with 3 levels of
>hierarchies may support a network with 1k*1k*1k nodes, which is about 10^9
>= 1 billion nodes. IS-IS with 4 levels of hierarchies may support a network
>with 1k*1k*1k*1k nodes, which is about 10^12 = 1 trillion nodes.
>2. For PDU type, section 2.2 of the draft proposes to use 8 bits (all
>three reserved bits plus the 5 bits for the existing PDU type). It seems
>better to use 6 bits (one reserved bit plus the 5 bits for the existing PDU
>type). Adding one reserved bit into the PDU Type allows people to define 32
>new PDU types, which is enough for the new PDU types needed for new
>hierarchies.
>3. Section 3 “Additional PDUs” of the draft, defines 6 new PDU Types
>for ’Level n LAN IS to IS hello PDU’ (Ln-LAN-HELLO-PDU), where n is 3, 4,
>5, 6, 7, and 8. In addition, the following new PDU Types should be defined
>(considering at most 4 levels of hierarchies):
>   1. 2 new PDU Types for ‘’Level n LSP”, where n is 3, and 4
>   2. 2 new PDU Types for ‘’Level n CSNP”, where n is 3, and 4
>   3. 2 new PDU Types for ‘’Level n PSNP”, where n is 3, and 4
>4. On a broadcast interface, Level 1 LSPs are multicast through MAC
>0x0180.c200.0014 (which is called AllL1ISs), and Level 2 LSPs are multicast
>through MAC 0x0180.c200.0015 (which is called AllL2ISs). It seems that
>Level n LSPs should be multicast through AllLnISs, where n is 3, and 4
>(considering at most 4 levels of hierarchies), thus
>   1. 2 new MAC should be assigned to AllLnISs, where n is 3, and 4.
>5. The existing DIS for a broadcast interface periodically multicast
>through AllL1ISs and AllL2ISs a Complete SNP (CSNP). It seems that the DIS
>should be extended to periodically multicast a CSNP through AllLnISs, where
>n is 1, 2, 3, and 4 (considering at most 4 levels of hierarchies).
>6. When there may be 3 or more levels of hierarchies, is it allowed to
>have 3 or more levels (consecutive) configured on an interface? It seems
>that there is no description about this in the draft.
>
>
>
> Best Regards,
>
> Huaimo
>
>
>
> *From:* Lsr  *On Behalf Of *Acee Lindem (acee)
> *Sent:* Monday, August 12, 2019 10:33 AM
> *To:* lsr@ietf.org
> *Subject:* [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS"
> - draft-li-lsr-isis-hierarchical-isis-01
>
>
>
> This begins a two week LSR Working Group Adoption Poll for the
> "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01. The poll
> will end at 12:00 AM UTC on August 27th, 2019. 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] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

2019-08-16 Thread Robert Raszuk
Hey Les,

Of course the objective of the draft is clear and I do not think anyone is
questioning that. There was however topic of data and control plane
congruence requirement and I think we all agreed by now that this is rather
required in link state protocol as it is defined today.

As to the overall direction which I think initial Aijun's mail brought up
was if hierarchy is actually best answer to scale a protocol.

Divide and conquer is great strategy, but as such it could be realized with
flat levels interconnected by ISIS LSP reflectors as pure control plane
scaling solution (still reusing most of today's machinery - leaking,
summarization etc ...) Some form of DIS analogy except here to interconnect
many flat levels.

So I think the overall point to the WG is if building additional data and
control plane levels is the most optimal solution to scale link state
protocols up. Sure it can be done and it will be one more optional tool in
the toolbox, but is this the right/best tool for the job ?

Thx,
R.


On Fri, Aug 16, 2019 at 8:08 PM Les Ginsberg (ginsberg) 
wrote:

> To expand on this a bit, the point of the draft extensions is to add
> additional levels of hierarchy and use existing mechanisms (leaking,
> summarization) to have traffic flow up/down the hierarchy.
>
> The intent is NOT to bypass the hierarchy.
>
>
>
> People can use multiple instances and redistribution to do whatever they
> may wish. In that context two instances of IS-IS are no different then one
> instance of two different protocols.
>
> But this is decidedly NOT the intent of the draft.
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * tony...@tony.li
> *Sent:* Friday, August 16, 2019 11:01 AM
> *To:* Tony Li 
> *Cc:* lsr@ietf.org; Aijun Wang ; Robert Raszuk
> 
> *Subject:* Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical
> IS-IS" - draft-li-lsr-isis-hierarchical-isis-01
>
>
>
>
>
> Hi Aijun,
>
>
>
> Les kindly points out that what I’ve suggested here is completely
> non-standard and requires multiple IS-IS instances.
>
>
>
> Tony
>
>
>
>
>
>
>
> On Aug 16, 2019, at 9:03 AM, tony...@tony.li wrote:
>
>
>
> Hi Aijun,
>
>
>
> If, as you stated,  we connect R1 and R7 via one link(although we will not
> do so, if we design the network hierarchically), how you flood the link
> information hierarchically but let the traffic between the two connected L1
> area bypass the L2 area?
>
>
>
>
>
> The link between R1 and R7 needs to belong to either the top area or the
> bottom area.  R1 or R7 needs to participate in two areas and leak routes
> between the two areas.
>
>
>
> Tony
>
>
>
>
>
___
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-15 Thread Robert Raszuk
Hi Tony,

> The hierarchical arrangement of the control plane does NOT imply that the
data plane is necessarily hierarchical.

Since Aijun posted his question I was trying to think of such model, but
failed.

While it is easy to envision this with DV protocols say BGP - do you have
any pointer to a link state protocol architecture where data plane is non
hierarchical (links do not belong to upper levels) while control plane used
traverses multiple levels ?

Thx,
R.

On Thu, Aug 15, 2019 at 4:40 PM  wrote:

>
> Hi Aijun,
>
> 1. The size of network is increasing, but it is becoming more flat. Is it
> the right direction to make the network more hierarchical?
>
>
>
> Well, given that we’re talking a link state protocol running SPF over a
> database in O(n log n) time, it’s pretty clear that we don’t want to scale
> the size of an area indefinitely. While modern processors are amazing
> (especially to those of us that started off with KHz 8080’s), it’s pretty
> clear that Moore’s law is over and that we cannot expect infinite compute
> power anytime in the future.  The alternative is to partition the network
> in some way.  Once partitioned, hierarchical arrangement seems like a
> natural fit. It’s been said that the only real tool that we have over scale
> is hierarchy.  Divide and conquer.
>
>
> 2. More hierarchical network means the traffic will also be traversed in
> hierarchical way, is it more efficient?
>
>
>
> The hierarchical arrangement of the control plane does NOT imply that the
> data plane is necessarily hierarchical.
>
>
> 3. Is there any other methods to scale out the IS-IS deployment?
>
>
>
> If you’ve been following along, Dynamic Flooding (
> https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-03) allows us
> to address the limitations that we have with flooding, allowing us to scale
> the size of an area. However, it does not address the O(n log n) cost of
> SPF that will still ultimately bound the growth of areas and in turn
> necessitate more hierarchy.
>
> 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 Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

2019-08-13 Thread Robert Raszuk
> lsr-isis-extended-hierarchy

 Sounds great !
___
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 Robert Raszuk
> What would you suggest?

How about:  draft-ietf-lsr-n-level-isis-00 ?

r.


On Tue, Aug 13, 2019 at 4:42 PM  wrote:

>
> Robert,
>
> Thank you for your support.  What would you suggest?
>
> Tony
>
>
> On Aug 13, 2019, at 6:40 AM, Robert Raszuk  wrote:
>
> Support.
>
> However assuming the draft will reach rough consensus of support I do
> recommend to change the title during the conversion to WG document. ISIS is
> already hierarchical today as even the abstract of the draft clearly says.
>
> Thx,
> R.
>
>
___
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 Robert Raszuk
Support.

However assuming the draft will reach rough consensus of support I do
recommend to change the title during the conversion to WG document. ISIS is
already hierarchical today as even the abstract of the draft clearly says.

Thx,
R.

On Mon, Aug 12, 2019 at 11:57 PM Acee Lindem (acee)  wrote:

> This begins a two week LSR Working Group Adoption Poll for the
> "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01. The poll
> will end at 12:00 AM UTC on August 27th, 2019. 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] Dynamic flow control for flooding

2019-07-24 Thread Robert Raszuk
*[Les:] At the cost of convergence. Not a good tradeoff.*

Hi Les - why at the cost of convergence ? No one as I see it is proposing
the same rate to every peer. Quite contrary -- per peer rate of flooding.
So if you keep flooding high speed on fast links the convergence will not
be any slower with flow control.

Thx,
R.

On Wed, Jul 24, 2019 at 8:28 PM Les Ginsberg (ginsberg) 
wrote:

> Tony –
>
>
>
> Inline.
>
>
>
> *From:* Tony Li  *On Behalf Of *tony...@tony.li
> *Sent:* Tuesday, July 23, 2019 10:39 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] Dynamic flow control for flooding
>
>
>
>
>
>
>
> Les,
>
>
>
> I also think we all agree on the goal - which is to flood significantly
> faster than many implementations do today to handle deployments like the
> case you mention below.
>
>
>
>
>
> I agree with that, but you haven’t responded to the goal that I proposed:
> keep the receiver processing PDUs.
>
>
>
> *[Les:] My goals are:*
>
>
>
> *Optimize convergence.*
>
> *Minimize complexity.*
>
>
>
> *Optimizing the throughput through a slow receiver is pretty low on my
> list because the ROI is low.*
>
>
>
> Beyond this point, I have a different perspective.
>
>
>
> As network-wide convergence depends upon fast propagation of LSP changes –
> which in turn requires consistent flooding rates on all interfaces enabled
> for flooding – a properly provisioned network MUST be able to sustain a
> consistent flooding rate or the operation of the network will suffer. We
> therefore need to view flow control issues as indicative of a problem.
>
>
>
> It is a mistake to equate LSP flooding with a set of independent P2P
> “connections” – each of which can operate at a rate independent of the
> other.
>
>
>
> If we can agree on this, then I believe we will have placed the flow
> control problem in its proper perspective – in which case it will become
> easier to agree on the best way to implement flow control.
>
>
>
>
>
> I agree that we want network wide convergence.  However, I disagree that
> the right thing to do is to uniformly flood at the same rate on all
> interfaces.
>
>
>
> First, the rate that you select might be too fast for one neighbor and not
> for the others.  Real flow control would help address this.
>
>
>
> *[Les:] At the cost of convergence. Not a good tradeoff.*
>
> *I am arguing that we do want to flood at the same rate on all interfaces
> used for flooding. When we cannot, flow control does not help with
> convergence. It may decrease some wasted bandwidth – but as we all agree
> that bandwidth isn’t a significant limitation this isn’t a great concern.*
>
>
>
> *The same reasons that drive us to use same SPF delay and LSP Generation
> timers on all routers also apply to flooding rate.*
>
>
>
> Second, all flooding paths are not created equal.  You do not know, a
> priori, how to flood to get uniform network wide propagation.  The variance
> in CPU loading alone is going to cause different routers to flood at
> different rates, and so it may actaully be optimal to flood quickly down
> one path, knowing that the data will reach the other end of the network and
> flood back before the slow CPU can absorb and flood.
>
>
>
> *[Les:] I do not see how flow control improves things.*
>
> *If you have alternate flooding paths around the slow link(s) this argues
> more that you should not have the slow link in the flooding topology in the
> first place. But this heads off topic – I think we agree that dynamic
> flooding is a separate discussion which we don’t want to bring into this
> thread.*
>
>
>
> Dropping down to the least common denominator CPU speed in the entire
> network is going to be undoable without an oracle, and absurdly slow even
> with that.
>
>
>
> *[Les:] Never advocated that – please do not put those words in my mouth.*
>
>
>
> *   Les*
>
>
>
>
>
> 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] Dynamic flow control for flooding

2019-07-24 Thread Robert Raszuk
Hi,

Yes indeed while I was reading your richly connected node restart problem
use of overload-bit should be explored, proposed, implemented.

For the partition problem I have two general comments:

a) If network partitions is likely to happen more often in the case of
dynamic flooding perhaps as already said before we should increase the max
number of occurrences given LSP is to arrive at flooding optimized node.
Two may not be enough.

b)  If protocol extensions will help to mitigate effects of network
partition via much faster repair some folks may treat network partitions as
normal operational model and instead of re-architecting the network to make
sure network partition events are as rear as possible.

Thx,
R.

On Wed, Jul 24, 2019 at 4:12 PM Henk Smit  wrote:

>
> Hello Robert,
>
> Tony brought up the example of a partioned network.
> But there are more examples.
>
> E.g. in a network there is a router with a 1000 neighbors.
> (When discussing distributed vs centralized flooding-topology
>   reduction algorithms, I've been told these network designs exist).
> When such a router reboots/crashes/comes back up, all 1000 neighbors
> will create a new version of their own LSP. This causes a 1000 different
> LSPs to be flooded through the network at the same time. Impacting every
> router in the network.
>
> The case I was thinking of myself, was when a router in a large network
> boots. When it brings up a number of adjacencies, each neighbor will
> try to synchronize its LSPDB with the newly booted router. As the newly
> booted router will send emtpy CSNPs to each of its neighbors, each
> neighbor will start sending the full LSPDB. If such a network has 10k
> LSPs, and such a router has 100 neighbors, that router will receive 100
> * 10k
> is 1 million LSPs. Having a faster and more efficient flooding
> transport,
> with flow-control, will make a reboot in such a topology less painful.
>
> (In that last case, creative use of the overload-bit could prevent
> black-holing
> or microloops while ISIS synchronizes its LSPDB after a reboot. Just
> like we
> used the overload-bit to solve the problem of slow convergence of BGP
> after
> a reboot, 22 years ago. I have no idea if there are any implementations
> that
> use the overload-bit to alleviate slow convergence of IS-IS after a
> reboot).
>
> henk.
>
>
> Robert Raszuk schreef op 2019-07-24 15:33:
> > Hey Henk & all,
> >
> > If acks for 1000 LSPs take 16 PSNPs (max 66 per PSNP) or even as long
> > as Tony mentioned the full flooding as Tony said may take 33 sec - is
> > this really a problem ?
> >
> > Remember we are not talking about protocol convergence after link flap
> > or node going down. We are talking about serious network partitioning
> > which itself may have lasted for minutes, hours or days. While just
> > considering absolute numbers yelds desire to go faster and faster, if
> > we put things in the overall perspective is there really a problem to
> > be solved in the first place ?
> >
> > Would there still be a problem if LSR WG recommends faster acking
> > maybe not for each LSP but for say 20 or 30 max ?
> >
> > Thx,
> > 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] Dynamic flow control for flooding

2019-07-24 Thread Robert Raszuk
Hey Henk & all,

If acks for 1000 LSPs take 16 PSNPs (max 66 per PSNP) or even as long as
Tony mentioned the full flooding as Tony said may take 33 sec - is this
really a problem ?

Remember we are not talking about protocol convergence after link flap or
node going down. We are talking about serious network partitioning which
itself may have lasted for minutes, hours or days. While just considering
absolute numbers yelds desire to go faster and faster, if we put things in
the overall perspective is there really a problem to be solved in the first
place ?

Would there still be a problem if LSR WG recommends faster acking maybe not
for each LSP but for say 20 or 30 max ?

Thx,
R.








On Wed, Jul 24, 2019 at 3:18 PM Henk Smit  wrote:

>
> Hello Les,
>
> Les Ginsberg (ginsberg) wrote on 2019-07-24 07:17:
>
> > If you accept that, then it makes sense to look for the simplest way
> > to do flow control and that is decidedly not from the RX side. (I
> > expect Tony Li to disagree with that  – but I have already
> > outlined why it is more complex to do it from the Rx side.)
>
> In your talk on Monday you called the idea in
> draft-decraene-lsr-isis-flooding-speed-01 "receiver driven flow
> control".
> You don't like that. You want "transmit based flow control".
> You argued that you can do "transmit based flow control" on the sender
> only.
> Therefor your algorithm is merely a "local trick".
> And "local tricks" don't need RFCs. I agree with that.
> But I don't agree that your algorithm is just a "local trick".
>
>
> In your algorithm, a "sender" sends a number of LSPs to a receiver.
> Without waiting for acks (PNSPs). Like in any sliding window protocol.
> The sending router keeps an eye on the number of unacked LSPs.
> And it determines how fast it can send more LSPs based on the current
> number of unacked LSPs. Every time the sender receives a PSNP, it
> knows the receiver got a number of LSPs, so it can increase its
> send-window again, and then send more LSPs.
> Correct ?
>
> I agree that the core idea of this algorithm makes sense.
> After all, it looks a lot like TCP.
> I believe the authors of draft-decraene-lsr-isis-flooding-speed were
> planning something like that for the next version of their draft.
>
>
> However, I do not agree with the name "tx driven flow control".
> I also do not agree that this algorithm is "a local trick".
> Therefor I also do not think this algorithm doesn't need to be
> documented (in an RFC).
>
> In your "tx based flow control", the sender (tx) sends LSPs at a rate
> that is derived from the rate at which it receives PSNPs. Therefor
> it is the sender of the PSNPs that sets the speed of transmission !
> So it is still the receiver (of LSPs) that controls the flow control.
> The name "tx based flow control" is a little misleading, imho.
>
>
> It is important to realize that the success of your algorithm actually
> depends on the behaviour of the receiver. How does it send PSNPs ?
> Does it send one PSNP per received LSP ? Or does it pack multiple acks
> in one PSNP ? Does it send a PSNP immediatly, or does it wait a short
> time ? Does it try to fill a PSNP to the max (putting ~90 acks in one
> PSNP) ? Does the receiver does something in between ? I don't think
> the behaviour is specified exactly anywhere.
>
> I know about an IS-IS implementation from the nineties. When a router
> would receive an LSP, it would a) set the SSN bit (for that
> LSP/interface),
> and b) start the psnp-timer for that interface (if not already running).
> The psnp-timer would expire 2 seconds later. The router would then walk
> the LSPDB, find all LSPs with the SSN-bit set for that interface. And
> then build a PSNP with acks for all those LSPs. The result would be
> that: a) the first PSNP would be send 2 seconds (+/- jitter) after
> receiving the first LSP, and b) the PSNP would include ~66 acks. (As
> a router receiving at full speed would have received 66 LSPs in 2
> seconds).
>
> For your "tx based flow control" algorithm to work properly, this has
> to change. The receiving router must send PSNPs more quickly and more
> aggressively. The result would be that there will be less acks in each
> PSNP. And thus more PSNPs will be sent.
>
> This makes us realize: in the current situation, if a router receives
> a 1000 LSPs, and sends those LSPs to 64 neighbors, it would receive:
> - the 1000 LSPs from an upstream neighbor, plus
> - 1000/66 = 16 PSNPs from each downstream neighbor = 64 * 16 = 1024
> PSNPs.
> This makes a total of ~2000K PDUs received.
>
> If routers would send one PSNP per LSP (to have faster flow control),
> then the router in this example would receive:
> - the 1000 LSPs from an upstream neighbor, plus
> - 1000 PSNPs from each downstream neighbor * 16 = 1600 PSNPs.
> This makes a total of ~17000 PDUs received.
>
> The total number of PDUs received on this router would go from 2K PDUs
> to 17K PDUs.
>
> Remember that the problem we're trying to solve here is to make sure
> 

Re: [Lsr] Dynamic flow control for flooding

2019-07-24 Thread Robert Raszuk
Hi Tony,

> I am assuming that there is no link layer flow control.  I can’t recall
> working on a system that supports X.25 since about 1995, so I don’t think
> that’s a common use case today.
>

I was more thinking along the lines of leveraging IEEE 802.3x or 802.1Qbb
standard not necessarily suggest fancy X.25 or Frame Relay :)

 Henk proposed that we simply pick up TCP for this, but my concern with
> that is really about introducing a whole new dependency to the protocol.
> That’s a lot to chew.  Do we really need it all? I hope not.  Thus, Bruno’s
> original suggestion sparked my interest in doing something dynamic and
> simple.
>

The second part of the question was really about at what layer it makes
most sense to provide this control loop.

Options seems to be:

* Invent new or use existing link layer flow control (IEEE)
* Reuse existing transport layer (TCP)
* App layer (QUIC or QUIC like)

I guess it would be useful to up front list on what type of media this must
be supported as it may change the game drastically:

* directly connected fiber p2p
* p2mp (via switch)
* p2p over encapsulation
etc...

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


Re: [Lsr] Dynamic flow control for flooding

2019-07-23 Thread Robert Raszuk
Hi Tony,

Are you working on the assumption that there is no data link layer flow
control already which could signal the OS congestion on the receiving end ?

Are we also working on the assumptions that when ISIS PDUs are send in DCs
(unknown today case when out of the sudden 1000s of LSPs may need to get
flooded) use of some L4 fancy flow control is an overkill and we must
invent new essentially L2 flow control to cover this case to address
partition repair ?

Thx,
R.

On Tue, Jul 23, 2019 at 3:34 PM Tony Li  wrote:

>
> Hi all,
>
> I’d like to continue the discussion that we left off with last night.
>
> The use case that I posited was a situation where we had 1000 LSPs to
> flood. This is an interesting case that can happen if there was a large
> network that partitioned and has now healed.  All LSPs from the other side
> of the partition are going to need to be updated.
>
> Let’s further suppose that the LSPs have an average size of 1KB.  Thus,
> the entire transfer is around 1MB.
>
> Suppose that we’re doing this on a 400Gb/s link. If we were to transmit
> the whole batch of LSPs at once, it takes a whopping 20us.  Not
> milliseconds, microseconds.  2x10^-5s.  Clearly, we are not going to be
> rate limited by bandwidth.
>
> Note that 20us is an unreasonable lower bound: we cannot reasonably expect
> a node to absorb 1k PDUs back to back without loss today, in addition to
> all of it’s other responsibilities.
>
> At the opposite end of the spectrum, suppose we transmit one PDU every
> 33ms.  That’s then going to take us 33 seconds to complete. Unreasonably
> slow.
>
> How can we then maximize our goodput?  We know that the receiver has a set
> of buffers and a processing rate that it can support. The processing rate
> will vary, depending on other loads.
>
> What we would like the transmitter to do is to transmit enough to create a
> small processing queue on the receiver and then transmit at the receiver’s
> processing rate.
>
> Can we agree on this goal?
>
> 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-isis-srv6-extensions-00

2019-05-31 Thread Robert Raszuk
Hi Paul,

It has been pointed out about month ago :)

Ref:
https://mailarchive.ietf.org/arch/msg/lsr/hbmJqgpnfjcsxiD40AGaTMA2tic

Best,
R.


On Fri, May 31, 2019 at 11:41 PM Paul Mattes  wrote:

> I think there is a small issue with
> draft-ietf-lsr-isis-srvr-extensions-00. The title is:
>
>
>
> IS-IS Extensions to Support Routing over IPv6 Dataplane
>
>
>
> I suspect that IS-IS works just fine for routing IPv6. The title should
> probably be:
>
>
>
> IS-IS Extensions to Support Segment Routing over IPv6 Dataplane
>
>
>
>*pdm*
>
>
> ___
> 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] 答复: 答复: Option B from "Migration between normal flooding and flooding reduction"

2019-05-29 Thread Robert Raszuk
Hey Peter,


> > Is it more efficient that only one area leader indicates(according to
> the command from NMS) explicitly then the network will be back to normal
> flooding?
>
> yes and we have that in the draft:
>
> "When the Area Leader advertises algorithm 0 in its Area Leader Sub-
> TLV and does not advertise a flooding topology, Dynamic Flooding is
> disabled for the area.  Note this applies whether the Area Leader
> intends to operate in centralized mode or in distributed mode."
>

Two little questions ...

- I think to avoid potential ambiguity in implementations it would be worth
clarifying what "does not advertise" means ... does it mean that Area Node
IDs TLV is not present all together or does it mean that it MAY be present
but it is sufficient that it does not contain any Node ID .. or both ?

- how does this apply to distributed mode if flooding topology is to be
used only in centralized mode ? Isn't the quoted text from section 6.4 a
bit incorrect and requires a fix ?

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


Re: [Lsr] Summary of WGLC discussion about draft-ietf-isis-te-app-06.txt and draft-ietf-ospf-te-link-attr-reuse-07.txt

2019-05-24 Thread Robert Raszuk
> With respect to your comments on BGP-LS, this is out of scope for LSR.

During last IETF it has been communicated by IDR chairs that there is an
agreement that all IGP extensions in LSR WG will define in the same
document also extensions to BGP-LS so the work is not duplicated and that
IDR will stop dealing with IGP encoding.

Quote from minutes:

"Propose: one document to keep the encoding in both IGP and BGP-LS. asking
LSR to handle encoding in their document set "

Chair's slide 5:

"Propose asking LSR to handle encoding in their document set"

Putting aside to what I personally think about BGP-LS are you as LSR
co-chair not going to follow the above recommendation/proposal ?

Thx,
R.



On Fri, May 24, 2019 at 1:12 PM Acee Lindem (acee)  wrote:

> Hi Olivier,
> I think the WG's energy has been completely focused on the dynamic
> flooding and these WG last calls didn't get the deserved attention.
>
> As for as your comments, the first two were discussed for over a year and
> half. There were other advantages as well. For example, the link attribute
> encoding reduced (OSPFv2) or eliminated (OSPFv3) the need to correlate LSA
> attributes for a single link. We will note your objection in the shepherds
> report on the documents. We could even include a pointer to your quagga
> code that took a different approach if you wish to provide one.
>
> With respect to your comments on BGP-LS, this is out of scope for LSR.
> While I haven't seen NLRI that hits the limit, I'm confident that the IDR
> WG will come up with a solution.
>
> Thanks,
> Acee
>
> On 5/23/19, 5:57 AM, "Lsr on behalf of olivier.dug...@orange.com" <
> lsr-boun...@ietf.org on behalf of olivier.dug...@orange.com> wrote:
>
> Dear all
>
> As there is no more exchange about the two mentioned drafts since 3
> weeks, I'll try to summarize the exchange and
> the requested modifications.
>
> The drafts proposed to extended IS-IS respectively OSPF to advertise
> new TE parameters to overcome 2 issues:
>  1 - Topology incongruence between the IGP and TE
>  2 - Provide different parameters per application
>
> For the first point, topology incongruence is not due to the protocol
> itself but to the fact that an operator
> may activate or not TE information on all links of its network.
> Indeed, RFC3630 and RFC5305 precise that TE
> information are Optionals.
>
> However, in both drafts, the term RECOMMENDED is used, which IMHO not
> solve the problem. An operator keeps the choice
> to activate or not this new TE information leading again to an
> incongruence network topology. At least, wording
> need to be change to MUST or MANDATORY. But, why not just change the
> wording of RFC3630 and RFC5305 ?
>
> In addition, no operator express explicitly that their are concern by
> topology incongruence.
>
>  => Introduction sections should be improved to better justify why we
> need to modify TE link advertisement
>  => Wording must be revise to avoid incongruence topology
>
> For the second point, TE information are related to a link not an
> application even if at the origin, RFC3630 and RFC5305
> were design for RSVP-TE. It is not mention in the RFCs that they could
> not be applicable to other protocol / application.
>
> If the idea, in liaison to first point, it to determine is an
> application / protocol is enable / disable on a given link,
> even if their have been not selected, drafts
> draft-hegde-ospf-advertising-te-protocols-01.txt and
> draft-hegde-isis-advertising-te-protocols-03.txt are largely
> sufficient as it is not necessary to duplicate link TE
> information. In addition, Router Information already provides
> indication on the support of SR by this router (presence
> of SRGB) where all IGP links are de-facto SR enable.
>
> Then, GMPLS specific attributes are not taken into account in these
> drafts.
>
>  => GMPLS must be considered as another application and specific GMPLS
> attribute must be part of the drafts
>  => or standardised only SABML / UDABML flags without duplicating TE
> information
>
> Network operational transition issues are poorly address in these
> drafts. Indeed, router upgrade
> take time in large scale network (several weeks even several months)
> leading cohabitation of the 2 systems which
> introduce a large degree of complexity for operators for network
> management.
>
>  => Improve migration section to help operator during the transition
> phase
>
> And finally, if we go a bit further, dealing with SDN, all these new
> TE information need to be learnt by and SDN
> controller e.g. a PCE, which naturally conduct to use BGP-LS for this
> purpose. However, recent discussion in idr WG
> mention that there is already too many attributes that have been
> standardised dealing with problem with the maximum
> size of BGP message. These new TE information will also certainly
> appear as duplicate 

Re: [Lsr] Migration between normal flooding and flooding reduction

2019-05-22 Thread Robert Raszuk
One may observe that the draft implicitly also supports already option A
too. If leader advertises full topology wouldn't it effectively disable
dynamic flooding automatically ?

At least no NMS or configuration push is required on all 1000s of nodes to
go back to full flooding say for the purpose of self distruction of your
fabric ;).

Thx,
R.

On Wed, May 22, 2019, 05:46 Les Ginsberg (ginsberg) 
wrote:

> Huaimo –
>
>
>
> The thread started with you defining multi-step processes for electing an
> area leader and enabling/disabling dynamic flooding – each of which
> involved multiple state changes on each node in the network. (Please scroll
> to the bottom to see your original post.)
>
>
>
> Both Tony and I responded by saying “no need for that”. Election of an
> Area Leader proceeds just like election of DIS on a LAN in IS-IS – totally
> event driven.
>
> Enabling/disabling of dynamic flooding happens based on what algorithm the
> Area Leader advertises and whether (in centralized mode) the Flooding
> Topology is advertised.
>
>
>
> Sections 6.4, 6.5, and 6.7 describe this.
>
>
>
> In response to my comment you have now changed the topic to discussing
> whether a config change is required on every node in order to
> enable/disable dynamic flooding.
>
> Different topic. It’s a bit hard to keep the thread focused when you
> change the topic.
>
> In brief, I do not see a problem supporting your “Option B” below – and
> the draft provides for that. We may want to make the wording more precise –
> I am certainly open to that – but the capability is already there..
>
>
>
>Les
>
>
>
>
>
> *From:* Huaimo Chen 
> *Sent:* Tuesday, May 21, 2019 3:13 PM
> *To:* Les Ginsberg (ginsberg) ; tony...@tony.li
> *Cc:* lsr@ietf.org
> *Subject:* RE: [Lsr] Migration between normal flooding and flooding
> reduction
>
>
>
> Hi Les,
>
>
>
> Consider the following options to transfer all nodes in an area from
> flooding reduction to normal flooding or from normal flooding to flooding
> reduction:
>
> Option A: Go to all the nodes (if there are thousands of nodes, go to all
> of them), execute “disable flooding reduction” or “enable flooding
> reduction” on all of them.
>
> Option B: Go to the leader (even if there are thousands of nodes, just go
> to the leader), execute “roll back to normal flooding” or “transfer to
> flooding reduction” on the leader.
>
>
>
> Option B should be supported. Option B provides a simpler and quicker way
> to transfer between flooding reduction and normal flooding.
>
>
>
> It seems that Option A is similar to going to all the nodes and
> configuring an algorithm to compute the FT for distributed mode; and Option
> B is similar to going to the leader and configuring an algorithm to compute
> the FT for distributed mode, which is used in
> draft-ietf-lsr-dynamic-flooding.
>
>
>
> Best Regards,
>
> Huaimo
>
> *From:* Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com
> ]
> *Sent:* Monday, May 20, 2019 4:39 PM
> *To:* Huaimo Chen ; tony...@tony.li
> *Cc:* lsr@ietf.org
> *Subject:* RE: [Lsr] Migration between normal flooding and flooding
> reduction
>
>
>
> Huaimo –
>
>
>
> I, like Tony, am wondering what problem you are trying to solve.
>
>
>
> Note that updated LSPs/LSAs which are received on an interface which the
> receiving node believes is NOT part of the flooding topology are NEVER
> discarded. They are processed and flooded on those interfaces which the
> receiver believes are part of the flooding topology.  So there is no need
> for the coordination you propose. The network can transition from no
> flooding optimizations to flooding optimizations – or vice versa – simply
> by enabling/disabling optimizations.
>
>
>
> The speed at which the migration occurs is not critical. What is critical
> is that correct flooding is not compromised during the migration and (as
> Tony has noted) based on testing that works without any issues.
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of *Huaimo Chen
> *Sent:* Monday, May 20, 2019 12:53 PM
> *To:* tony...@tony.li
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] Migration between normal flooding and flooding
> reduction
>
>
>
> Hi Tony,
>
>
>
> For the case that the IGP running in an area has been doing the
> flooding reduction, in order to let the IGP on every node in the area roll
> back to the normal flooding quickly and easily, a procedure for migrating
> from the flooding reduction to normal flooding is needed. After back to
> normal flooding, if we want to let the IGP on every node do flooding
> reduction some time later, the procedure should be able to migrate from
> normal flooding to the flooding reduction quickly and easily.
>
>
>
> Best Regards,
>
> Huaimo
>
> *From:* Tony Li [mailto:tony1ath...@gmail.com ] *On
> Behalf Of *tony...@tony.li
> *Sent:* Saturday, May 18, 2019 1:17 PM
> *To:* Huaimo Chen 
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] Migration between normal flooding and flooding
> reduction
>
>
>
>
>
> Hi Huaimo,
>
>
>
> 

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-crh-isis-extensions-00.txt

2019-05-14 Thread Robert Raszuk
Hi Ron,

Could you provide pointer to comparison of CRH vs SRH ? Do we really need
to standardize both ? Is this going to help any practical deployments ?

Very honestly when I read this draft I needed to check date as I though we
are back in 2002/2003 when CR-LDP was trying to compete with RSVP-TE :)

Cheers,
R.


On Tue, May 14, 2019 at 5:20 PM Ron Bonica  wrote:

> Folks,
>
> Please review and comment.
>
>Ron
>
>
> Juniper Public
>
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Tuesday, May 14, 2019 11:14 AM
> To: Ron Bonica ; Shraddha Hegde ;
> Parag Kaneriya ; Rajesh M 
> Subject: New Version Notification for
> draft-bonica-lsr-crh-isis-extensions-00.txt
>
>
> A new version of I-D, draft-bonica-lsr-crh-isis-extensions-00.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
>
> Name:   draft-bonica-lsr-crh-isis-extensions
> Revision:   00
> Title:  IS-IS Extensions To Support The IPv6 Compressed Routing
> Header (CRH)
> Document date:  2019-05-14
> Group:  Individual Submission
> Pages:  13
> URL:
> https://www.ietf.org/id/draft-bonica-lsr-crh-isis-extensions-00.txt
>
> Status:
> https://datatracker.ietf.org/doc/draft-bonica-lsr-crh-isis-extensions/
>
> Htmlized:
> https://tools.ietf.org/html/draft-bonica-lsr-crh-isis-extensions-00
>
>
> Abstract:
>Source nodes can use the IPv6 Compressed Routing Header (CRH) to
>steer packets through a specified path.  This document defines IS-IS
>extensions that support the CRH.
>
>
>
>
> 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] Working Group Adoption Call for "IS-IS Extensions to Support Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

2019-05-09 Thread Robert Raszuk
Isn't the draft's name a bit misleading ?

"IS-IS Extensions to *Support* Routing over IPv6 Dataplane"

I think ISIS supports routing over IPv6 for some time now :) Maybe it would
be better to s/Support/Segment/ ?

In any case I support the adoption.

Thx,
R.

On Thu, May 9, 2019 at 3:50 PM Acee Lindem (acee)  wrote:

> We been holding off WG adoption until the base SRv6 draft was adopted in
> SPRING. Now that
> https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/
> has been adopted, we are starting a two week LSR WG adoption poll for the
> subject draft. Please register your support or objection prior to 12:00 AM
> UTC, on May 25th, 2019.
>
>
>
> For your convenience, here is a URL for the draft:
>
>
>
> https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions/
>
>
>
> 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-15 Thread Robert Raszuk
Peter,

IMO what Olivier has indicated is a practical and operational aspect. The
theoretical aspects of protocol operation is what this document is
extending. Those are two different things :)  And this is not the first
time where IETF is manufacturing specs without any serious input from folks
who actually need to use it. The co-authors of this very draft indicates it
quite clearly - all vendors !

It would be very operationally complex and completely bizarre to run N
different TE applications concurrently in any production network. The fact
that you could or can does not make it immediately a good idea. Perhaps
great exercise for the lab though.

Even with one such TE mechanism there is a lot of things to manage and that
is why very few networks run full 100% TE. Further more as you know TE
reservations are all in control plane so the moment you forward any
significant amount of non TE traffic (unicast or multicast) your entire TE
magic is over.

Last I was hoping someone will answer how for a given link of RTT 20 ms -
you could send different value per each application ? Or do you mean that
on any given link mpls RTT != IPv4 RTT != IPv6 RTT ?

Kind regards,
R.

On Mon, Apr 15, 2019 at 10:49 AM Peter Psenak  wrote:

> Hi Olivier,
>
> On 12/04/2019 16:26 , olivier.dug...@orange.com wrote:
> > Hello Peter,
> >
> >
> > Le 12/04/2019 à 15:27, Peter Psenak a écrit :
> >> Hi Oliver,
> >>
> >> There are two major purposes served by the drafts:
> >>
> >> 1)Support of incongruent topologies for different applications
> > Don't understand. What do you mean ?
>
> RFC3630 allows the traffic engineering topology to be incongruent with
> the regular routing topology. This means that the RSVP TE topology can
> only be a subset of the regular routing topology. If there is a need to
> advertise some link attribute for the purpose of the other application,
> the link would become part of the RSVP TE topology, something that may
> not be desired.
>
> >>
> >> 2)Advertisement of application specific values even on links that are in
> >> use by multiple applications
> > Hum. Do you think it makes sense to announce different TE metric for the
> > same link for different applications ? e.g. 10 ms delay for RSVP-TE, 20
> > ms for SR, 15 ms for LFA and 5 ms for Flex -Algo ? The link has a fix
> > delay propagation whatever the application.
> >
> > If the goal is to dedicated link per application, Resource Class/Color
> > attribute could be used. If you would advertised different metric per
> > CoS, then you need to dedicated metric per CoS like the unreserved
> > bandwidth.
>
> The goal is the allow the link to be used by multiple applications, but
> be advertised with application specific attributes.
>
> >>
> >> 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.
> > Can you point me a concrete and detail example of the problem ? With a
> > PCE, there is no problem to manage both RSVP-TE and SR-TE in the same
> > network. And again, as already mention, if the problem come from
> > bandwidth reservation, the draft will not solve the issue.
>
> there is no way to advertise the link for the purpose of the SR-TE,
> without it becoming the part of the RSVP-TE using existing
> advertisements. Similarly applicable in the context of any other
> application.
>
> >>
> >> 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.
> > Again, I don't see the problem. Can you explain in detail ? I already
> > implement SR in OSPF, starting playing with TE, and there is no problem
> > to get TE information from OSPF to tune some Segment Path. If it is an
> > implementation issue, it is not a new RFC that will solve the problem.
>
> we are not trying to solve the implementation issue. We are solving the
> protocol issue. Both protocols have defined many link attributes for the
> purpose of the RSVP-TE. Some of these are usable outside of the RSVP TE
> and we are extending the protocols to support that.
>
> Please read the discussion on the mailing list that happened prior to
> the WG adoption of these drafts.
>
> >>
> >> It is simply not possible to address these issues with the existing
> >> single set of application independent advertisements.
> > Why ? Again, explain in detail. I don't see a real use case that could
> > not be address with standard TE attributes.
>
> please see above.
>
> thanks,
> Peter
>
>
> >>
> >> 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
> >
> > Regards
> >
> > Olivier
> >
> >>
> >> On 11/04/2019 19:43 , 

Re: [Lsr] LANs in IGPs

2019-04-03 Thread Robert Raszuk
Well imagine I am building DMZ with two gateways and a firewall connected
to L2 switch. I run IGP between them so my iBGP next hops can resolve.

Later I may perhaps add third and fourth gateway.

I can not normally set it as p2p IGP day one, but it could operate fine for
the first few years as such.

Thx,
R.



On Wed, Apr 3, 2019 at 8:10 PM Les Ginsberg (ginsberg) 
wrote:

>
>
> If you want a way to more easily enable P2P mode by default – speak to
> your favorite vendor. That is a feature – not a protocol extension.
>
>
>
> Completely disagree. To detect how many IGP peers are on the interface
> and to do the switchover gracefully between 2 vs N or N vs 2 protocol
> extension is needed. It is not a single side local hack.
>
>
>
> *[Les:] You are saying that customers today need to deploy circuits on
> which they are uncertain whether they will connect two nodes or more than
> two nodes?*
>
> *This is the first I have heard of such a requirement.*
>
>
>
> *If this really is a deployment requirement then such an extension could
> be considered. But since the extension isn’t trivial and isn’t backwards
> compatible I would not take this on without justification.*
>
> *Be interested to hear if anyone else on the deployment side of things
> believes this is needed.*
>
>
>
> *   Les*
>
>
>
> Thx,
>
> 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] LANs in IGPs

2019-04-03 Thread Robert Raszuk
> What extension are you proposing?

If you have only two routers on LAN based on IIH multicast discovery you
are still forming an adj between them (you do that anyway as one of them
will be DIS). But for flooding reduction point of view you can treat it as
p2p link (so it must be signaled as such).

When Nth (N >= 3) router comes up you fall back to LAN mode and here you
can support it or not.

I guess your take is that since you want to support it anyway when N >= 3
there is no point of building the special case for the N=2.

Thx,
R.







On Wed, Apr 3, 2019 at 7:56 PM  wrote:

>
> Hi Robert,
>
> But I really think this isn’t relevant. The use of LANs in the flooding
>> topology is only meaningful if we have a multi-access circuit which is used
>> for transit traffic. And at least some of us are leaning to allowing for
>> that possibility – which is not at all the same thing as saying you SHOULD
>> run in LAN mode even if you don’t have to. Nor is it encouraging the use of
>> multi-access LANs.
>>
>
> I guess this is the question ... is dynamic flooding a new flooding
> paradigm in IGPs to be used everywhere or is it only applicable to densely
> connected topologies ?
>
>
>
> It is only sensible in dense topologies.  In sparse topologies, such as
> you would find in a WAN, there is very little improvement to be had.
>
> For example, at Prague I showed an 8x8 grid.  The FT improvement was only
> 36%.  Given the computational cost, it’s probably not worth it.
>
>
> If this is former - by all means support of real LANs is must have. If
> this is the latter - I doubt.
>
> In fact if this is the latter more simplification in computing flooding
> graph, less complexity in signalling and therefor less bugs will IMHO yield
> much better outcome.
>
> In such cases it may be actually a feature to limit dynamic flooding to
> p2p topologies only.
>
>
>
> Well, I have to disagree.  While it’s nice to say that you will limit that
> feature to those topologies, real operators push the envelope all of the
> time.  Things happen operationally. Folks can definitely use LANs
> advantageously in dense topologies. It makes sense to support them.
>
> If you want a way to more easily enable P2P mode by default – speak to
>> your favorite vendor. That is a feature – not a protocol extension.
>>
>
> Completely disagree. To detect how many IGP peers are on the interface
> and to do the switchover gracefully between 2 vs N or N vs 2 protocol
> extension is needed. It is not a single side local hack.
>
>
>
> What extension are you proposing?
>
> 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] LANs in IGPs

2019-04-03 Thread Robert Raszuk
Hi Les,

Sorry – but I really think you are taking this thread off topic.
>

If asking a question which is outside of the box is equal to thread
hijacking then sorry. But you won - subject line changed.

But I really think this isn’t relevant. The use of LANs in the flooding
> topology is only meaningful if we have a multi-access circuit which is used
> for transit traffic. And at least some of us are leaning to allowing for
> that possibility – which is not at all the same thing as saying you SHOULD
> run in LAN mode even if you don’t have to. Nor is it encouraging the use of
> multi-access LANs.
>

I guess this is the question ... is dynamic flooding a new flooding
paradigm in IGPs to be used everywhere or is it only applicable to densely
connected topologies ?

If this is former - by all means support of real LANs is must have. If this
is the latter - I doubt.

In fact if this is the latter more simplification in computing flooding
graph, less complexity in signalling and therefor less bugs will IMHO yield
much better outcome.

In such cases it may be actually a feature to limit dynamic flooding to p2p
topologies only.


> If you want a way to more easily enable P2P mode by default – speak to
> your favorite vendor. That is a feature – not a protocol extension.
>

Completely disagree. To detect how many IGP peers are on the interface  and
to do the switchover gracefully between 2 vs N or N vs 2 protocol extension
is needed. It is not a single side local hack.

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


  1   2   >