Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

["Dongjie (Jimmy)" <[e-mail]>]

Hi Peter, 

> -----Original Message-----
> From: Peter Psenak [mailto:[e-mail]]
> Sent: Thursday, December 10, 2020 5:05 PM
> To: Dongjie (Jimmy) <[e-mail]>; Acee Lindem (acee)
> <acee=[e-mail]>; lsr <[e-mail]>
> 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 09:06, Dongjie (Jimmy) wrote:
> > Hi Peter,
> >
> >> -----Original Message-----
> >> From: Peter Psenak [mailto:[e-mail]]
> >> Sent: Wednesday, December 9, 2020 9:06 PM
> >> To: Dongjie (Jimmy) <[e-mail]>; Acee Lindem (acee)
> >> <acee=[e-mail]>; lsr <[e-mail]>
> >> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
> >> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
> >>
> >> Hi Jimmy,
> >>
> >> On 09/12/2020 13:52, Dongjie (Jimmy) wrote:
> >>> Hi Peter,
> >>>
> >>>> -----Original Message-----
> >>>> From: Peter Psenak [mailto:[e-mail]]
> >>>> Sent: Wednesday, December 9, 2020 6:45 PM
> >>>> To: Dongjie (Jimmy) <[e-mail]>; Acee Lindem (acee)
> >>>> <acee=[e-mail]>; lsr <[e-mail]>
> >>>> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
> >>>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
> >>>>
> >>>> Jimmy,
> >>>>
> >>>> On 09/12/2020 11:10, Dongjie (Jimmy) wrote:
> >>>>> Hi authors,
> >>>>>
> >>>>> Here is one comment following the previous discussion on the mail
> >>>>> list and the IETF meeting.
> >>>>>
> >>>>> The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm
> >>>>> participation information, there is no separate TLV for IPv4 or
> >>>>> IPv6 Flex-Algo participation.
> >>>>
> >>>> the draft clearly says:
> >>>>
> >>>>       "The IP Flex-Algorithm participation advertised in ISIS IP Algorithm
> >>>>       Sub-TLV is topology independent."
> >>>
> >>> This does not answer my question.
> >>>
> >>> Section 7 gives the rules of IP Flex-Algo Path calculation:
> >>>
> >>> " IP Flex-Algorithm application only considers participating nodes
> >>> during
> >> the Flex-Algorithm calculation.  When computing paths for a given
> >> Flex-Algorithm, all nodes that do not advertise participation for IP
> >> Flex-Algorithm, as described in Section 5, MUST be pruned from the
> >> topology."
> >>>
> >>> >From IP Algorithm TLV, one cannot tell whether a node participates
> >>> >in
> >>>> Flex-Algo 128 for IPv4, IPv6 or both. This would cause the problem
> >>>> described below: >
> >>> When one node uses IP Flex-Algo participation to compute a path for
> >>> an
> >> IPv6 address advertised with Flex-Algo 128, it will not prune the
> >> nodes which participate in Flex-Algo 128 for IPv4 only from the
> >> topology. Thus IPv6 packets following that path may get dropped on
> >> nodes which participates in Flex-Algo 128 for IPv4 only.
> >>
> >> FA calculation is done for every MT topology independently.
> >>
> >> For IPv4 it will take all routers participating in MT0 and run the FA
> >> calculation on top of MT0.
> >>
> >> For IPv6 it will take all routers participating in MT2 and run the FA
> >> calculation on top of MT2.
> >>
> >
> > Using different MTs for different data plane and run FA path computation
> within each MT may solve the problem in many cases.
> >
> > While the different rules related to FA definition, FA participation, and FA
> reachability advertisement still make me a little confused, and there may be
> some cases not covered by the above approach.
> >
> > - Flex-Algo definition is application independent and topology independent.
> >
> > - IP Flex-Algo participation is application specific and topology independent.
> >
> > - IPv4 and IPv6 are considered as one application, while may use different
> topologies.
> >
> > - IP Flex-Algo reachability advertisement is per AF, and may with different
> topologies.
> >
> > With the above rules, let's consider the case below:
> >
> > - A node participates in both MT 0 (for IPv4) and MT 2 (for IPv6).
> >
> > - This node advertises its IP Flex-Algo participation of FA 128.
> >
> > - This node advertises IPv4 Flex-Algo reachability with MT=0/FA=128.
> >
> > - This node does NOT advertise IPv6 Flex-Algo reachability for FA 128. It may
> advertise normal IPv6 reachability in MT 2.
> >
> > Thus this node is not reachable in MT 2 with FA 128.
> 
> above is wrong.


