Aijun,
AJ] For your proposed BGP solutions, Peter has responded you and I agree
> with his opinions with the followings additional comments:
>
All Peter keeps saying is that the solution must work where BGP is non
existent. I question whether BGP in any network is non-existent. .
> [Option 1]:
Aijun,
[WAJ] For SRv6 policy based tunnel, the previous node may not be the
> neighbor node. It may locate in other area.
>
Only in the case of binding SIDs on the penultimate segment endpoint such
signalling would perhaps help.
In all other cases the information MUST be propagated to the
Aijun,
[WAJ] As Peter and I state several times, we want to find the generic
> solution for different scenarios. BGP exist or not.
>
Maybe you missed my point. I am not aware of any production router stack
which would not support BGP. That is irrespective of if BGP is used for
service
> Pulse cleans up itself without any additional flooding, that's the whole
> idea of it.
That's the most scary and not well understood part of it. Ghosts ! Appears
and magically disappears.
> It also is not part of the LSDB that IGP uses for
> computation, so it does not affect the scale.
>
(say mGRE) this is no longer possible
as the interface there is p2mp so it can not go down if even one remote PE
is still up.
Thx,
R.
On Fri, Nov 26, 2021 at 5:36 PM Peter Psenak wrote:
> Robert,
>
> On 26/11/2021 17:18, Robert Raszuk wrote:
> > Peter,
> >
> > Technically I se
to be written, tested and deployed. Leave alone aspect of
network wide flooding of those PULSEs.
Many thx,
R.
On Fri, Nov 26, 2021 at 4:38 PM Peter Psenak wrote:
> Robert,
>
> On 26/11/2021 15:06, Robert Raszuk wrote:
> > Peter,
> >
> >
Huzhibo,
> specifying the master/backup relationship of egress protection is complex
Sure is - but there is absolutely no requirement to do it. BGP already
carries all information needed to instantiate such protection. It is
therefore all dynamic and automated.
As said cost is extra LFIB space
5 PM Peter Psenak wrote:
> Robert,
>
> On 25/11/2021 18:25, Robert Raszuk wrote:
> > Dear LSR WG,
> >
> > I wanted to visualize the scenario we are so deeply discussing here.
> > Specifically BGP vs IGP flooding as well as applicability of RFC8679.
> >
&g
RFC 8679 does not require RSVP-TE to work.
Best,
R.
On Thu, Nov 25, 2021 at 5:30 PM Gyan Mishra wrote:
>
> Hi Shraddha
>
> The PUA draft is detecting the BGP NH liveliness based on the PUA
> protection mechanism for immediate control plane convergence immediately
> on alternative next -
Hi Aijun,
> #3
>
> > [WAJ] It is the IGP advertises the inaccurate information, why let BGP
> clear up? Won’t you estimate the IDR experts will resist?
>
> There is nothing inaccurate in the IGP advertisement. IGP does
> precisely what the operator configured it to do.
>
> [WAJ] It lack some more
Hi Aijun,
Just few points to your note.
#1
> when ABR does the summary work
In a lot of your emails you keep stating that ABR or IGPs do summarization.
Well that is not true. It is operators which configure the summarization.
It is important to recognize this difference.
It is also operators
Aijun,
Nothing Shraddha is describing is about protecting intermediate hops.
She illustrated different solutions for egress protection of PEs.
It has some cost and some deployment limitations but it is an option to
consider.
Thx,
R.
On Wed, Nov 24, 2021 at 6:44 AM Aijun Wang
wrote:
> Hi,
Peter,
> it requires SID allocation to be synchronized between multiple egress PEs.
That is not correct.
The concept Shraddha is describing does not require any synchronization of
either VPN demux label or SIDs.
In an essence you create based on regular service routing propagation a
shadow
jun Wang
wrote:
> Hi, Robert:
>
> Aijun Wang
> China Telecom
>
> On Nov 23, 2021, at 21:22, Robert Raszuk wrote:
>
>
>
> [WAJ] What I want to express is the overall time from the failures occur
>> to the ABR notice it via only IGP procedures. Shouldn’t it b
> [WAJ] What I want to express is the overall time from the failures occur
> to the ABR notice it via only IGP procedures. Shouldn’t it be within
> millisecond within one area?
>
No. Not at all.
OSPF hello def timer is 10 sec in some implementations I just checked.
So unless you can quickly
, 2021 at 1:26 PM Aijun Wang
wrote:
> Hi, Robert:
>
> Aijun Wang
> China Telecom
>
> On Nov 23, 2021, at 20:00, Robert Raszuk wrote:
>
>
> Dear Aijun,
>
>
>> [WAJ] Once there is a link/node failure, upon receiving the updated LSA,
>> the ABR
>
Dear Aijun,
> [WAJ] Once there is a link/node failure, upon receiving the updated LSA,
> the ABR
>
That node failure will need to be detected fast.
The entire discussion here is to do it reasonably fast or as fast as
possible. That is why such detection must happen quickly via LOS or BFD
I hope you are not talking about IGP hellos or BGP keepalives here.
We are talking PE-P or PE-RR.
Thx,
R.
On Tue, Nov 23, 2021 at 12:38 PM Aijun Wang
wrote:
> Hi, Robert:
>
> Aijun Wang
> China Telecom
>
> On Nov 23, 2021, at 18:04, Robert Raszuk wrote:
>
>
&g
Support.
On Mon, Nov 22, 2021 at 3:11 PM Acee Lindem (acee) wrote:
> We indicated the intent to adopt of
> draft-decraeneginsberg-lsr-isis-fast-flooding-00 as an LSR WG document at
> the IETF 112 LSR WG meeting.
>
> We are now confirming WG consensus on this action. Please indicate your
>
tries in the forwarding plane. As such, it solves the scaling of
>> >>
>> >> pure IP routers sharing the IGP with MPLS routers. However, it
>> does
>> >> not decrease the number of LFIB entries so is not sufficient to
>> solve
>> >>
cussed, the potential usage of such information is not
> only BGP, but may be tunnel endpoints.
>
> Yes, I agree, the light speed is the same.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@i
Aijun,
*> or lose the fast convergences*
Putting aside all the drawbacks already discussed, what makes you think
that flooding LSPs or LSAs across tens of hops over 2 or maybe soon 8 areas
would be any faster then sending BGP UPDATE message(s) across 2-3 RRs ?
Assume you need to detect the
te for RFC 5283 and why it was never deployed by
> operators.
>
>
> SRv6 is an answer but majority of all SPs are not there yet and we need to
> be able support MPLS for a long time to come beyond our lifetime.
>
> Kind Regards
>
> Gyan
>
> On Mon, Nov 22,
better to leak host routes with opaque stuff when needed
rather then then leak blindly everything everywhere.
Cheers,
R.
On Mon, Nov 22, 2021 at 3:12 PM Peter Psenak wrote:
> On 22/11/2021 15:00, Robert Raszuk wrote:
> >
> > it's not a choice, that is an MPLS architectu
Are you saying this draft is useless ?
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/
Thx,
R.
On Mon, Nov 22, 2021 at 2:54 PM Gyan Mishra wrote:
>
> Correction related to SRv6 as if uses the native IPv6 data plane it does
> out of the box support summarization.
>
> A
time to look at SRv6, it does net require end-to-end LSP with host
> reachability - e.g. summarization is possible.
>
And how do I know if remote PE is even SRv6 capable and for what behaviours
? How do I know its functions ? How about using EPE with adj SID on it ?
How will the ingress know all
what is required.
Thx,
R.
On Sun, Nov 21, 2021 at 5:19 PM Gyan Mishra wrote:
>
>
> On Sun, Nov 21, 2021 at 6:50 AM Robert Raszuk wrote:
>
>>
>> > So we desperately need a viable IGP summarization
>>
>> And could you elaborate on how summarization i
Hi Aditya,
> Meanwhile, if you have the ABR as the inline RR changing the BGP NH to
> itself and hiding the egress PE, even in that case ingress PE doesn’t need
> to worry about the egress PE as long as BGP service route is available with
> ABR as NH and let ABR figure out the available egress
flooding the routes in the IGP or use LDP ordered label
>> distribution.
>>
>>
>> Even if you used LDP ordered label distribution is still does not solve the
>> problem of robbing Peter to pay Paul now dumping the flooding of host routes
>> on MPLS LFIB making
> The ABR should do the summary work based on the liveness, right?
Really ???
It seems we are as the WG in a form of a disconnect on that one .. rather
fundamental to what IGPs are or are supposed to be.
One way to look at them is an analogy to road signs which first tell you
the direction to
All,
With all the discussions about how to accomplish this I have one
fundamental doubt.
Let's take SR and ISIS or OSPF extensions for it (say RFC8667).
It seems that none of it works network wide if we instead of prefix
reachability start advertising summary routes from ABRs to
other
Aijun,
> [WAJ] I agree with you on this point. But how about your comments for such
> considerations in
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-7.
> We have considered how to reaction to the mass outrage at the beginning.
>
That section
easonable an assumption that is better than I.
>
> I also think the scale numbers discussed in the draft have increased
> significantly over the years – which further stresses the use of this
> approach.
>
>
>
>Les
>
>
>
>
>
> *From:* Robert Raszuk
> *Se
destinations covered by an IGP
> originated summary advertisement and some folks do not.
>
>
>
> Thanx.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk
> *Sent:* Friday, November 19, 2021 12:25 PM
> *To:* Peter Psenak
> *Cc:* Tony Li ; Les Ginsberg (gin
Peter,
> yes, but it's not specific to flat areas. Even in multi-area deployments
> the host routing is mandated by MPLS.
In the early days of MPLS yes that was the case.
But that "mandate" was fixed by Ina, Bruno and Jean-Louis in 2008 :)
https://datatracker.ietf.org/doc/html/rfc5283
In
> I don’t think their is an easy way to solve this in BGP.
Can you briefly elaborate why ? What is difficult using BGP native
recursion ?
Thx,
R.
On Fri, Nov 19, 2021 at 1:14 AM Gyan Mishra wrote:
>
> Hi Tony
>
> The issue exists related to domain wide flooding to support seamless MPLS
> E2E
Hi les,
*[LES2:] It is reasonable to limit the rate of pulses sent. Peter has
> already indicated in an earlier reply that we will address that in a future
> version of the event-notification draft. So, good point – and we are in
> agreement regarding mass failure.*
>
In respect to the
Hi Tony,
> How so? Doesn’t this correspond 1:1 with overlay BGP sessions?
Not at all.
BGP is never full mesh across multiple areas. RR hops are used. BFD does
not have concept of RRs last time I looked at it :)
Kind regards,
R.
On Thu, Nov 18, 2021 at 5:38 PM Tony Li wrote:
> Les,
>
>
> If you want to address this problem with BGP keep alive timers, that’s
certainly an alternative as well.
Nope that is not what I previously described in this thread.
BGP uses recursion. So you can propage next hops in BGP and recurse your
service route next hops over those with simple config
Tony,
Why would we need to deploy a full mesh of BFD or introduce a new proxy
liveness service if BGP can do all what is needed here with just a few
lines of additional cfg on existing and deployed operating systems ?
In respect to using BFD here - let's start with basic question - who would
be
ate such reachability information, we
> have mechanism to control for which covered prefix to send the notification
> when they become unreachable. It is not randomly suppressed.
>
>
> Aijun Wang
> China Telecom
>
> On Nov 18, 2021, at 21:27, Robert Raszuk wrote:
&g
to send the notification
> when they become unreachable. It is not randomly suppressed.
>
>
> Aijun Wang
> China Telecom
>
> On Nov 18, 2021, at 21:27, Robert Raszuk wrote:
>
>
>
> In such cases I would rather consider implementing pulse to be less then
> host
wrote:
> Robert,
>
> On 18/11/2021 13:42, Robert Raszuk wrote:
> > [WAJ] In the scenarios that you mentioned, BGP nexthop reachability
> > is derived from the directed interface, there is no summary action
> > done by the router. Is that true?
> >
>
> [WAJ] In the scenarios that you mentioned, BGP nexthop reachability is
> derived from the directed interface, there is no summary action done by the
> router. Is that true?
>
Not necessarily - TORs do not always do eBGP to compute and set next hop
self. There can be IBGP session there and
Les, All,
One thing to keep in mind in this entire discussion is the reality of
compute nodes becoming L3 routing nodes in many new architectures. The
protocol which is used between TORs and such compute nodes is almost always
BGP. That means that no matter what we do in the IGP we will not avoid
ior to L2 route leaking). It's not sufficiently
> accurate to rely on the aggregates in these cases.
>
> Thanks. -- Enke
>
>
>
>
> On Fri, Oct 15, 2021 at 10:37 AM Robert Raszuk wrote:
>
>> Enke,
>>
>> Not really ... unless you force it by configurat
Enke,
Not really ... unless you force it by configuration most specific route is
used to resolve your next hops.
Clearly everything works fine from your list with no loopbacks everywhere -
except summary route is used instead.
Best,
R.
On Fri, Oct 15, 2021 at 7:21 PM Enke Chen
wrote:
> Hi,
Hi Tom & Acee,
To the best of my knowledge what may have triggered spam in this thread for
you is not ISIS nor IS-IS words.
It is used twice "quote" "quote" as such special characters are very
rear and unsual in the subjects of normal email communication.
Thx,
Robert
On Fri, Oct 15, 2021 at
t.
>
>
>
> If this was expected to be a large amount of information and needed to be
> sent with great frequency, I think your preference might well make more
> sense – but for the given use case that amount/rate of traffic would be
> unusual.
>
>
>
>Les
>
&g
, 2021 at 10:37 PM Les Ginsberg (ginsberg)
wrote:
> Robert –
>
>
>
> Inline.
>
>
>
> *From:* Robert Raszuk
> *Sent:* Wednesday, October 13, 2021 12:52 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Acee Lindem (acee) ; Peter Psenak (ppsenak) <
> ppse...@cisc
Hi Les,
> If we can agree that an IGP solution is useful, then we can use this
thread to
> set a direction for the IGP solution
I think this thread aimed to answer both of those questions hence some
comments.
But even if we assume that Event Flooding via IGP have a valid use case
(regardless if
un a 1000 MH BFD session @1sec
>
> Cheers,
> Jeff
>
> On Oct 13, 2021, at 10:16, Robert Raszuk wrote:
>
>
>
> > How many other PEs does a BGP edge PE maximally peer with?
>
> Typically on IBGP side you will see 2-4 peers. Those are RRs.
>
> Due to no auto
Below ..
>
> *From: *Robert Raszuk
> *Date: *Wednesday, October 13, 2021 at 1:16 PM
> *To: *Acee Lindem
> *Cc: *"Peter Psenak (ppsenak)" , "lsr@ietf.org" <
> lsr@ietf.org>
> *Subject: *Re: [Lsr] "Prefix Unreachable Announcement&quo
> How many other PEs does a BGP edge PE maximally peer with?
Typically on IBGP side you will see 2-4 peers. Those are RRs.
Due to no autodiscovery of BGP sessions no many people do iBGP full mesh
between PEs.
Best,
R.
On Wed, Oct 13, 2021 at 6:48 PM Acee Lindem (acee) wrote:
> Hi Peter,
>
>
Dear Aijun,
Let me reply to other your other comments ...
> In both cases such an event will likely be detected using BFD (if we are
> talking about unreachability of a BGP or IGP peer).
>
> *[WAJ] No. Link or Node Failures are not detected via BFD within one IGP
> domain. It just rely on the
Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org *On Behalf Of *Robert
> Raszuk
> *Sent:* Wednesday, October 13, 2021 3:52 AM
> *To:* Acee Lindem (acee)
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] "Prefix Unreachable
Hi Peter,
In your example of GRE between PEs .. what is the purpose of this GRE ?
Isn't it to connect services advertised via BGP ?
In any case perhaps one size does not fit all. Maybe some networks can use
BGP signalling (withdraws), maybe other will like to see bad even
notification in IGPs.
ich fits to their scale and connectivity restoration requirements. IMO
what is missing is not protocol gaps, but proper configuration of already
available features.
Many thx,
Robert.
On Tue, Oct 12, 2021 at 11:02 PM Acee Lindem (acee) wrote:
> Hi Robert,
>
>
>
> *From: *Robe
gt; problem.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Tuesday, October 12, 2021 at 3:52 PM
> *To: *"Acee Lindem (acee)"
> *Cc: *"lsr@ietf.org"
> *Subject: *Re: [Lsr]
Hi Acee,
I would like to make a comment on your point #1.
You said:
"Is this a problem that needs to be solved in the IGPs? The use case
offered in both drafts is signaling unreachability of a BGP peer. Could
this better solved with a different mechanism (e.g., BFD)..."
That is not a very
Tony,
Yes - spot on.
It is like either selecting ingredients to "make your own pizza" vs
ordering a fixed one (Pepperoni, Margarita, 4 cheese, style #135 etc...)
All I am saying is that both options are useful. And it seems defining few
most useful flex-algos may be helpful. Call it well known
Hi Tony,
> Actual interoperability testing where developers sit down and test.
To the best of my knowledge the objective of those testing is to detect
bugs or make sure that developers of different vendors read the spec they
were implementing the same way.
> what would you propose? :-)
Top
Tony,
> We are all painfully aware of the true challenges of interoperability.
Is there really some point to beating on this decades-dead horse?
IMHO the magnitude of those will exponentially increase with flex-algo if
it really takes off. Will it be manageable in some networks - perhaps.
But
> Lack of support for flex algorithm or a particular flex algorithm will not
> break things either.
>
I was not really talking about breaking.
I was more expressing an option about cross vendor support of various
metrics and constraints as part of a given flexible algorithm. I think
putting a
, Sep 16, 2021 at 10:16 PM Acee Lindem (acee) wrote:
> Hi Robert,
>
>
>
> *From: *Robert Raszuk
> *Date: *Thursday, September 16, 2021 at 5:34 AM
> *To: *Peter Psenak
> *Cc: *Linda Dunbar , Tony Li ,
> "lsr@ietf.org" , Bruno Decraene ,
> Acee Lindem , "Ac
> I believe flex-algo with additional constraints would be sufficient.
Aren't we putting too much operational complexity to the operators ?
How can anyone practically assure that such constraints will be understood
across a zoo of software versions and various implementations ?
For well known
aft is about latter. I was (also) suggesting the former.
Currently what seems to be the case is operationally not user friendly mix
of both to build arbitrary topology.
The end,
Robert.
On Mon, Aug 23, 2021 at 8:24 PM Les Ginsberg (ginsberg)
wrote:
> Robert –
>
>
>
>
>
> *From:
>
> SPT/topology is not equal to application. One can define an application
> that does not not even use any SPT. Please think in a more generic way.
>
That is 100% true.
But nothing should prevent me from defining an application the way I
choose to.
Many thx,
R.
> You continue to confuse Flex and ASLA.
>
I don't think so ... This thread is about ASLA encoding for Flex-Algo.
> ASLA is an architecture that supports multiple applications – of which
> Flex is just one of the supported applications.
>
Care to elaborate why ASLA SABM allows only 64
(ginsberg) wrote:
>
>
>
>
> *From:* Shraddha Hegde
> *Sent:* Monday, August 23, 2021 8:22 AM
> *To:* Les Ginsberg (ginsberg) ; Tony Przygienda <
> tonysi...@gmail.com>
> *Cc:* Ron Bonica ; Robert Raszuk ;
> lsr@ietf.org
> *Subject:* RE: [Lsr] New Version Noti
Peter,
> > Question: Can I use UDABM to set bits in metrics for use with selective
> > flex-algo topologies ?
>
> no, all flex-algo constraints are defined in the flex-algo draft.
>
That's news to me. And from what I am seeing not only to me.
So I ask vendor X & Y to allow me to set 2 bits in
n the renamed thread.
>
> Note that I am NOT encouraging you to continue this discussion – I am in
> full agreement with Peter. I do not think what you propose is desirable or
> needed.
>
>
>
>Les
>
>
>
>
>
> *From:* Robert Raszuk
> *Sent:* Sunday, A
Hey Peter,
> And I will perhaps say it again that to me flex-algo is more of a
> > mechanism to build new applications then NEW APPLICATION itself.
>
> no, flex-algo is a single application, it's not a mechanism to create
> new applications. The fact that you can create many constraints
>
Les,
I beg to differ.
>
> *[LES:] Your statement suggests (and I am certain you do not mean to do
> so) that if only we had the foresight to define the A-bit in RFC 8919/8920
> that we could have introduced support for Flex-Algo without writing any new
> code at all. ***
>
Nope. I meant to say
1 with all 0s or length is 0 on A
> bit presence and if 0 will the current implementations hold up to that ;-)
>
> Les, correct me if I'm off somewhere, I was watching lots of that just
> from the corner of my eye ;-)
>
> -- tony
>
>
>
> On Sat, Aug 21, 2021 at 2:06 AM Les G
> But the entire point of A-bit is that you are doing this exercise to make
> sure your routers understand A-bit only one time.
>
> *[LES:] This does not mean that you can introduce support for a new
> application (call it “bit N”) w/o upgrading your routers simply because you
> already have A-bit
A-bit only one time.
Otherwise you need to do it each time you invent a new bit.
Thx,
R.
On Sat, Aug 21, 2021 at 1:34 AM Les Ginsberg (ginsberg)
wrote:
> Robert –
>
>
>
> Inline.
>
>
>
> *From:* Robert Raszuk
> *Sent:* Friday, August 20, 2021 1:29 PM
Hi Les,
Please see below.
It is not just that a new application wants to use the same link attribute
> value that allows you to use the "all applications" encoding. It is also
> necessary for the set of links used by the new application to be identical
> to the set of links used by the existing
> you can have up to 128 flex-algo topologies, each using different
> constraint. What else do you need?
>
Isn't that a FAD limit ?
So if I have a metric X advertised on all links and want to include it
only on some specific links to compute SPT in one or few special flex-algo
topologies how do
es to Exclude links
> > from flex-algo topology which is much simpler.
> >
> > Rgds
> > Shraddha
> >
> >
> > Juniper Business Use Only
> >
> > -Original Message-
> > From: Peter Psenak
> > Sent: Saturday, July 31, 2021 1:07 AM
> Information of Type 2 should be advertises as ASLA.
>
>
>
> Information of Type 3 should be considered on an application by
> application basis. For Flexalgo, it should be advertised in the FAD.
>
>
>
>
>
Hi Ron,
Please kindly enlighten me on your line of thinking ...
Let's consider your list:
Total physical bandwidth
Number of LAG elements
Bandwidth of smallest lag member
Latency
Then as a method of distributing them you choose your option 3 which reads:
"Configure this information in a few
t; Would you expect the protocol to correctly perform topology specific
> calculations if the advertisements from each node did not include a
> topology ID?
>
>Les
>
> > -Original Message-----
> > From: Tony Li On Behalf Of Tony Li
> > Sent: Friday, July 30, 2021
Hi Tony,
If architecture enforces you to flood metric to topology mappings then you
don't have the issue of disconnect of control and mgmt plane.
So far IGPs are very solid in that respect. Much more solid then other
protocols.
I am a bit surprised we are ready to relax this and lower the bar
IMO it is a control plane role to at least detect such inconsistency.
On Fri, Jul 30, 2021 at 11:11 PM Tony Li wrote:
>
> Les,
>
>
> [LES:] Node R1 uses metric-type A for Application X and metric type B for
> Application Y.
> Node R2 uses metric-type B for Application X and metric type A for
>
But isn't this exactly where you would either start copying same data N
times if more then one app want to include given metric in its topo
computation ?
Or alternatively we would quickly get into mess of overlapping pools of
metrics used by app A and app B but not app C. I don't think
Hi Tony,
Why do we need separate and different copies of attributes for different
> applications?
>
Don't we have a bit mask as defined in ASLA RFCs (for example in section
4.1 rfc8919) to indicate in which app given metric should be used ? I am
a bit puzzled why would we ever send copies of
cifies which metric-type it is going to
> use.
>
>
>
>
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk
> *Sent:* Friday, July 30, 2021 6:20 PM
> *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) <
> gunt
Hey Gunter,
> It doesn’t make sense to have Application specific values if a particular
metric is obtained only dynamically,
It sure does.
Please notice what ASLA RFCs say up front in the abstract. ASLA is useful
for:
A) application- specific values for a given attribute
AND
B) indication of
Hi Ron,
I think you are not taking into consideration the full picture here and
instead you are only focusing only on signaling.
So let's take your example of "link's total physical bandwidth" Yes physics
wise it is generic, by nature.
And that claim is true too: "It will always be the same for
Hi Shraddha,
> 3.Advertising generic metric in an application independent manner in
> legacy TLV 22 and ELO LSA
> does not violate RFC 8919/8920. Application-independent attributes are not
> expected to use RFC 8919/8920
> mechanisms. Generic metric is like igp cost. IGP-cost is never advertised
>
>
>
> *From:* Robert Raszuk [mailto:rob...@raszuk.net]
> *Sent:* Friday, June 4, 2021 3:35 PM
> *To:* DECRAENE Bruno INNOV/NET
> *Cc:* draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org
> *Subject:* Re: [Lsr] draft-ietf-lsr-flex-algo
>
>
>
>
>
> Ok you meant
So context of "permitted" is not in the sense use or not use ASLA, but
in the sense when both use zero length or none zero length app id is
present.
Thx
On Fri, Jun 4, 2021 at 2:56 PM wrote:
> Hi Robert,
>
>
>
> *From:* Robert Raszuk [mailto:rob...@raszuk.net]
>
>
Hi Bruno,
> I think it’s self-evident that we would end up with a permanent routing
loop.
Is that so ? Wouldn't it just result in unidirectional link for a given app
? Maybe intentional ?
It seems that what you described may cause asymmetric routing but not a
routing loop. After all packets
Hi,
I support WG adoption of this draft.
It seems clear to me that protection for any constrained topology should
use/prefer same constrains if available (with possible fallback to base if
operator wishes so).
Flexible algorithm based topologies should be no exception to this.
And as a side
Support.
Happy to see LSR thinking ahead.
Wish IDR would do the same in respect to minimise the impact of non routing
stuff with "Transport Instance BGP" draft I proposed 10+ years back ... :(
https://tools.ietf.org/html/draft-raszuk-ti-bgp-01
Best,
R.
On Sun, May 2, 2021 at 11:19 PM Les
ink it is the other way round – they look at drafts/RFCs and
> only look at registries when the document points to them.
>
>
>
> Les
>
>
>
>
>
> *From:* Robert Raszuk
> *Sent:* Tuesday, March 16, 2021 4:46 PM
> *To:* Les Ginsberg (ginsberg)
> *C
Hi Les,
I would like to share my personal experience that when debugging network
issues say using wireshark or tcpdump often dissectors only decode what is
in IANA registry. Anything beyond they print as hex.
Sure if someone needs to decode it he or she will find an RFC where all
fields are
like building a tower from the cards ... the higher you
>> go the more likely your entire tower is to collapse.
>>
>> Cheers,
>> R.
>>
>> PS.
>>
>> > with MPLS loopback address of all PEs is advertised everywhere.
>>
>> Is this a feature or a
1 at 9:10 AM Peter Psenak wrote:
> Robert,
>
>
> On 09/03/2021 19:30, Robert Raszuk wrote:
> > Hi Peter,
> >
> > > Example 1:
> > >
> > > If session to PE1 goes down, withdraw all RDs received from such
> PE.
> >
> &g
301 - 400 of 557 matches
Mail list logo
