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
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
