Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

["Acee Lindem (acee)" <[e-mail]>]

On 5/16/22, 8:12 AM, "Peter Psenak" <[e-mail]> wrote:

    Hi Acee,

    On 16/05/2022 13:25, Acee Lindem (acee) wrote:
    > Hi Peter,
    > 
    > On 5/16/22, 6:48 AM, "Peter Psenak" <ppsenak=[e-mail]> wrote:
    > 
    >      Hi Acee,
    > 
    >      thanks for your comments, I have incorporated them all.
    > 
    >      Please see one response inline:
    > 
    > 
    >      On 13/05/2022 22:28, Acee Lindem (acee) wrote:
    >      > Hi Peter,
    >      >
    >      > Thanks for addressing the WG last comments relating to terminology and IGP flex-algorithm data-plane granularity. I also have some editorial comments attached. These include:
    >      >
    >      >      1. Remove "new" from the text since these specifications will not be new when they are published.
    >      >      2. Fix the reference to the OSPFv3 Router Information Opaque LSA. As you know, there are no opaque LSAs in OSPFv3 since OSPFv3 natively supports LSA compatibility.
    >      >      3. Replace "ISIS" with "IS-IS".
    >      >      4. Use American English spellings consistent with RFC style.
    > 
    > 
    >      >
    >      > One comments, for situations where we don't install any route in the data-plane, should we recommend logging an error? For example, in RFC 7684, we say:
    > 
    >      why would not installing a forwarding entry in a specific data-plane be
    >      an error? There could be multiple valid reasons why that can happen.
    > 
    > I am only referring to the cases where we ignore advertisements due to conflict. For example:
    > 
    >      A router receiving multiple IPv4 Algorithm Prefix Reachability
    >     advertisements for the same prefix, from different originators, each
    >     with a different Algorithm, MUST ignore all of them and MUST NOT
    >     install any forwarding entries based on these advertisements.
    > 
    > There are six of these in total. Wouldn't these be configuration errors?
    ok, sure I added the "This situation SHOULD be logged as an error." to 
    all of them.

Thanks Peter,
Acee


    thanks,
    Peter
    > 
    >     
    > Thanks,
    > Acee
    > 
    > 
    >      thanks,
    >      Peter
    > 
    >      >
    >      >              This situation SHOULD be logged as an error.
    >      >
    >      > I was tempted to hyphenate "Flex-algorithm specific" and "algorithm specific" but didn't since they aren't in the base Flex-Algo specification.
    >      >
    >      > Thanks,
    >      > Acee
    >      >
    >      >
    >      >
    >      >
    >      >
    >      > On 5/13/22, 9:59 AM, "Lsr on behalf of Peter Psenak" <[e-mail] on behalf of ppsenak=[e-mail]> wrote:
    >      >
    >      >      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 <[e-mail]
    >      >      > <mailto:[e-mail]>> 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=[e-mail]
    >      >      >     <mailto:[e-mail]>
    >      >      >     <mailto:[e-mail]
    >      >      >     <mailto:[e-mail]>>> 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
    >      >      >      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
    >      >      >     <mailto:[e-mail]>>
    >      >      >      > 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
    >      >      [e-mail]
    >      >      https://www.ietf.org/mailman/listinfo/lsr
    >      >
    >      >
    > 
    > 
    >