Hi Ketan,
sure, thanks for catching those, I'll fix them in next revision.
thanks,
Peter
On 13/05/2022 15:32, Ketan Talaulikar wrote:
Hi Peter,
Thanks for your updates to the draft and your responses below.
I would like to point out a few remaining points to be fixed/addressed.
a) There is a discrepancy regarding the size of the Metric field for the
OSPFv2 IP Algo Reachability sub-TLV between the figure and the text
description. The text needs to be fixed to reflect 4 octets size.
b) For the OSPFv3 IP Algo Prefix Reachability sub-TLV the Type should be
2 octets and the discrepancy in the sub-TLV name in the Figure needs to
be corrected. Length should now become 8.
c) The references to the sections of draft-lsr-flex-algo in this
document need corrections in Sec 7 ? In general, I think the references
to the base draft sections 11, 12, and 13 (except that M-flag is always
used) would be helpful.
Thanks,
Ketan
On Wed, May 11, 2022 at 3:20 PM Peter Psenak <ppse...@cisco.com
<mailto:ppse...@cisco.com>> wrote:
Hi Ketan,
please see 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
Done
>
> 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
this has been discussed previously in this thread.
>
> 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
Done
>
> 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.
##PP
Done
>
> 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.
##PP
Done
>
> 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.
##PP
Done. For section 6, I would prefer to keep it in the protocol specific
sections.
>
> 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.
##PP
I prefer to keep the MUSTs there
>
> 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.
##PP
Done.
>
>
> 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.
##PP
Done
>
>
> 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.
##PP
Done
>
>
> 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.
##PP
Done
>
> 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.
##PP
Why? We have a text that says:
"This new TLV shares the sub-TLV space defined for TLVs 135, 235, 236
and 237."
Why do we need to describe the usage of the specific sub-TLV?
>
>
> 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.
##PP
Done
>
>
> 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.
##PP
Done
>
>
> 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.
##PP
Done
>
>
> 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?
##PP
Done
>
>
> 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" ?
##PP
Done
>
>
> 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?
>
> This (in some way) goes back to my comment (2) above.
##PP
I don't see the relationship to BIER IPA here.
>
>
> 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.
##PP
nothing prevents someone to advertise LDP label for the IP algo-prefix
and use it with the labeled forwarding. I don't see a problem. But this
specification does not specify any of it.
>
>
> 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
Done.
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
