Hi, Acee:
Regarding to your comments on the meetings that where to put the attributes of
these stub-link attributes, I had reviewed again the previous discussions on
the mail list. Please see it at
https://mailarchive.ietf.org/arch/msg/lsr/LbsiUl9iL_9zTXnxtuAnKVpfmGs/. Then
putting it into
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
WG,
This is proposed text change for flex-algo draft.
Any comments on this?
Rgds
Shraddha
Juniper Business Use Only
-Original Message-
From: Shraddha Hegde
Sent: Wednesday, July 28, 2021 11:47 PM
To: Peter Psenak ; Ron Bonica ; Acee
Lindem (acee) ; Les Ginsberg (ginsberg)
;
Robert,
> IMO it is a control plane role to at least detect such inconsistency.
I understand the desire and I sympathize, but the architecture is not set up
for that. The management plane has the information, the control plane does
not. Detecting inconsistencies would also require that
Hi Acee,
> Speaking as working member:
>
> You've made it abundantly clear that you don't think like the ASLA encoding.
> However, we have standardized the ASLA encoding in the LSR working group -
> this is a done deal. You are free to propose an alternative but you this
> should not be
Hi, Acee:
Thanks for your comments.
Please see the replies inline.
Aijun Wang
China Telecom
> On Jul 31, 2021, at 01:00, Acee Lindem (acee) wrote:
>
>
> Hi Gyan,
>
> See brief inlines.
>
> From: Gyan Mishra
> Date: Thursday, July 29, 2021 at 10:24 PM
> To: Acee Lindem
> Cc:
Tony –
I don’t agree with your argument – but at least we are clear on the point of
disagreement.
I will let the operator community comment on how your approach appeals to them.
Speaking as someone who (like you) gets called in to unravel problems in
customer networks, I sure don’t want to
Speaking as working member:
Hi Tony,
You've made it abundantly clear that you don't think like the ASLA encoding.
However, we have standardized the ASLA encoding in the LSR working group - this
is a done deal. You are free to propose an alternative but you this should not
be done after the
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
>
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
> Application Y.
> Both nodes are advertising both metric-types.
> But neither node is aware of the inconsistency because
Tony -
> -Original Message-
> From: Tony Li On Behalf Of Tony Li
> Sent: Friday, July 30, 2021 1:37 PM
> To: Les Ginsberg (ginsberg)
> Cc: Peter Psenak (ppsenak) ; Shraddha Hegde
> ; Robert Raszuk ; Van De
> Velde, Gunter (Nokia - BE/Antwerp) ;
> lsr@ietf.org
> Subject: Re: [Lsr]
Les,
> [LES:] I do not object to the Generic-Metric TLV (I believe I stated that at
> the beginning). I might not have chosen to do it that way myself - but I am
> OK with it.
> But one of the consequences of this choice is that not all metric-types can
> be advertised in this new format.
>
Tony -
Thanx for separating out this thread.
Inline.
> -Original Message-
> From: Tony Li On Behalf Of Tony Li
> Sent: Friday, July 30, 2021 1:25 PM
> To: Les Ginsberg (ginsberg)
> Cc: Peter Psenak (ppsenak) ; Shraddha Hegde
> ; Robert Raszuk ; Van De
> Velde, Gunter (Nokia -
Peter,
> well, not in case where you want a per application granularity of which
> application uses that metric on a particular ink.
If you want per application granularity, then you need to send two TLVs,
regardless of ASLA.
> To do that you need per application/per link signaling.
No,
Les,
> " That does not need to be signaled. Configuration information SHOULD NOT be
> signaled."
>
> Where "that" refers to the mapping of link attributes to an application.
>
> I am saying not advertising this association is an interoperability disaster
> and has been proven to be so -
Tony,
On 30/07/2021 22:29, Tony Li wrote:
Peter,
isn't setting a bit in the existing TLV less overhead compared to sending a
separate TLV if the same metric-type and value happens to be used by multiple
application?
As previously noted, if applications are going to share a metric, then
Peter,
> isn't setting a bit in the existing TLV less overhead compared to sending a
> separate TLV if the same metric-type and value happens to be used by multiple
> application?
As previously noted, if applications are going to share a metric, then there is
no need to send multiple TLVs.
Tony -
I assure you I am not talking about ASLA vs non-ASLA.
I am responding to your statement:
" That does not need to be signaled. Configuration information SHOULD NOT be
signaled."
Where "that" refers to the mapping of link attributes to an application.
I am saying not advertising this
Hi Les,
> [LES:] So you are proposing that all metrics - now and in the future - be
> restricted to Generic-Metric format?
Of course not. We are simply trying to generalize. As you note, we already
have three different metric types floating around. Bandwidth would make 4.
With FA, we
Tony,
On 30/07/2021 22:08, Tony Li wrote:
Les,
That does not need to be signaled. Configuration information SHOULD NOT
be signaled. Yes, I realize that there is a great deal of precedent. No, I don’t
agree with it. It’s a lot of unnecessary development overhead.
[LES:] You are taking us
Les,
>> That does not need to be signaled. Configuration information SHOULD NOT
>> be signaled. Yes, I realize that there is a great deal of precedent. No, I
>> don’t
>> agree with it. It’s a lot of unnecessary development overhead.
>>
>>
> [LES:] You are taking us back 20 years in time and
Tony,
On 30/07/2021 18:54, Tony Li wrote:
imagine you have an application A and B and a link X. You advertise application
independent metric M on that link X because you want application A to use it.
Application B is also enabled to use the metric M, but you do not want
application B to
Shraddha,
On 30/07/2021 18:45, Shraddha Hegde wrote:
Peter,
imagine you have an application A and B and a link X. You advertise application
independent metric M on that link X >because you want application A to use it.
Application B is also enabled to use the metric M, but you do not want
Tony -
> -Original Message-
> From: Tony Li On Behalf Of Tony Li
> Sent: Friday, July 30, 2021 11:25 AM
> To: Les Ginsberg (ginsberg)
> Cc: Peter Psenak (ppsenak) ; Shraddha Hegde
> ; Robert Raszuk ; Van De
> Velde, Gunter (Nokia - BE/Antwerp) ;
> lsr@ietf.org
> Subject: Re: [Lsr]
Les,
>> If you don’t want application B to use metric M, then you create metric N and
>> use that for application B.
>
> [LES:] The issue is...how do I indicate that Metric M is for App A (and NOT
> for App B) and that Metric N is for App B (and not for App A)?
That does not need to be
Dear Diego Lopez, Qin Wu, Dhruv Dhody, Qiufang Ma, Daniel King:
An IPR disclosure that pertains to your Internet-Draft entitled "IGP
extension for PCEP security capability support in the PCE discovery"
(draft-ietf-lsr-pce-discovery-security-support) was submitted to the IETF
Secretariat on
Tony -
> -Original Message-
> From: Tony Li On Behalf Of Tony Li
> Sent: Friday, July 30, 2021 9:55 AM
> To: Peter Psenak (ppsenak)
> Cc: Shraddha Hegde ; Robert Raszuk
> ; Van De Velde, Gunter (Nokia - BE/Antwerp)
> ; Les Ginsberg (ginsberg)
> ; lsr@ietf.org
> Subject: Re: [Lsr]
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
> Can anyone explain how do I map generic metric to selected network
> applications I am to run in the network ?
By manual configuration.
There are 256 generic metrics.
Application A uses metrics 1-10
Application B uses metrics 20-30
Application C uses metrics 100-110
Or any other mapping
> imagine you have an application A and B and a link X. You advertise
> application independent metric M on that link X because you want application
> A to use it.
>
> Application B is also enabled to use the metric M, but you do not want
> application B to use metric M on the link X
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
Shraddha,
Let's zoom on flex-algo for now ...
There are two types of FAD:
Local Flexible Algorithm Definition - Flexible Algorithm Definition
defined locally on the node.
Remote Flexible Algorithm Definition - Flexible Algorithm Definition
received from other nodes via IGP
Robert,
> Can anyone explain how do I map generic metric to selected network
> applications I am to run in the network ?
Which application uses which metric type is defined by the application.
For example in flex-algo FAD defines which metric-type its going to use.
In SR-TE, the constraint list
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
Sharddha,
From my last email in the list, I am also asking the same - can you be specific
about what ASLA doesn't provide ? Maybe you have a point that I don't see.
dan
On 2021-07-30, 3:42 AM, "Lsr on behalf of Peter Psenak" wrote:
Shraddha,
On 30/07/2021 06:53, Shraddha Hegde
Very good point indeed made my Gunter related to a “configured” metric
which would yield applicable specific nature that the link attribute
should be configured inside ASLA, however if dynamic PM measurement based
metric, then the metric would be the same for all applications and in that
case is
Hi,
I share similar opinion with Gunter.
ASLA provides the flexibility to define the set of applications which can use a
specific type of link attribute, it also allows to customize the attribute
value for each application.
As the generic metric mechanism will be used to define different
A little late in the discussion... (PTO events do happen)
a quick opinion on the below discussion on whether Generic metric sub-tlv
should be encoded on a ASLA or not.
For me, it depends on how the metric for the corresponding metric-type is
obtained and if it can be configured (static).
It
Shraddha,
On 30/07/2021 06:53, Shraddha Hegde wrote:
Operators have built their networks with link attributes
being configured and used by any application. For example
igp-metric is used by ISIS, then came LDP that used same igp-metric,
RSVP could also use igp-metric. Then came ISIS-SR and
39 matches
Mail list logo
