Hi Peter,
> -----Original Message-----
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Thursday, December 10, 2020 9:22 PM
> To: Dongjie (Jimmy) <jie.d...@huawei.com>; Acee Lindem (acee)
> <acee=40cisco....@dmarc.ietf.org>; lsr <lsr@ietf.org>
> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
> (Flex-Algorithm)
> In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>
> Hi Jimmy,
>
> On 10/12/2020 13:02, Dongjie (Jimmy) wrote:
> > In Flex-Algo draft, it says:
> >
> > "Application-specific Flex-Algorithm participation advertisements MAY be
> topology specific or MAY be topology independent, depending on the
> application itself."
> >
> > The preassumption of current IP Flex-Algo participation is that one node
> always participate in a Flex-Algo for both IPv4 and IPv6, and for all the
> topologies it joins.
> >
> > I'm not saying this does not work, just want to understand the reason of
> > this
> design, and whether some flexibility (e.g. AF specific or topology specific)
> would
> be useful in some cases.
> >
>
> this was the choice of authors, because there does not seem to be a string
> reason to do it per topology.
>
>
> > BTW, a similar case is about SR-MPLS and SRv6 being treated as a single
> application. Below is the discussion quoted from a previous mail on this list:
> >
> > [Jie] OK. While the meaning of "app" here maybe a little vague, are
> SR-MPLS and SRv6 considered the same or different apps?
> >
> > [Peter] These are considered as single app, and share the same
> participation signaling. Please note that SRv6 support is signaled
> independently
> of FA participation.
> >
> > Does this imply that for Flex-Algo path computation with SRv6, in addition
> > to
> the Flex-Algo participation information, the SRv6 support information of nodes
> also needs to be considered, so that nodes participate in this Flex-Algo but
> do
> not support SRv6 will be pruned from the topology?
>
> no.
Let me elaborate with an example:
20 20
A------B-------C
10 | 10 | /
| | / 10
D------E --*
10
(The metrics on the links are delay metric)
- Flex-Algo 128 is defined to use delay metric for computation. This FAD is
application independent, thus can be used by all applications.
- All of the nodes (A, B, C, D, E) participate in FA 128.
- Node A, B, C, D support both SR-MPLS and SRv6.
- Node E support SR-MPLS only, it may support IPv6.
Then node A computes the path to node C with FA 128. According to the
computation rules of FA 128, the path would be A-D-E-C. This path can be used
to send SR-MPLS packet to node C.
But if node A sends SRv6 packets with node C's SRv6 SID in FA 128 as the
destination address, when the packet arrives at E, it will be dropped, because
node E does not have the forwarding entry for C's SRv6 SID in FA 128.
Do you think this is a problem?
IMO this problem is due to the FA calculation is based on the combination of
the constraints in FA definition, and the nodes' FA participation (which is app
specific), while since SR-MPLS and SRv6 are treated as one single application,
the difference in supporting SR-MPLS or SRv6 is not considered in FA
calculation. This is why I asked whether the SRv6 support information also need
be considered in FA calculation.
To solve this problem, there are several options:
Option 1: Define two different Flex-Algos for delay metric computation, one for
SR-MPLS, the other one for SRv6. But this makes the FAD application dependent.
Option 2: Include the SR-MPLS or SRv6 information in Flex-Algo participation,
i.e. make SR-MPLS and SRv6 separate applications.
Option 3: Also consider the SRv6 (or SR-MPLS) capability information in FA
calculation.
Or do you have other options in mind?
Best regards,
Jie
> thanks,
> Peter
>
>
> > If so, IMO this needs to be specified in the Flex-Algo draft. If not, please
> clarify how to prune the nodes which participate in the same Flex-Algo for
> SR-MPLS only? Thanks.
> >
> > Best regards,
> > Jie
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
