Hi Peter,
> > Example 1:
> >
> > If session to PE1 goes down, withdraw all RDs received from such PE.
>
> still dependent on RDs and BGP specific.
To me this does sound like a feature ... to you I think it was rather
pejorative.
> We want app independent way of
> signaling the reachability
still signal summary no issue as no inet.3
route.
Best,
R.
On Tue, Mar 9, 2021 at 12:12 PM Peter Psenak wrote:
> Hi Robert,
>
> On 09/03/2021 12:02, Robert Raszuk wrote:
> > Hey Peter,
> >
> > Well ok so let's forget about LDP - cool !
> >
> > So IGP
3/2021 11:47, Robert Raszuk wrote:
> > > You’re trying to fix a problem in the overlay by morphing the
> > underlay. How can that seem like a good idea?
> >
> > I think this really nails this discussion.
> >
> > We have discussed this before and while the
> You’re trying to fix a problem in the overlay by morphing the underlay.
How can that seem like a good idea?
I think this really nails this discussion.
We have discussed this before and while the concept of signalling
unreachability does seem useful such signalling should be done where it
Hello,
I agree with Les that this draft may not be a fit for LSR WG.
Typically this type of effort (essentially describing use cases) is much
better to be put in slides and present on various operators forums.
That said I think perhaps we are indeed missing LROW WG (Local Routing
Operations WG)
ore
often then M ms
Care to share that with the group ?
Thx,
R.
On Thu, Mar 4, 2021 at 2:30 PM Peter Psenak wrote:
> On 04/03/2021 14:28, Robert Raszuk wrote:
> > > Is it minimum ever, is it min of the year, month, week, day ...
> etc
> >
> > https://tools.iet
> > Is it minimum ever, is it min of the year, month, week, day ... etc
>
> https://tools.ietf.org/html/rfc8570#section-4.2
>
> Peter
>
Maybe it is just me but in section 4.2 I see NOTHING about how often that
delay should be measured which was the point above.
Thx,
R.
wrote:
> On 04/03/2021 11:52, Robert Raszuk wrote:
> > I guess now you are not listening ;)
> >
> > I am saying it is about finding the right normalization timers and
> > values which can satisfy the need. And those should reside on the
> senders.
>
> that's
it as static approximated link delay.
Thx
R.
On Thu, Mar 4, 2021, 11:06 Peter Psenak wrote:
> Robert,
>
> On 04/03/2021 10:50, Robert Raszuk wrote:
> > Peter,
> >
> > Sorry but the draft does not have a disclaimer section which states:
> >
> > "
s of ms. And IMO the proposal on
the table is specifically designed to catch and address those cases - not
just dismiss it as you can not use it in your network - sorry mr customer.
Best,
R.
On Thu, Mar 4, 2021 at 10:41 AM Peter Psenak wrote:
> Robert,
>
> On 04/03/2021 10:23, Rober
, 2021 at 10:07 AM Peter Psenak wrote:
> Robert,
>
> On 03/03/2021 20:57, Robert Raszuk wrote:
> > Peter,
> >
> > > that differ by few microsecond
> >
> > Really you normalize only single digit microseconds ???
> >
> > What if link delay changes
ew of the network may quickly become stale. However, IMO,
> any per-path e2e SLA need to be validated (independent of the network
> topology) e.g., by active measurement using probes or other means.
>
>
>
> My 2cents.
>
>
>
> Regards,
>
> Tarek
>
>
>
> O
Peter,
> that differ by few microsecond
Really you normalize only single digit microseconds ???
What if link delay changes in milliseconds scale ? Do you want to compute
new topology every few milliseconds ?
Out of curiosity as this is not a secret - What are your default min delay
Hi Peter,
> I was talking about requirements of generation and flooding of min
> > delay for the needs of this new constrain.
>
> yes, but the min delay is already being used by flex-algo as one of the
> possible metrics, so noting new is required.
>
I think it depends on one's use case.
The
gt;
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk
> *Sent:* Wednesday, March 3, 2021 4:12 PM
> *To:* Peter Psenak
> *Cc:* Tony Li ; Gyan Mishra ;
> DECRAENE Bruno IMT/OLN ; Shraddha Hegde <
&g
Not sure what's the difference between the two.
But I guess let't wait for authors to clarify their intentions here.
Cheers,
R.
On Wed, Mar 3, 2021, 11:47 Peter Psenak wrote:
> Robert,
>
> On 03/03/2021 11:41, Robert Raszuk wrote:
> >
> > Sorry but to me the draft is ve
and advertised in delay metric in IGP. For usecases that deploy low
latency flex-algo, may want to exclude links that have delay more
than a defined threshold.
Thx,
R.
On Wed, Mar 3, 2021 at 11:31 AM Peter Psenak wrote:
> On 03/03/2021 11:27, Robert Raszuk wrote:
> >
> > I am not sur
imum value of minimum value
?
Thx,
R.
On Wed, Mar 3, 2021 at 11:22 AM Peter Psenak wrote:
> Robert,
>
> On 03/03/2021 11:10, Robert Raszuk wrote:
> > Hey Peter,
> >
> > > Authors stated: "Whether egress queueing delay is included in the
> > link
Hey Peter,
> > Authors stated: "Whether egress queueing delay is included in the link
> > delay depends on the measuring mechanism."
>
> I disagree with that statement - the Min Unidirectional Link Delay is
> the value that does not include the queueing delay - that's why it is
> called Min.
Hi Peter,
To your last point ...
Authors stated: "Whether egress queueing delay is included in the link
delay depends on the measuring mechanism."
So sure there will be thresholds etc ... but this may very well depend on
the traffic.
Thx,
R.
On Wed, Mar 3, 2021 at 10:34 AM Peter Psenak
Hey Tony,
I think there are few things to observe here.
1.
It very much depends how one is to use Flex-Algo topologies. If you attempt
to use it as solid fixed topology for some applications I would be very
cautious not to create such topology with dynamic constraints. Not only
worrying about
metric-types for SPF. We are trying introduce the protocol
> constructs to simplify the use of metric based on bandwidth via Flex-Algo.
>
> This draft does not attempt to do bandwidth management nor reservation
> like what RSVP does. For LDP based networks that use igp metric relative to
&
meant for
> pruning out high latency links from a Flex-Algo, and it is upto the
> operator to define the maximum bounds based on the measuring mechanisms
> deployed in his network.
>
>
>
> Thanks,
>
> William
>
>
>
> *From: *Robert Raszuk
> *Date: *Satur
Hi William & co-authors,
I read the draft and have two basic questions.
1.
Both bw & delay can be used as defined in the draft to construct new
forwarding topologies. But how practical such topologies would be in the
real life when 40GB links may be heavily occupied with bursty traffic and
10G
Telecom
>
> On Feb 26, 2021, at 19:00, Robert Raszuk wrote:
>
>
> Hi Yali,
>
>
>> If this was precise, then the existing multi-instance mechanism would be
>> sufficient.
>> [Yali]: MFI is a different solution we recommend to solve this same and
>> valuable
Hi Yali,
> If this was precise, then the existing multi-instance mechanism would be
> sufficient.
> [Yali]: MFI is a different solution we recommend to solve this same and
> valuable issue.
>
Well the way I understand this proposal MFI is much weaker solution in
terms of required separation.
> This is true, btw, of the centralized flood reduction mechanisms I've
seen,
Really ?
My understanding it that only LSP originator limits the flooding scope
based on the optimized topology reception (or in distributed case local
computation) not any via node.
Cheers,
R.
On Sat, Jan 9, 2021
Support.
R.
On Tue, Jan 5, 2021 at 10:17 AM Christian Hopps wrote:
> This begins a 2 week WG adoption call for the following draft:
>
> https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-admin-tags/
>
> Please indicate your support or objection by January 19th, 2021.
>
> Authors, please
Hi Jie,
> But if node A sends SRv6 packets with node C's SRv6 SID in FA 128 as the
> destination address, when the packet arrives at E, it will be dropped,
> because node E does not have the forwarding entry for C's SRv6 SID in FA
> 128.
* How can E be on the SRv6 SID list if it did not
Hi,
Adjusting subject to reflect topic.
Wow .. I did not think this will start such a debate :)
To me this is actually very simple. Flex Algo is still IMO an SPF with
additional two new factors:
* You have ability to exclude links or nodes from your computation
* You run traditional SPF based
Hi,
I support adoption of this draft.
However I really do not think that what Flexible Algorithm offers can be
compared or even called as Traffic Engineering (MPLS or SR).
Sure Flex Algo can accomplish in a very elegant way with little cost multi
topology routing but this is not full TE. It can
Alex,
I believe the text in section 2.7 talks about Router LSA advertisements
which contains both local information as well as information describing
each formed adjacency with each neighbour. The RFC just talks about the new
added part.
Thx,
R.
On Thu, Nov 26, 2020 at 5:58 PM Alexander
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
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
>>
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>
> *Da
e 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
>
;
>>> 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.
>>>
>>>
>>>
>>> Thank
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
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
> 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
>
> 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
>
ir - 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 wr
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
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
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
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
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
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
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
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
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 d
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
ot 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:* Le
g 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
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
>
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 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
> 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:
> 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
>
> [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
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
plified. 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 (ace
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
Delay |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>
>
> my ability to see your POV is somewhat limited.
>
>
>
> Perhaps you could own that a more careful reading is possible?
>
>
>
>Les
>
>
cument. 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
>
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
e 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 i
ert –
>
>
>
> 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 Gin
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
*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)
>
> [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
-
> 胡志波 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>
> *时 间：*202
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
&g
> > 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.
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 <
> huz
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
, 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 wo
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
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
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
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
ciency 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.
>
>
> &
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
>
> > 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,
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
> 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
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
der 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
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).
>
>
>
>
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
> 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,
> > &g
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
e 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 :)
>>
>
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:
>>
>>&g
l 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:
> >
> > >
, 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 Ho
> > 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
, 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.
ght 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 ;-
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
401 - 500 of 557 matches
Mail list logo
