Hi Les,
Let39s get back to the simple questions:
1)Do you agree with the issue proposed in the draft?
Similar to the UPA draft,even without protocol extension, a new draft is also
required to illustrate the problem and solution comprehensively.
2)Does the existing solution（maximum link metric）work for OSPF?
In the previous discussion, you replied that you would consult to your
colleagues，Any information?
Best Regards,
Liyan
----邮件原文----发件人："Les Ginsberg (ginsberg)" <ginsb...@cisco.com>收件人：Liyan Gong
<gongli...@chinamobile.com>,lsr <lsr@ietf.org>抄 送: (无)发送时间：2022-08-30
10:58:02主题：RE: Re:Re: [Lsr]
Commentsondraft-gong-lsr-exclusive-link-for-flex-algo
Liyan –
From: Liyan Gong <gongli...@chinamobile.com> Sent: Monday, August 29, 2022 7:30
PM To: lsr <lsr@ietf.org> Les Ginsberg (ginsberg) <ginsb...@cisco.com> Subject:
Re:Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo
Hi Les,
About your comments, My opinion is as below:
1）It does not change the base spf in order to support flex-algo, but avoid
changes to base spf when flex-algo is deployed.
[LES:] I do not care “why” you are changing the base SPF – it the fact that you
are changing it at all that I find objectionable.
2）Do you mean that one flex-algo should be associated with an MT? If so, Is it
too complicated?
Deploying both flex-algo and MT at the same time will bring a lot of burden
to IGP protocol.
[LES:] I never mentioned “MT”.
When I used the word “topology” I was referring to the set of nodes/links used
by a particular flex-algorithm. A better terminology would be “constrained
topology”.
I suggest you read
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-20 and see how
the word topology is used there.
We still believe it is very necessary to find a suitable solution for the
problem.
According to the previous discussion, the key point is the backward
compatibility.
[LES:] No – the key point is that what you are doing is completely unnecessary.
The problem you are trying to address has already been solved.
Les
It has been addressed in the new version using the existing mechanism which is
consistent with RFC8042.
Please refer to the latest version:
https://datatracker.ietf.org/doc/draft-gong-lsr-exclusive-link-for-flex-algo/
Further comments are welcome. Thanks again.
Best Regards,
Liyan
----邮件原文---- 发件人："Les Ginsberg \\(ginsberg\\)"
<ginsberg=40cisco....@dmarc.ietf.org> 收件人："龚立艳"
<gongli...@chinamobile.com>,Jeff Tantsura <jefftant.i...@gmail.com>,shraddha
<shrad...@juniper.net>,lsr <lsr@ietf.org> 抄 送: (无) 发送时间：2022-08-20 22:11:51
主题：Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo
Liyan –
I have stated this explicitly at least twice before – please do not twist my
words.
1)Modifying the operation of the base SPF in order to add support for flex-algo
MUST NOT be done.
2)Being able to use a topology for a given flex-algorithm which includes links
that are excluded from the base (Algo 0) SPF is already possible.
Please abandon your draft.
Les
From: 龚立艳 <gongli...@chinamobile.com> Sent: Saturday, August 20, 2022 6:58 AM
To: Jeff Tantsura <jefftant.i...@gmail.com> shraddha <shrad...@juniper.net> lsr
<lsr@ietf.org> Les Ginsberg (ginsberg) <ginsb...@cisco.com> Subject: Re:Re:
[Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo
Hi Les/All,
Thanks for your specific suggestion for OSPF and IS-IS.
Considering the difference between IS-IS and OSPF, How about seperating the
draft into two parts?
One is for IS-IS, using the maximum link metric.
The other is for OSPF, using the extension U-bit.
It can leverage the existing mechanism as much as possible.
Personally speaking,I think it is better if one solution is used for both IS-IS
and OSPF.
It will be great to get further comments.Thanks again.
Best Regards,
Liyan
----邮件原文---- 发件人："Les Ginsberg \\(ginsberg\\)"
<ginsberg=40cisco....@dmarc.ietf.org> 收件人："龚立艳"
<gongli...@chinamobile.com>,Jeff Tantsura <jefftant.i...@gmail.com>,shraddha
<shrad...@juniper.net>,lsr <lsr@ietf.org> 抄 送: (无) 发送时间：2022-08-18 13:11:34
主题：Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo
Liyan –
For IS-IS there is no need for a new mechanism to exclude a link from algo 0
SPF. On that we at least seem to agree.
Changing Algo 0 SPF in order to accommodate a new requirement you have for
flex-algo is simply wrong – which is why I still think your draft is not needed.
What then remains, is whether there is any need in OSPF for the new “U-bit “
that you propose. I think not, but I will let my OSPF colleagues respond more
specifically to that point.
However, even if U-bit were deemed useful for OSPF, the reason for adding it
would have nothing whatever to do with flex. The only justifiable reason would
be that Algo 0 SPF required it.
Les
From: 龚立艳 <gongli...@chinamobile.com> Sent: Wednesday, August 17, 2022 7:01 PM
To: Jeff Tantsura <jefftant.i...@gmail.com> shraddha <shrad...@juniper.net> Les
Ginsberg (ginsberg) <ginsb...@cisco.com> lsr <lsr@ietf.org> Subject: Re:Re:
[Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo
Hi All,
According to the comments, we have updated the draft to clarify these two
solutions.
SolutionA, The maximum link metric, which is backward compatible but may not
work in OSPF, since the links with maximum link metric are not always treated
as unreachable by OSPF routers. Besides, additional mechanisms are required
for the Flex-Algorithm using IGP Metric in path calculation.
SolutionB, The new extention, Which can avoid the above problems but backward
incompatible, all nodes in the same area or level must support it.
Each solution has its pros and cons. The co-authors would like more comments
and suggestions from WG.
Best Regards,
Liyan
----邮件原文---- 发件人：Jeff Tantsura <jefftant.i...@gmail.com> 收件人："Les Ginsberg
(ginsberg)" <ginsberg=40cisco....@dmarc.ietf.org>,"龚立艳"
<gongli...@chinamobile.com>,"lsr@ietf.org" <lsr@ietf.org>,shraddha
<shrad...@juniper.net> 抄 送: (无) 发送时间：2022-08-13 07:05:25 主题：Re: [Lsr] Comments
ondraft-gong-lsr-exclusive-link-for-flex-algo
+1
Cheers,
Jeff
From: Les Ginsberg (ginsberg) Sent: Friday, August 12, 2022 9:05 AM To: 龚立艳
lsr@ietf.org shraddha Subject: Re: [Lsr] Comments
ondraft-gong-lsr-exclusive-link-for-flex-algo
Liyan –
You agree that there is an existing way to prune links from the IGP SPF.
Still, you insist that an extension that requires ALL routers – whether they
support flex algo or not – to utilize a new advertisement when computing algo 0
SPF is necessary.
Your rationale for this is that this allows you to use IGP Metric for flex algo
in cases where the IGP metric would have been set to maximum.
But we already have the ability to define metrics specific to flex algo – and
this is greatly enhanced by the generic metric defined in
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/
Requiring a non backwards compatible extension to be used in base protocol
operation in order to support a new feature is exactly what we MUST NOT do when
introducing protocol extensions.
My opinion is unchanged – this is a bad idea – and completely unnecessary.
Les
From: 龚立艳 <gongli...@chinamobile.com> Sent: Friday, August 12, 2022 2:16 AM To:
lsr@ietf.org Les Ginsberg (ginsberg) <ginsb...@cisco.com> shraddha
<shrad...@juniper.net> Subject: Re:Re: [Lsr] Comments
ondraft-gong-lsr-exclusive-link-for-flex-algo
Hi Shraddha and Les,
Sorry for late reply and thanks for your comments.
Yes, the maximum link metric mechanism is an option as described in section 4
of the draft.
But, it has two defects which we also wanted to discuss in ietf 114 meeting.
Firstly, it restricts the Flex-Algorithm from using IGP-Cost as its metric-type.
Secondly, it does not work with OSPF. For OSPF,the links with maximummetric
value(65535) are also included in the SPF calculation,even if not preferred. If
there are no other preferred paths,the Flex-Algoritnm links will still
affect the result of thenormal SPF calculation.
Due to the time constraints,The presentation has been moved to the interim
meeting on 2022-09-21. For more detail, please refer to the slides.
https://datatracker.ietf.org/meeting/114/materials/slides-114-lsr-13-exclusive-link-for-flex-algo-00.
In view of these two cases, new protocol extension becomes necessary.
As for the backward incompatible issues, we think it can be avoided by
deployment.
For example, the new extension should be deployed in sync with the Flex-Algo
feature, so that all the routers in one IGP domain will run the same software
version.
Looking forward to your reply.
Best Regards,
Liyan
----邮件原文---- 发件人："Les Ginsberg \\(ginsberg\\)"
<ginsberg=40cisco....@dmarc.ietf.org> 收件人：Shraddha Hegde
<shraddha=40juniper....@dmarc.ietf.org>,"lsr@ietf.org" <lsr@ietf.org> 抄 送: (无)
发送时间：2022-07-29 21:14:08 主题：Re: [Lsr] Comments on
draft-gong-lsr-exclusive-link-for-flex-algo
I fully agree with Shraddha.
In fact Section 4 of the draft makes clear why no protocol extensions are
needed.
Les
From: Lsr <lsr-boun...@ietf.org> On Behalf Of Shraddha Hegde Sent: Friday, July
29, 2022 2:18 AM To: lsr@ietf.org Subject: [Lsr] Comments on
draft-gong-lsr-exclusive-link-for-flex-algo
Authors,
I suggest that the usecase can be satisfied using the backward compatible
Maximum link metric mechanism defined in the draft.
I don’t see any need to define protocol extensions,
that are backward incompatible and can cause serious issues in the network
in the presence of older implementations.
Rgds
Shraddha
Juniper Business Use Only
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
