Dear authors,
here are couple of comments to draft-peng-lsr-flex-algo-l2bundles:
1. Flex-algo specification as specified in draft-ietf-lsr-flex-algo only
uses L3 link information for path computation. This is consistent with
the regular Algo 0 path computation. My preference would be to keep
> In addition you may have a hierarchical RR, which would still involve
> BGP signalling.
Last time I measured time it takes to propage withdraw via good RR was
single milliseconds.
> because BGP signalling is prefix based and as a result slow.
+
> that is the whole point, you need something
Dear authors,
here are couple of comments to draft-zhu-lsr-isis-sr-vtn-flexalgo:
1. whether we want to flood VTN specific link data in IGPs or not is
something that deserves its own discussion.
2. Nevertheless, the proposed encoding does not seem to be a fortunate one:
a) it hijacks the L2
Gyan, you are confusing RIB with LSDB. It is absolutely feasible and normal
to generate multiple RIBs/FIBs from a single LSDB and that has been done
for about forever
problem with lots of those proposals and assertions here is that powerpoint
and rfc text always compiles no matter what you put
Hi Robert,
On 09/03/2021 12:02, Robert Raszuk wrote:
Hey Peter,
Well ok so let's forget about LDP - cool !
So IGP sends summary around and that is all what is needed.
So the question why not propage information that PE went down in service
signalling - today mainly BGP.
because BGP
I know it's not fashionable (yet) but put multipoint BFD on BIER & run 2
subdomains and you got 10K. Add subdomains to taste which will also allow
to partition it across chips easily. Yepp, needs silicon that will sustain
reasonable rates but you have a pretty good darn' solution. IGP gives you
Christian,
If “network fails”, the packets won’t even get into the desired App Server (or
App Layer Load Balancer).
What the draft has proposed is to add a “Tie breaker” or additional weight to
the “Best Path” selection by BGP/IGP.
There is definitely interaction among the Application
Tony,
On 09/03/2021 01:03, Tony Li wrote:
Gyan,
If I understand the purpose of this draft, the point is to punch a hole
in a summary so that traffic is redirected via an alternate, working path.
Rather than punch a hole, why not rely on existing technology? Have the
valid path advertise
Hi Jie and all,
I'm sorry to have digressed in the adoption on this informational
draft-xie-lsr-isis-sr-vtn-mt-03. However, I think these enhanced-vpn related
documents are closely related, although they are divided into multiple
documents. So discussing the main document
Robert,
On 09/03/2021 12:20, Robert Raszuk wrote:
> In addition you may have a hierarchical RR, which would still involve
> BGP signalling.
Last time I measured time it takes to propage withdraw via good RR was
single milliseconds.
> because BGP signalling is prefix based and as a
Hi All,
I support the adoption of this document. It provides an useful mechanism to
build SR based VTNs using existing IS-IS Multi-Topology instances to provide
the network resources for each VTN.
Regards,
Giuseppe
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent:
Hey Peter,
Well ok so let's forget about LDP - cool !
So IGP sends summary around and that is all what is needed.
So the question why not propage information that PE went down in service
signalling - today mainly BGP.
> And forget BFD, does not scale with 10k PEs.
You missed the point. No
Hi,
Since this discussion is not related to the adoption poll for
draft-xie-lsr-isis-sr-vtn-mt, please start a separate mail thread if you want
to discuss other documents.
A brief reply:
In the current version or any previous version of
draft-peng-teas-network-slicing, there is no
Hi, all
This draft describes the IGP control plane mechanism with necessary extensions
to build SR based VTNs. It is useful. I support the adoption of this document.
Best regards，
Cong Li
发件人： Acee Lindem (acee)
发送时间： 2021-03-03 07:27
收件人： lsr@ietf.org
主题： [Lsr]WG Adoption Poll for “Using
Thanks Tony for the clarification on MI versus MT. Peter set me straight
as well on the difference. There are use cases for either one and in this
particular case for VTN underpinning it makes sense as the authors pointed
out that the forwarding plane resources is what needs to be constrained &
Tony,
In-line
On Tue, Mar 9, 2021 at 5:55 AM Tony Przygienda wrote:
> and replying to myself, as was mentioned yesterday in LSR already, the key
> questions is HOW MANY control plane slices and then FIB slices do you
> really need in the technology to be built. And how much of that needs to
>
Hi Alvaro,
Please check inline below with [KT2]
I will wait for your responses on a few of the points before posting the draft
update.
-Original Message-
From: Alvaro Retana
Sent: 09 March 2021 02:57
To: Ketan Talaulikar (ketant) ;
draft-ietf-lsr-ospf-prefix-origina...@ietf.org
Cc:
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
Gyan, all good except you find that once you have MFI thought through and
really working (implementations do wonder to understanding) with all kind
of frills like Les pointed out you'll build MT by another name again most
likely AFAIS.
If you want to flood everywhere and have some attribution on
> 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
and replying to myself, as was mentioned yesterday in LSR already, the key
questions is HOW MANY control plane slices and then FIB slices do you
really need in the technology to be built. And how much of that needs to
be really in the core? Both will have large implication on solutions, you
21 matches
Mail list logo