OK, more precisely, this node cannot be used as the destination of a path in MT 2 with FA 128.

> 
> The node participates in MT2 and FA 128, as such it is reachable in MT2 in FA
> 128.
> 
> >While it will be considered by other nodes for path computation in MT 2 with
> FA 128.
> >
> > The question is: will this node compute paths for other IPv6 prefixes
> advertised with MT=2/FA=128?
> 
> absolutely. It is participating in MT2 and FA 128. The fact that "does NOT
> advertise IPv6 Flex-Algo reachability" is completely irrelevant. It is NOT
> mandatory for a node to advertise the reachability for prefix in every MT/FA
> algo it participates.
> 
> Similarly it is not required for a node that participates in in MT0 to advetise any
> IPv4 prefix and IPv4 traffic will flow over it.

Agree that it can be used as a transit node, if its Flex-Algo participation is for both AFs.

> >
> > If not, this node may drop packets whose destination is IPv6 prefixes with FA
> 128.
> >
> > And do you think it is needed to provide approach to only consider this node
> for IPv4 path computation with FA 128, and prune it from IPv6 path
> computation with FA 128? For example, make the IP Flex-Algo participation per
> AF or per topology?
> 
> absolutely not.

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. 

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

> thanks,
> Peter
> 
> 
> >
> > Best regards,
> > Jie
> >
> >>>>
> >>>>> If some nodes participate in IPv4 Flex-Algo 128, and some of these
> >>>>> nodes participate in IPv6 Flex-Algo 128, how to ensure that the
> >>>>> path computed for IPv6 Flex-Algo will not use the nodes which only
> >>>>> participate in IPv4 Flex-Algo 128?
> >>>>
> >>>> there is no such thing as "IPv4 Flex-Algo 128" or "IPv6 Flex-Algo 128".
> >>>> There is only algo 128.
> >>>
> >>> Agree that Flex-Algo 128 is application or data plane agnostic, and
> >>> as we
> >> discussed the same Flex-Algo can be used with both IPv4 and IPv6
> >> (maybe also for SR-MPLS, SRv6). These terms are used as shorthand of
> >> "Flex-Algo
> >> 128 used with IPv4 or IPv6"
> >>>
> >>>> You are mixing data plane support with algo participation.
> >>>
> >>> I understand Flex-Algo definition is application agnostic, and
> >>> Flex-Algo
> >> participation is application specific, it is just not clear to me
> >> whether IPv4 and IPv6 can be treated as one application.
> >>
> >> yes they can.
> >>
> >>>
> >>>> If you want an algo to only include nodes that supports specific
> >>>> data
> >> plane,
> >>>> you would need to define a specific algo for it.
> >>>
> >>> This IMO contradicts with the base concept: Flex-Algo definition is
> >> application (or data plane) agnostic.
> >>
> >> not really, see above.
> >>
> >> thanks,
> >> Peter
> >>
> >>>
> >>> Best regards,
> >>> Jie
> >>>
> >>>>
> >>>> thanks,
> >>>> Peter
> >>>>
> >>>>
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> Jie
> >>>>>
> >>>>> *From:*Lsr [mailto:[e-mail]] *On Behalf Of *Acee
> >>>>> Lindem
> >>>>> (acee)
> >>>>> *Sent:* Wednesday, December 2, 2020 5:13 AM
> >>>>> *To:* lsr <[e-mail]>
> >>>>> *Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms
> >>>>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
> >>>>>
> >>>>> This IP Flex Algorithm draft generated quite a bit of discussion
> >>>>> on use cases and deployment prior to IETF 109 and there was
> >>>>> generally support for WG adoption. This begins a two week WG adoption
> call.
> >>>>> Please indicate your support or objection to WG adoption on this
> >>>>> list prior to
> >>>>> 12:00 AM UTC on December 16^th , 2020. Also, review comments are
> >>>>> certainly welcome.
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Acee
> >>>>>
> >>>
> >>>
> >>>
> >
> >
> >