Hi Ketan,
please responses to some of your comments inline (##PP):
On 11/04/2022 08:25, Ketan Talaulikar wrote:
Hello All,
Following are some comments on this draft:
1) Is this draft about opening the use of all IGP Algorithms for IP
(Algo) Routing or intended to be specific to Flexible Algorithms (i.e.
algo 128-255) alone. I think it is important to specify the scope
unambiguously. Perhaps it makes sense to restrict the usage in this
particular document to FlexAlgorithms alone. If not, the draft probably
needs an update and we need to also cover algo 1 (Strict SPF)
applicability and update the text to refer more generically to
algo-specific IP routing.
##PP
the intent is to use FlexAlgorithms only.
2) The relationship between the algo usage for IP FlexAlgo and other
data planes (e.g. FlexAlgo with SR) is not very clear. There arise
complications when the algo usage for IP FlexAlgo overlap with other
(say SR) data planes since the FAD is shared but the node participation
is not shared. While Sec 9 suggests that we can work through these
complications, I question the need for such complexity. The FlexAlgo
space is large enough to allow it to be shared between various data
planes without overlap. My suggestion would be to neither carve out
parallel algo spaces within IGPs for various types of FlexAlgo data
planes nor allow the same algo to be used by both IP and SR data planes.
So that we have a single topology computation in the IGP for a given
algo based on its FAD and data plane participation and then when it
comes to prefix calculation, the results could involve programming of
entries in respective forwarding planes based on the signaling of the
respective prefix reachabilities. The coverage of these aspects in a
dedicated section upfront will help.
##PP
I strongly disagree.
FAD is data-pane/app independent. Participation is data-plane/app
dependent. Base flex-algo specification is very clear about that. That
has advantages and we do not want to modify that part.
Topology calculation for algo/data-plane needs to take both FAD and
participation into account. You need independent calculation for each
data-plane/app in the same algo.
The fact that the same FAD is shareable between all apps has it
advantages and use cases - e.g. if the participation for algo X is the
same in SR and IP data-planes, one can use SR to protect IP in that algo.
3) This draft makes assertions that IGP FlexAlgo cannot be deployed
without SR. This is not true since the base IGP FlexAlgo spec explicitly
opens it up for usage outside of the SR forwarding plane. We already
have BIER and MLDP forwarding planes as users of the IGP FlexAlgo. My
suggestion is to remove such assertions from the document. It is
sufficient to just say that the document enables the use of IGP FlexAlgo
for IP prefixes with native IP forwarding.
##PP
where do you see such assertion? Each flex-algo data-plane/app can be
deployed independently.
4) The draft is mixing up "address" and "prefix" in some places. IGP
path computation is for prefixes and not addresses. There are a few
instances where "address" should be replaced by "prefix". References to
RFC791 and RFC8200 seem unnecessary.
5) The draft does not cover the actual deployment use-case or
applicability of IP FlexAlgo. The text in Sec 3 is not clear and
insufficient. What is the point/use of sending traffic to a loopback of
the egress router? Perhaps it makes sense in a deployment where IP-in-IP
encapsulation is used for delivering an overlay service? If so, would be
better to clarify this. The other deployment scenario is where
"external" or "host/leaf prefixes" are associated with a FlexAlgo to
provide them a different/appropriate routing path through the network.
Yet another is the use of IP FlexAlgo along with LDP. Sec 9 does not
address the topic well enough. I would suggest expanding and clarifying
this and perhaps other such deployment use cases (or applicability) in
the document in one of the earlier sections to provide a better context
to the reader.
6) It would be better to move the common (i.e. not protocol specific)
text from 5.1 and 5.2 under 5. This might also apply to some extent to
the contents of sec 6.
7) Most of the text with MUSTs in sec 5 doesn't really make sense in
repeating - this is covered in the base FlexAlgo spec already. The only
key/important MUST is the one related to using separate algo for IP
FlexAlgo over SR data planes. See my previous comment (2) above.
8) Sec 5.1, the SHOULD needs to be MUST in the text below.
A router receiving multiple IP Algorithm
sub-TLVs from the same originator SHOULD select the first
advertisement in the lowest-numbered LSP and subsequent instances of
the IP Algorithm Sub-TLV MUST be ignored.
9) Sec 5.1, I would suggest changing the following text as indicated.
Also, perhaps add that the algo 0 MUST NOT be advertised and a receiver
MUST ignore if it receives algo 0.
OLD
The IP Algorithm Sub-TLV could be used to advertise
support for non-zero standard algorithms, but that is outside the
scope of this document.
NEW
The use of IP Algorithm Sub-TLV to advertise support for algorithms
outside the flex-algorithm range is outside the
scope of this document.
10) Sec 5.1, the SHOULD needs to be MUST in the text below
The IP Algorithm TLV is optional. It SHOULD only be advertised once
in the Router Information Opaque LSA.
11) Sec 6. The following text is better moved into the respective
protocol sub-sections. OSPFv3 is not covered anyway by it.
Two new top-level TLVs are defined in ISIS [ISO10589
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#ref-ISO10589>]
to advertise
prefix reachability associated with a Flex-Algorithm.
* The IPv4 Algorithm Prefix Reachability TLV
* The IPv6 Algorithm Prefix Reachability TLV
New top-level TLV of OSPFv2 Extended Prefix Opaque LSA [RFC7684
<https://datatracker.ietf.org/doc/html/rfc7684>] is
defined to advertise prefix reachability associated with a Flex-
Algorithm in OSPFv2.
12) Sec 6.1 & 6.2. There is no discussion regd the use of the Prefix
Attribute Flags sub-TLV with the new top-level TLVs.
I think their usage MUST (or at least SHOULD) be included as it helps
determine the route type and prefix attributes that
have proven to be quite useful for various use cases and deployments.
13) Sec 6.2 what happens when the same prefix is advertised as SRv6
Locator as well as IPv6 Algo Prefix (same or conflicting algos). Perhaps
both must be ignored?
The same applies for OSPFv3 as well.
14) Sec 6.3, OSPFv2 MT-ID reference should be RFC4915. Perhaps the range
of MT should be mentioned since it is a 8 bit field here.
15) Sec 6.4, the metric field in the sub-TLV has to be 32-bit. While
24-bit is ok when the FAD uses IGP metric, it will not suffice for other
IGP metric types.
16) Sec 6.3 & 6.4, the conflict checking with base algo 0 prefix
reachability cannot be limited only to the OSPFv2/3 Extended LSAs but
should also cover the base fixed form
OSPFv2/v3 LSAs. We could use a more generic term like "normal prefix
reachability" advertisements perhaps to cover the different LSAs?
17) Sec 7 and 8, suggest to not use the term "application" to avoid
confusion with ASLA. My understanding is that there is a single FlexAlgo
application when it comes to ASLA.
Perhaps the intention here is "data plane" ?
18) The relationship between the BIER IPA and this draft needs some
clarifications - should the BIER WG be notified if they want to update
draft-ietf-bier-bar-ipa?
##PP
what is the relationship? I see none.
This (in some way) goes back to my comment (2) above.
19) Sec 8, what prevents the use of IP FlexAlgo paths programmed by LDP
as well. Or if the intention is to use them strictly for IP forwarding only
then this needs to be clarified.
20) The following text in Sec 9 is about using the same FlexAlgo (with a
common definition) for multiple data-planes at the same time. The key is
that we only are able to use
prefix in one algo/data-plane? I am wondering if we can improve this
text to bring this out in a better way. Or altogether remove this if we
agree to not allow sharing of algo
between different data planes to keep things simple.
Multiple application can use the same Flex-Algorithm value at the
same time and and as such share the FAD for it. For example SR-MPLS
and IP can both use such common Flex-Algorithm. Traffic for SR-MPLS
will be forwarded based on Flex-algorithm specific SR SIDs. Traffic
for IP Flex-Algorithm will be forwarded based on Flex-Algorithm
specific prefix reachability announcements.
##PP
above text does not talk about the same prefix. It talks in general how
forwarding works in presence of multiple data-planes/apps using the same
algo.
thanks,
Peter
Thanks,
Ketan
On Fri, Apr 8, 2022 at 12:38 AM Acee Lindem (acee)
<acee=40cisco....@dmarc.ietf.org <mailto:40cisco....@dmarc.ietf.org>> wrote:
This begins a WG last call for draft-ietf-lsr-ip-flexalgo-04. The
draft had a lot of support and discussion initially and has been
stable for some time. Please review and send your comments, support,
or objection to this list before 12 AM UTC on April 22^nd , 2022.____
__ __
Thanks,
Acee____
_______________________________________________
Lsr mailing list
Lsr@ietf.org <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
