Robert,
On 21/03/2024 20:52, Robert Raszuk wrote:
Peter,
Ok I think what you are proposing is pretty granular and that is fine.
We may still disagree if link should be used at all if there are
errors on this link in *ANY* direction.
So my suggestion here is to have that support build in as
Hi Jie
I thought about this and how applying your L2 member link extension to SR
algo would work and would it be feasible or not.
I believe subinterface would work since each subinterface has an L3 logical
IP on it so could map multiple NRPs to multiple L3 sub interfaces and that
would work as
Hi Bruno,
Please check inline below with KT3.
On Thu, Mar 21, 2024 at 11:28 PM wrote:
> Hi Ketan,
>
>
>
> Please see inline [Bruno2]
>
>
>
> *From:* Ketan Talaulikar
> *Sent:* Thursday, March 21, 2024 4:19 PM
> *To:* DECRAENE Bruno INNOV/NET
> *Cc:* Acee Lindem ; lsr ;
>
Hi Les,
Ack - we will fix that text.
Thanks,
Ketan
On Fri, Mar 22, 2024 at 12:17 AM Les Ginsberg (ginsberg)
wrote:
> I support adoption of this draft.
> Knowledge of whether a given prefix is Anycast has proven useful in
> existing deployments - closing this gap for OSPFv2 is a good thing to
Hi Peter,
Please see inline:
From: Peter Psenak
Sent: Thursday, March 21, 2024 7:39 PM
To: Dongjie (Jimmy) ; Les Ginsberg
(ginsberg) ; lsr@ietf.org;
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org
Subject: Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07
Hi Jie,
On 21/03/2024
Peter,
Ok I think what you are proposing is pretty granular and that is fine. We
may still disagree if link should be used at all if there are errors on
this link in *ANY* direction.
So my suggestion here is to have that support build in as well in the nodes
computing the topology and not always
I support adoption of this draft.
Knowledge of whether a given prefix is Anycast has proven useful in existing
deployments - closing this gap for OSPFv2 is a good thing to do.
One editorial comment. The introduction (and abstract) states:
" Both SR-MPLS prefix-SID and IPv4 prefix may be
Hi Ketan,
Please see inline [Bruno2]
From: Ketan Talaulikar
Sent: Thursday, March 21, 2024 4:19 PM
To: DECRAENE Bruno INNOV/NET
Cc: Acee Lindem ; lsr ;
draft-chen-lsr-anycast-f...@ietf.org; Dongjie (Jimmy) ;
Tony Przygienda
Subject: Re: [Lsr] Working Group Adoption Poll for "Updates to
Hi Robert,
On 21/03/2024 18:26, Robert Raszuk wrote:
Hey Peter,
Why do we need the notion of "reverse direction" to be any
different then
the notion of forward direction from node B to A on a link ?
For a link A->B, we typically use attributes in the direction
A->B.
Hey Peter,
> Why do we need the notion of "reverse direction" to be any different then
> the notion of forward direction from node B to A on a link ?
>
> For a link A->B, we typically use attributes in the direction A->B. .e.g.
> link delay, link affinities, etc.
>
> The reason why we want to be
Hi Robert,
One quick response inline below with KT.
On Thu, Mar 21, 2024 at 10:37 PM Robert Raszuk wrote:
> Hi Ketan,
>
> That is my main point. So we define something which is only local to the
> area.
>
> If this information will turn out to be very useful I am sure there is
> going to be
Robert,
On 21/03/2024 17:52, Robert Raszuk wrote:
Hi,
> When Flex-Algorithm calculation processes the link A to B, it may
look at
> the 'colors' of the link in the reverse direction, e.g., link B to
A. This would
> allow the operator to exclude such link from the Flex-Algorithm
topology.
Hi Ketan,
That is my main point. So we define something which is only local to the
area.
If this information will turn out to be very useful I am sure there is
going to be someone proposing to leak it :) Remember the UPA discussions ?
If so my real question is - should such information belong
Hi,
> When Flex-Algorithm calculation processes the link A to B, it may look at
> the 'colors' of the link in the reverse direction, e.g., link B to A.
This would
> allow the operator to exclude such link from the Flex-Algorithm topology.
Why do we need the notion of "reverse direction" to be
Hi Robert,
Summarization/aggregation does result in loss of individual prefixes'
attributes.
The draft does not intend to specify procedures for propagation of anycast
attribute of individual prefixes to the summary since that is not something
that is going to be robust.
Thanks,
Ketan
On Thu,
Hi All,
I have reviewed this document and believe it needs some further work before
publication.
I am sharing my comments below:
1) There is the following text in sec 2.1 and 2.2 for Generic Metric.
A metric value of 0xFF is considered as maximum link metric and a link
having this metric
Hi,
Isn't this knowledge gone outside of the local area when ABR does
summarization ? If so, is this really practically useful ?
Thx,
R.
On Thu, Mar 21, 2024 at 4:19 PM Ketan Talaulikar
wrote:
> Hi Bruno,
>
> Please check inline below with KT2 for responses.
>
>
> On Thu, Mar 21, 2024 at
Hi Bruno,
Please check inline below with KT2 for responses.
On Thu, Mar 21, 2024 at 7:16 PM wrote:
> Hi Ketan,
>
>
>
> Thanks for your quick reply.
>
> Please see inline [Bruno]
>
>
>
> *From:* Ketan Talaulikar
> *Sent:* Thursday, March 21, 2024 2:18 PM
> *To:* DECRAENE Bruno INNOV/NET
>
I can only say, `spot on, Bruno` ...
a spec in IGP is not (not even experimental AFAIS) "hey, let's quickly call
something 'anycast' and put a flag into encoding and then kind of figure
out what it really means", especially for such a massive concept as
"anycast" that will be coming up over years
Hi Ketan,
Thanks for your quick reply.
Please see inline [Bruno]
From: Ketan Talaulikar
Sent: Thursday, March 21, 2024 2:18 PM
To: DECRAENE Bruno INNOV/NET
Cc: Acee Lindem ; lsr ;
draft-chen-lsr-anycast-f...@ietf.org; Dongjie (Jimmy) ;
Tony Przygienda
Subject: Re: [Lsr] Working Group
Hi Bruno,
Thanks for your feedback. Please check inline below for responses.
On Thu, Mar 21, 2024 at 4:12 PM wrote:
> Hi all,
>
>
>
> I would also welcome a clear specification of the semantics.
>
> Such that the meaning and implications are clear on both the originator
> and the
Hi all,
I would also welcome a clear specification of the semantics.
Such that the meaning and implications are clear on both the originator and the
receivers/consumers.
e.g., from the originator standpoint:
- The originator MAY advertise the Anycast Flag if CONDITIONS1 are met (which
allow
Hi Chairs, WG,
I have relearned this document, and there are some non-blocking comments:
[1]
For Interface Group Mode of automatic metric calculation, it may biases the
utilization rate of each link of the parallel link-set.
Although the document give an example (figure 7) to explain why this
Hi Jie,
On 21/03/2024 02:34, Dongjie (Jimmy) wrote:
Hi Les,
Thanks for providing your opinion with an example.
In your example, the default IGP metric is used, which is normally
calculated based on bandwidth. While Flex-Algo can support metric
types such as TE metric and delay.
When
Tony,
On 20/03/2024 18:51, Tony Przygienda wrote:
hmm, Peter, thanks for clarification but wasn't A the attach flag is
OSPF in 7684?
yes, here we define AC-flag.
In ISIS it's in the SR support draft and hence I would ask here as
well to somehow clarify that "this is for SR purposes"
25 matches
Mail list logo
