Hi Ketan,
please see inline (##PP2):
On 11/04/2022 16:02, Ketan Talaulikar wrote:
Hi Peter,
Please check inline below.
On Mon, Apr 11, 2022 at 1:06 PM Peter Psenak <ppse...@cisco.com
<mailto:ppse...@cisco.com>> wrote:
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.
KT> Can the authors clarify this in the text? Perhaps something in one
of the earlier sections of the document that says something like -
"these extensions apply to FlexAlgorithms (128-255) only and the use for
other algorithms is beyond the scope of the document." Also perhaps,
indicate that advertisements for algos outside the FlexAlgorithm ranges
SHOULD be ignored.
##PP2
sure
>
> 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.
KT> No issue with this 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.
KT> So, an implementation now needs to potentially support performing
multiple topology computations for each algo. This is a complication for
which I do not see the justification. Why not just pick different
algorithms for different data planes for those (rare?) deployments where
someone wants multiple data planes?
##PP2
flex-algo architecture supports multiple apps/data-planes per algo, with
unique participation per app/data-plane. That requires per-algo/per
app/data-plane calculation. What is complicated on it?
If your implementation does not want to support it, fine, but the
architecture allows it and there is/are implementation(s) that already
support it. This is not defined in this draft, it's defined in base
flex-algo spec.
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.
KT> Would this protection use case not violate the base FlexAlgo rule
that the protection has to remain within the specific topology. If there
is an SR data plane, then why would one want an IP data plane as well?
##PP2
if the participation in two app/data-planes is the same for the algo,
the resulting topology is the same. If your implementation is smart, it
can only run a single computation for that case. There is no violation
here whatsoever.
IP forwarding can be steered over the SR-based FlexAlgo topology along
with the protection provided by it. Am I missing something?
##PP2
topology for both primary and backup computation must be the same.
>
> 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.
KT> Let me clarify what I meant by taking the example of the abstract.
OLD
An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute
constraint-based paths. As currently defined, IGP Flex-Algorithm is
used with Segment Routing (SR) data planes - SR MPLS and SRv6.
Therefore, Flex-Algorithm cannot be deployed in the absence of SR.
This document extends IGP Flex-Algorithm, so that it can be used for
regular IPv4 and IPv6 prefixes. This allows Flex-Algorithm to be
deployed in any IP network, even in the absence of SR.
NEW
An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute
constraint-based paths. The base IGP Flex-Algorithm document
specified use with Segment Routing (SR) data planes - SR MPLS and
SRv6.
This document extends IGP Flex-Algorithm, so that it can be used with
regular IPv4 and IPv6 forwarding.
##PP2
ok
>
> 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
<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
<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.
KT> Can BIER use FlexAlgo with IP Forwarding as the IPA?
Perhaps draft-ietf-bier-bar-ipa needs to discuss/cover flex algo? This
comment is not so much about the IP FlexAlgo draft and maybe someone
here also working on BIER can point to a document that covers the
applicability of FlexAlgo as IPA for BIER.
##PP2
I let some BIER knowledgeable folks to respond to that.
>
> 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.
KT> I am suggesting that clarifying that we are talking about different
prefixes here would be helpful.
##PP2
absolutely.
thanks,
Peter
Thanks,
Ketan
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>
<mailto: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> <mailto:Lsr@ietf.org
<mailto:Lsr@ietf.org>>
> https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>
> <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
