On 5/16/22, 8:12 AM, "Peter Psenak" <[email protected]> wrote:
Hi Acee,
On 16/05/2022 13:25, Acee Lindem (acee) wrote:
> Hi Peter,
>
> On 5/16/22, 6:48 AM, "Peter Psenak" <[email protected]>
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"
<[email protected] on behalf of [email protected]> 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
<[email protected]
> > > <mailto:[email protected]>> 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)
> > > > <[email protected]
> > > <mailto:[email protected]>
> > > <mailto:[email protected]
> > > <mailto:[email protected]>>> 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
> > > > [email protected] <mailto:[email protected]>
<mailto:[email protected]
> > > <mailto:[email protected]>>
> > > > 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
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/lsr
> >
> >
>
>
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
