Hi, Tony:
Aijun Wang
China Telecom
> On Mar 9, 2021, at 12:32, Tony Li wrote:
>
>
> Hi Aijun,
>
>> Stuffing things in the IGP seems like a poor way of determining that there’s
>> a BGP failure. Wouldn’t BFD be a more appropriate way of determining the
>> loss of connectivity? Or
Linda and authors
Some thoughts regarding load balancing draft.
Anycast in my experience has been used predominantly in my experience
within operators networks with BGP overlay, using BGP best path selection
and most cases boils down to lowest IGP metric tie breaker shortest path
for the
Hi Tony,
On Mon, Mar 8, 2021 at 11:39 PM Tony Li wrote:
>
> Hi Gyan,
>
> > Gyan> In previous threads BFD multi hop has been mentioned to track
> IGP liveliness but that gets way overly complicated especially with large
> domains and not viable.
>
>
> This is not tracking IGP liveness, this
Hi Gyan,
> Gyan> In previous threads BFD multi hop has been mentioned to track IGP
> liveliness but that gets way overly complicated especially with large domains
> and not viable.
This is not tracking IGP liveness, this is to track BGP endpoint liveness.
Here in 2021, we seem to have
Hi,
Sorry to chime in.
There are certainly some higher layer application/protocols to employ. At the
same time, there are some advantages of network layer approaches as well in my
mind.
When talking about edge computing, there are some unique characteristics. The
number of edge sites could
Hi Aijun,
> Stuffing things in the IGP seems like a poor way of determining that there’s
> a BGP failure. Wouldn’t BFD be a more appropriate way of determining the
> loss of connectivity? Or aggressive BGP keepalive timers?
> [WAJ] For BFD, you need to configure between each pair of them to
Hi Tony
Thank your for your comments.
Responses in-line
Kind Regards
On Mon, Mar 8, 2021 at 11:06 PM Aijun Wang
wrote:
> Hi, Tony:
>
> -Original Message-
> From: lsr-boun...@ietf.org On Behalf Of Tony Li
> Sent: Tuesday, March 9, 2021 11:12 AM
> To: Aijun Wang
> Cc: lsr ;
Hi, Tony:
-Original Message-
From: lsr-boun...@ietf.org On Behalf Of Tony Li
Sent: Tuesday, March 9, 2021 11:12 AM
To: Aijun Wang
Cc: lsr ; draft-wang-lsr-prefix-unreachable-annoucement
; Acee Lindem (acee)
; Aijun Wang ; Gyan Mishra
Subject: Re: [Lsr]
Hi, Acee:
From: lsr-boun...@ietf.org On Behalf Of Acee Lindem
(acee)
Sent: Tuesday, March 9, 2021 4:12 AM
To: draft-dunbar-lsr-5g-edge-compute-ospf-...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] Comments on draft-dunbar-lsr-5g-edge-compute-ospf-ext-03
Speaking as WG member:
Hi Linda
Hi Abhinay,
OSPFv3 authentication trailer RFC (RFC7166) is newer RFC than OSPFv2 HMAC
authentication (RFC5709), and
in RFC 7166, in section 1.2. Summary of Changes from RFC 6506 ,
2. Section 3 previously recommended usage of an expired key for
transmitted OSPFv3 packets when no valid
Sooo, I have been reluctant to comment on the shortcomings of this draft
because I feel there was no need for the draft to be written in the first place.
I had hoped that the authors would think about this a bit more and realize the
flaws in the proposed solution – or – as Acee suggested during
Hi Aijun,
> [WAJ] We just want to avoid such silent discard behavior, especially for the
> scenario that there is BGP session run on such failure prefix.
Stuffing things in the IGP seems like a poor way of determining that there’s a
BGP failure. Wouldn’t BFD be a more appropriate way of
Hi Jie,
Now that you mention VTN-ID, I have to point out that the VTN-ID in
draft-dong-lsr-sr-for-enhanced-vpn is actually the AII in
draft-peng-teas-network-slicing, just a new name. That can be seen from the
evolution of the historical versions of the these two drafts.
See
Hi, Acee:
Let me state my considerations for your questions.
Aijun Wang
China Telecom
> On Mar 9, 2021, at 08:37, Acee Lindem (acee) wrote:
>
>
> Speaking as a WG member:
>
> Hi Gyan,
>
> The first question is how do you know which prefixes within the summary range
> to protect? Are
On Mon, Mar 8, 2021 at 7:37 PM Acee Lindem (acee) wrote:
> Speaking as a WG member:
>
>
>
> Hi Gyan,
>
>
>
> The first question is how do you know which prefixes within the summary
> range to protect? Are these configured? Is this half-assed best-effort
> protection where you protect prefixes
> On Mar 8, 2021, at 7:40 PM, Linda Dunbar wrote:
>
> Christian,
>
> You said at LSR session today that there might be concern of network
> optimizing ANYCAST traffic to better balance among multiple App Layer Load
> Balancers.
> First of all, only the Applications that need to leverage the
Hi, Tony:
Aijun Wang
China Telecom
> On Mar 9, 2021, at 08:22, Tony Li wrote:
>
>
> Hi Aijun,
>>
>> There are two scenarios as introduced by Gyan: one is the node
>> failure(Scenario 1), and another is the link failure(Scenario 2).
>>
>> For scenario 1, also when all ABRs can’t reach the
Hi Tony
On Mon, Mar 8, 2021 at 7:22 PM Tony Li wrote:
>
> Hi Aijun,
> >
> > There are two scenarios as introduced by Gyan: one is the node
> failure(Scenario 1), and another is the link failure(Scenario 2).
> >
> > For scenario 1, also when all ABRs can’t reach the specified address, it
> is
Christian,
You said at LSR session today that there might be concern of network optimizing
ANYCAST traffic to better balance among multiple App Layer Load Balancers.
First of all, only the Applications that need to leverage the network condition
to balance among their multiple Load Balancers
Speaking as a WG member:
Hi Gyan,
The first question is how do you know which prefixes within the summary range
to protect? Are these configured? Is this half-assed best-effort protection
where you protect prefixes within the range that you’ve installed recently?
Just how does this work? It
Hi Aijun,
>
> There are two scenarios as introduced by Gyan: one is the node
> failure(Scenario 1), and another is the link failure(Scenario 2).
>
> For scenario 1, also when all ABRs can’t reach the specified address, it is
> not efficient to advertise all of other detail prefixes when only
Hi, Tony:
There are two scenarios as introduced by Gyan: one is the node failure(Scenario
1), and another is the link failure(Scenario 2).
For scenario 1, also when all ABRs can’t reach the specified address, it is not
efficient to advertise all of other detail prefixes when only one prefix or
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 the more specific. This will attract the
Acee.
Please ask the two questions you raised about the PUA draft so we can
address your concerns.
If anyone else has any other outstanding questions or concerns we would
like to address as well and resolve.
Once all questions and concerns are satisfied we would like to ask for WG
adoption.
The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'OSPF Prefix Originator Extensions'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive
On March 8, 2021 at 12:35:52 PM, Ketan Talaulikar (ketant) wrote:
Ketan:
Hi!
I have a couple of comments below, which I think can be handled with
other last-call comments. I'm starting the IETF LC.
Thanks!!
Alvaro.
...
> 127 2. Protocol Extensions
>
> 129 This document defines the
Dear Authors,
Just want to quickly clarify my comment today on this draft.
We know there was a significant discussion many years ago when similar work
was done during RFC 6822 (ISIS-MI) and RFC 6823 (GenInfo). The usefulness
of this is evident with the more recent publication
Speaking as WG member:
Hi Linda and Co-authors,
My first major comment is the confusion with the usage of multiple anycast
addresses for the same application. Why are you requiring multiple anycast
address? It would seem the load balancing over multiple servers can be done at
the data center
Hi Alvaro,
Thanks for your detail review and comments. We've update the draft to address
your comments and the version 8 posted below.
https://www.ietf.org/archive/id/draft-ietf-lsr-ospf-prefix-originator-08.txt
Please check inline below for responses.
Thanks,
Ketan
-邮件原件-
发件人:
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 : OSPF Prefix Originator Extensions
Authors : Aijun Wang
Acee Lindem
Hi Tarek,
The draft draft-dong-teas-enhanced-vpn-vtn-scalability describes the more
scalable solutions for network slicing. It is apparent that it has to introduce
the new encapsulation using MPLS and/or IPv6 as the data plane which propose
challenges for the hardware implementation. It has
Hi Tarek,
Your understanding about the scalability implication of this MT based VTN
mechanism is correct, this is also described in section “scalability
considerations” of this draft. The value of this mechanism is that it reuses
several existing TLVs together to provide the required function.
Hi Tony,
Just so we are on same page, I think you are agreeing on the overhead per MT
(and even MI) that would be incurred using the approach proposed in I-D.
draft-xie-lsr-isis-sr-vtn-mt to realize a forwarding treatment on a shared
resource.
To you’re point on flex-algo producing
This argument seems fairly bogus to me. if you use IGP to flood some stuff
and then want the distributed computation stitch it together based on IGP
topology to get you a nexthop you end in computation which is something
like Bellman or Dijkstra or Boruvka. Unless you have some controller
Hi Jie
Response in-line
Thank you
Gyan
On Mon, Mar 8, 2021 at 9:11 AM Dongjie (Jimmy) wrote:
> Hi Gyan,
>
>
>
> Thanks for your comments.
>
>
>
> As you mentioned, both MT and MI can provide separate topologies and the
> topology based computation, and MI can provide separate LSDBs at some
>
Hi authors,
My understanding is the draft is proposing a separate MT topology (unique
MT-ID) to identify a forwarding treatment to be enforced on a shared resource.
While this may work for limited number of MT topologies (i.e. forwarding
treatments), as described in RF5120 there is overhead
Hi Gyan,
Thanks for your comments.
As you mentioned, both MT and MI can provide separate topologies and the
topology based computation, and MI can provide separate LSDBs at some
additional cost (separate adjacencies, etc.). In this document, the resource of
VTN mainly refers to the forwarding
Hi All,
Thanks for your valuable comments and feedback. We have tried to address most
of them in the new version which has been uploaded now.
https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-01
Thanks,
William
From: Tony Li on behalf of Tony Li
Date: Friday, 5 March
Hi Veeru,
Is there a need to have the same behaviour? When we had to
implement it I remember we followed rule 1 for OSPFv3, but we
triggered a trap message before doing so.
Thanks & Regards,
Abhinay R
On Mon, Mar 8, 2021 at 9:00 AM Veerendranatha Reddy V
wrote:
>
> Hi All,
>
> As per
39 matches
Mail list logo
