date:20220517

Re: [Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

2022-05-17 Thread Gyan Mishra

Hi Jie

I reviewed the draft as well and it seems to parallel SR VTN MT draft
 Enhanced VPN / VPN+  underpinning to IETF slice underlay TEAS NRP  mapped
to an ISIS or OSPF MTID control plane instance.

Similarly here with this draft mapping of TEAS NRP to a Flex Algo FAD
realizing of IETF network slice and now bundle members with this draft
extensions to RFC 8668 ISIS and OSPF draft
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-03 can
now be mapped to an NRP.

VTN MT
https://datatracker.ietf.org/doc/html/draft-xie-lsr-isis-sr-vtn-mt

Suggestion for s/VTN/NRP using updated TEAS Network slicing terminology.

This draft updates RFC 8668 for ISIS but should also update the OSPF draft
above.

I think Adrian may have mentioned in his review I would refer to Flex Algo
as IGP Flex Algo not SR Flex Algo throughout the draft as specified in the
IGP Flex Algo draft.

I think it may or may not be the intention but I believe along with
realizing an NRP using IGP Flex Algo mapping to L2 bundle member links,
this draft also provides the context of realizing an NRP using Flex Algo
and using the Flex Algo identifier as a way to reference or index the NRP
per statement in section 2.

If each VTN is associated with a unique Flex-Algo, the Flex-Algo
identifier could be
reused as the identifier of the VTN in the control plane.

With the 1 to 1 mapping of Flex Algo to NRP you could also use the Flex
Algo identifier to correlate the IETF Network slice NRP being instantiated
by the NSC and possibly could use the Flex Algo identifier as the NRP ID.

Kind Regards

Gyan

On Tue, May 17, 2022 at 6:01 AM Dongjie (Jimmy)  wrote:

> Hi Adrian,
>
> Thanks a lot for your detailed review. All your comments and suggestions
> look good and we will produce a new revision to incorporate them.
>
> And please see replies to some points inline:
>
> Best regards,
> Jie
>
> > -Original Message-
> > From: Adrian Farrel [mailto:adr...@olddog.co.uk]
> > Sent: Monday, May 16, 2022 7:22 PM
> > To: lsr@ietf.org
> > Cc: draft-zhu-lsr-isis-sr-vtn-flexa...@ietf.org
> > Subject: FW: A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04
> >
> > Hi LSR and draft authors,
> >
> > I read this draft, and it seems to me that it provides a useful
> transitional
> > mechanism. It can obviously only support a relatively small number of
> VTNs
> > (128 due to the limited number of Flex-Algos the network devices can
> > support), but it looks to be a worthwhile first step because it can be
> achieved
> > with a very minor control plane extension.
> >
> > Perhaps this document is a good first step while we work on a longer term
> > and more scalable control plane solution. It would also give us the
> chance to
> > determine the level of interest in VTNs.
>
> Indeed, this is exactly the purpose of this document.
>
> >
> > My comments, below, are mainly editorial, but there are a couple of
> issues
> > around the use of the E flag.
> >
> > Best,
> > Adrian
> >
> > (PS. For those of you saying "What's a VTN?" the "Virtual Transport
> > Network"
> > is a network construct described in the TEAS WG to support Enhanced VPNs
> > (https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/) and
> network
> > slicing
> > (https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/)
> > where it maps to a "Network Resource Partition".)
> >
> > ===
> >
> > As currently defined, I think this document needs to update RFC 8668.
> This is
> > because that RFC says that other flags in the flag field of the Parent L3
> > Neighbor Descriptor in the L2 Bundle Member Attributes TLV "MUST be
> > ignored".
> >
> > That's easy enough to handle:
> > - You add the "updates 8668" element to the XML
> > - You add a final paragraph to the Abstract to say
> > This document updates RFC 8668 by defining a new flag in the Parent
> > L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV.
> > - You add a final paragraph to the Introduction to say
> > This document updates [RFC8668] by defining a new flag in the Parent
> > L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV.
> > [RFC8668] states that all bit fields not defined in that document
> > "MUST be set to zero on transmission and ignored on receipt".
> > Section 3 of this document defines a new flag and specifies both
> > when it is set and how it should be processed.
> >
> > However, a purist might point out that RFC 8668 should be fixed so that:
> >
> > - The unused bits are defined as reserved for future use
> > - The text should be updated to describe how the bits are set and handled
> >   by implementations that don't understand them
> > - There should be an IANA registry for the bits
> >
> > You're not responsible for fixing RFC 8668, but you could if you want to.
> >
> > Making this document an "update" is also important because of the absence
> > of an IANA registry -- it is important to provide a way for people to
> track the
> > bits so that there

Re: [Lsr] Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

2022-05-17 Thread Robert Raszuk

Hi Peter,

Enabling local protection on all nodes in all topologies may also not be
the best thing to do (for various reasons).

While I agree that general fallback may be fragile, how about limited
fallback and only to one special "protection topology" which would have few
constraints allowing us to do such fallback safely ?

I guess for ip flex-algo which is a subject of this thread this would not
be possible, but for SR flex-algo I think this may work pretty well
allowing N:1 fast connectivity restoration.

Thx,
Robert

On Tue, May 17, 2022 at 2:19 PM Peter Psenak  wrote:

> Robert,
>
> On 17/05/2022 14:14, Robert Raszuk wrote:
> > Ok cool - thx Peter !
> >
> > More general question - for any FlexAlgo model (incl. SR):
> >
> > Is fallback between topologies - say during failure of primary one -
> > only allowed on the ingress to the network ?
>
> no. Fallback between flex-algos has never been a requirement and is not
> part of the flex-algo specification.
>
> I consider it a dangerous thing to do. It may work under certain
> conditions, but may cause loops under different ones.
>
> thanks,
> Peter
>
>
> >
> > If so the repair must be setup on each topology, otherwise repair will
> > be long as it would need to wait for igp flooding and ingress switchover
> > trigger ?
> >
> > Obviously for IP flex algo it would be much much longer as given prefix
> > needs to be completely reflooded network wide and purged from original
> > topo. Ouch considering time to trigger such action.
> >
> > Many thanks,
> > R.
> >
> > On Tue, May 17, 2022, 13:35 Peter Psenak  > > wrote:
> >
> > Hi Robert,
> >
> >
> > On 17/05/2022 12:11, Robert Raszuk wrote:
> >  >
> >  > Actually I would like to further clarify if workaround 1 is even
> > doable ...
> >  >
> >  > It seems to me that the IP flexalgo paradigm does not have a way
> for
> >  > more granular then destination prefix forwarding.
> >
> > that is correct. In IP flex-algo the prefix itself is bound to the
> > algorithm.
> >
> >  >
> >  > So if I have http traffic vs streaming vs voice going to the same
> > load
> >  > balancer (same dst IP address) there seems to be no way to map
> some
> >  > traffic (based on say port number) to take specific topology.
> >
> > no, you can not do that with IP flex-algo.
> >
> >
> >  >
> >  > That's pretty coarse and frankly very limiting for applicability
> > of IP
> >  > flex-algo. If I am correct the draft should be very
> > explicit about this
> >  > before publication.
> >
> > please look at the latest version of the draft, section 3:
> >
> >
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-3
> > <
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-3
> >
> >
> > thanks,
> > Peter
> >
> >  >
> >  > Kind regards
> >  > R.
> >  >
> >  > On Tue, May 17, 2022 at 12:01 PM Robert Raszuk  > 
> >  > >> wrote:
> >  >
> >  > Folks,
> >  >
> >  > A bit related to Aijun's point but I have question to
> > the text from
> >  > the draft he quoted:
> >  >
> >  > In cases where a prefix advertisement is received in both
> > a IPv4
> >  > Prefix Reachability TLV and an IPv4 Algorithm Prefix
> > Reachability
> >  > TLV, the IPv4 Prefix Reachability advertisement MUST be
> > preferred
> >  > when installing entries in the forwarding plane.
> >  >
> >  > Does this really mean that I can not for a given prefix say
> > /24 use
> >  > default topology for best effort traffic and new flex-algo
> > topology
> >  > for specific application ?
> >  >
> >  > Is the "workaround 1" to always build two new topologies for
> such
> >  > /24 prefix (one following base topo and one new) and never
> > advertise
> >  > it in base topology ?
> >  >
> >  > Is the "workaround 2" to forget about native forwarding and
> > use for
> >  > example SR and mark the packets such that SID pool
> > corresponding to
> >  > base topology forwarding will be separate from SID pool
> >  > corresponding to new flex-algo topology ?
> >  >
> >  > Many thx,
> >  > Robert
> >  >
> >  >
> >  > -- Forwarded message -
> >  > From: *Acee Lindem via Datatracker*  > 
> >  > >>
> >  > Date: Mon, May 16, 2022 at 3:36 PM
> >  > Subject: [Lsr] Publication has been requested for
> >  > draft-ietf-lsr-ip-flexalgo-06
> >  > To: mailto:j...@juniper.net>
> > >>
> >  > Cc:

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

2022-05-17 Thread Peter Psenak

Aijun,

On 17/05/2022 16:22, Aijun Wang wrote:

Hi, Peter:
Here is the contradictory:
The prefixes that associated with SID can exist in multiple Algo and
also the algorithm 0.

in SR MOPLS only.

Why the prefixes that don’t associate with the SID can’t exist in
specific Algo and also the algorithm 0?

because in the absence of label, you only can install a single IP
forwarding entry for the IP prefix.

Peter

I have provided the solutions for the loop avoidance. If this is only
your worry, you can responses the threads that I discussed with Acee.

Aijun Wang
China Telecom

On May 17, 2022, at 21:42, Peter Psenak
wrote:

Aijun,

On 17/05/2022 15:04, Aijun Wang wrote:

Hi, Peter:
Based on the statements in
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo-06#section-6
as
the followings:

FAPM is only used for SR MPLS, where the prefix can exist in multiple
algos and forwarding is realized via algo specific label(s). In SR
MPLS the prefix is always reachable in algo 0.

In IP flex-algo, the prefix is only associated with a single algo.

thanks,
Peter

Aijun Wang
China Telecom

On May 17, 2022, at 19:24, Peter Psenak wrote:

Hi Aijun,

please see inline:

On 17/05/2022 04:10, Aijun Wang wrote:

Hi, Peter and Acee:
Then the key issues are the node’s capabilities negotiation within
one area. Right?
To deploy the flex-Algo and ensure the forwarding paths are
available, should the nodes within one area be all upgraded in
advance?

absolutely not. That has never been a requirement for flex-algo. It
can be deployed incrementally.

If so, why we should still worry about the legacy router? If not,
how the operators confirm/assures there will be available paths
when apply one flex-algorithm? I think it will be a disaster when
only some of routers within the area to support some of
flex-algorithms.

no, it will work just fine. Same as if not all routers participate
in the particular flex-alago. That is actually one of the deployment
scenarios that I've seen being deployed - using flex-algo to create
multiple specific planes with a subset of routers only.

Not every node should participate each flex-algorithm, but every
node should support the deployed flex-algorithm.

no, that is absolutely not a requirement.

If the above conditions are not met, such algorithm specified
prefixes shouldn’t be advertised in any node.
Based on the above rule, no possible loop will occur. The standard
will be also simplified.

Or else, why we have the node capabilities advertisements?

there is no negotiation of the flex-algo support. Only the
participation in flex-algo is advertised.

thanks,
Peter

Aijun Wang
China Telecom
On May 17, 2022, at 01:24, Peter Psenak
wrote:

Aijun,

please read the responses from Les and myself on this matter. We
can not use legacy advertisement of prefix for IP algp prefixes,
because legacy routers would treat this as valid advertisement of
prefix in algo-0. If that happens routers with IP algpo support
would calculate the path on a different topology than the routers
that do not support IP algo. That at the end would result in
permanent loops.

I don't know what else to add. Seems obvious to me.

thanks,
Peter

“To be able to associate the prefix with the Flex-Algorithm, the
existing prefix reachability advertisements can not be used,
because

they advertise the prefix reachability in default algorithm 0.
Instead, a new IP Flex-Algorithm reachability advertisements are
defined in IS-IS and OSPF.”
If the above statement is valid, then why the FAPM defined in the
base document can be the sub-TLV of existing prefix advertisements?
Please also refer to the IANA allocation table
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-prefix-reachability
And, I see no any clue of different flex-Algo will influence each
other:
If the router doesn’t support FAPM sub-TLV(doesn’t not support
flex-Algo) or the FAPM sub-TLV doesn’t present in the

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

2022-05-17 Thread Peter Psenak

Aijun,

On 17/05/2022 15:04, Aijun Wang wrote:

Hi, Peter:
Based on the statements in
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo-06#section-6
as
the followings:

“To be able to associate the prefix with the Flex-Algorithm, the

existing prefix reachability advertisements can not be used, because
they advertise the prefix reachability in default algorithm 0.
Instead, a new IP Flex-Algorithm reachability advertisements are
defined in IS-IS and OSPF.”

Then why the FAPM sub-TLV can be included in these prefixes reachability
advertisements?

FAPM is only used for SR MPLS, where the prefix can exist in multiple
algos and forwarding is realized via algo specific label(s). In SR MPLS
the prefix is always reachable in algo 0.

In IP flex-algo, the prefix is only associated with a single algo.

thanks,
Peter

Aijun Wang
China Telecom

On May 17, 2022, at 19:24, Peter Psenak wrote:

Hi Aijun,

please see inline:

On 17/05/2022 04:10, Aijun Wang wrote:

absolutely not. That has never been a requirement for flex-algo. It
can be deployed incrementally.

If so, why we should still worry about the legacy router? If not,
how the operators confirm/assures there will be available paths when
apply one flex-algorithm? I think it will be a disaster when only
some of routers within the area to support some of flex-algorithms.

no, it will work just fine. Same as if not all routers participate in
the particular flex-alago. That is actually one of the deployment
scenarios that I've seen being deployed - using flex-algo to create
multiple specific planes with a subset of routers only.

Not every node should participate each flex-algorithm, but every node
should support the deployed flex-algorithm.

no, that is absolutely not a requirement.

Or else, why we have the node capabilities advertisements?

there is no negotiation of the flex-algo support. Only the
participation in flex-algo is advertised.

thanks,
Peter

Aijun Wang
China Telecom
On May 17, 2022, at 01:24, Peter Psenak
wrote:

Aijun,

please read the responses from Les and myself on this matter. We can
not use legacy advertisement of prefix for IP algp prefixes, because
legacy routers would treat this as valid advertisement of prefix in
algo-0. If that happens routers with IP algpo support would
calculate the path on a different topology than the routers that do
not support IP algo. That at the end would result in permanent loops.

I don't know what else to add. Seems obvious to me.

thanks,
Peter

“To be able to associate the prefix with the Flex-Algorithm, the
existing prefix reachability advertisements can not be used, because
they advertise the prefix reachability in default algorithm 0.
Instead, a new IP Flex-Algorithm reachability advertisements are
defined in IS-IS and OSPF.”
If the above statement is valid, then why the FAPM defined in the
base document can be the sub-TLV of existing prefix advertisements?
Please also refer to the IANA allocation table
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-prefix-reachability
And, I see no any clue of different flex-Algo will influence each
other:
If the router doesn’t support FAPM sub-TLV(doesn’t not support
flex-Algo) or the FAPM sub-TLV doesn’t present in the prefix
advertisements , the prefixes will be calculated in algorithm 0. If
the router support FAPM sub-TLV(support flex-Algo) and FAPM is
present, the associated prefixes will be calculated in the
appointed Flex-Algorithm.

What’s the difficulty?
I have also noticed your statement in the document write up, but
you and the authors’ responses to the concerns are unreasonable.
Should the AD make the final judgment and give one reasonable
explanation?
I respect the works of the authors and all the reviewers’ and
shepherd’s efforts, but think this is not the right direction to
accomplish the aim.

Aijun Wang
China Telecom
On May

Re: [Lsr] Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

2022-05-17 Thread Peter Psenak


Robert,

On 17/05/2022 14:14, Robert Raszuk wrote:

Ok cool - thx Peter !

More general question - for any FlexAlgo model (incl. SR):

Is fallback between topologies - say during failure of primary one - 
only allowed on the ingress to the network ?


no. Fallback between flex-algos has never been a requirement and is not 
part of the flex-algo specification.


I consider it a dangerous thing to do. It may work under certain 
conditions, but may cause loops under different ones.


thanks,
Peter




If so the repair must be setup on each topology, otherwise repair will 
be long as it would need to wait for igp flooding and ingress switchover 
trigger ?


Obviously for IP flex algo it would be much much longer as given prefix 
needs to be completely reflooded network wide and purged from original 
topo. Ouch considering time to trigger such action.


Many thanks,
R.

On Tue, May 17, 2022, 13:35 Peter Psenak > wrote:


Hi Robert,


On 17/05/2022 12:11, Robert Raszuk wrote:
 >
 > Actually I would like to further clarify if workaround 1 is even
doable ...
 >
 > It seems to me that the IP flexalgo paradigm does not have a way for
 > more granular then destination prefix forwarding.

that is correct. In IP flex-algo the prefix itself is bound to the
algorithm.

 >
 > So if I have http traffic vs streaming vs voice going to the same
load
 > balancer (same dst IP address) there seems to be no way to map some
 > traffic (based on say port number) to take specific topology.

no, you can not do that with IP flex-algo.


 >
 > That's pretty coarse and frankly very limiting for applicability
of IP
 > flex-algo. If I am correct the draft should be very
explicit about this
 > before publication.

please look at the latest version of the draft, section 3:


https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-3


thanks,
Peter

 >
 > Kind regards
 > R.
 >
 > On Tue, May 17, 2022 at 12:01 PM Robert Raszuk mailto:rob...@raszuk.net>
 > >> wrote:
 >
 >     Folks,
 >
 >     A bit related to Aijun's point but I have question to
the text from
 >     the draft he quoted:
 >
 >         In cases where a prefix advertisement is received in both
a IPv4
 >         Prefix Reachability TLV and an IPv4 Algorithm Prefix
Reachability
 >         TLV, the IPv4 Prefix Reachability advertisement MUST be
preferred
 >         when installing entries in the forwarding plane.
 >
 >     Does this really mean that I can not for a given prefix say
/24 use
 >     default topology for best effort traffic and new flex-algo
topology
 >     for specific application ?
 >
 >     Is the "workaround 1" to always build two new topologies for such
 >     /24 prefix (one following base topo and one new) and never
advertise
 >     it in base topology ?
 >
 >     Is the "workaround 2" to forget about native forwarding and
use for
 >     example SR and mark the packets such that SID pool
corresponding to
 >     base topology forwarding will be separate from SID pool
 >     corresponding to new flex-algo topology ?
 >
 >     Many thx,
 >     Robert
 >
 >
 >     -- Forwarded message -
 >     From: *Acee Lindem via Datatracker* mailto:nore...@ietf.org>
 >     >>
 >     Date: Mon, May 16, 2022 at 3:36 PM
 >     Subject: [Lsr] Publication has been requested for
 >     draft-ietf-lsr-ip-flexalgo-06
 >     To: mailto:j...@juniper.net>
>>
 >     Cc: mailto:a...@cisco.com>
>>,
 >     mailto:iesg-secret...@ietf.org>
>>,
 >     mailto:lsr-cha...@ietf.org>
>>,
mailto:lsr@ietf.org>
 >     >>
 >
 >
 >     Acee Lindem has requested publication of
 >     draft-ietf-lsr-ip-flexalgo-06 as Proposed Standard on behalf
of the
 >     LSR working group.
 >
 >     Please verify the document's state at
 > https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/

 >     >
 >
 >
 >     ___
 >     Lsr mailing list
 > Lsr@ietf.org

Re: [Lsr] Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

2022-05-17 Thread Robert Raszuk

Ok cool - thx Peter !

More general question - for any FlexAlgo model (incl. SR):

Is fallback between topologies - say during failure of primary one - only
allowed on the ingress to the network ?

If so the repair must be setup on each topology, otherwise repair will be
long as it would need to wait for igp flooding and ingress switchover
trigger ?

Obviously for IP flex algo it would be much much longer as given prefix
needs to be completely reflooded network wide and purged from original
topo. Ouch considering time to trigger such action.

Many thanks,
R.

On Tue, May 17, 2022, 13:35 Peter Psenak  wrote:

> Hi Robert,
>
>
> On 17/05/2022 12:11, Robert Raszuk wrote:
> >
> > Actually I would like to further clarify if workaround 1 is even doable
> ...
> >
> > It seems to me that the IP flexalgo paradigm does not have a way for
> > more granular then destination prefix forwarding.
>
> that is correct. In IP flex-algo the prefix itself is bound to the
> algorithm.
>
> >
> > So if I have http traffic vs streaming vs voice going to the same load
> > balancer (same dst IP address) there seems to be no way to map some
> > traffic (based on say port number) to take specific topology.
>
> no, you can not do that with IP flex-algo.
>
>
> >
> > That's pretty coarse and frankly very limiting for applicability of IP
> > flex-algo. If I am correct the draft should be very explicit about this
> > before publication.
>
> please look at the latest version of the draft, section 3:
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-3
>
> thanks,
> Peter
>
> >
> > Kind regards
> > R.
> >
> > On Tue, May 17, 2022 at 12:01 PM Robert Raszuk  > > wrote:
> >
> > Folks,
> >
> > A bit related to Aijun's point but I have question to the text from
> > the draft he quoted:
> >
> > In cases where a prefix advertisement is received in both a IPv4
> > Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability
> > TLV, the IPv4 Prefix Reachability advertisement MUST be preferred
> > when installing entries in the forwarding plane.
> >
> > Does this really mean that I can not for a given prefix say /24 use
> > default topology for best effort traffic and new flex-algo topology
> > for specific application ?
> >
> > Is the "workaround 1" to always build two new topologies for such
> > /24 prefix (one following base topo and one new) and never advertise
> > it in base topology ?
> >
> > Is the "workaround 2" to forget about native forwarding and use for
> > example SR and mark the packets such that SID pool corresponding to
> > base topology forwarding will be separate from SID pool
> > corresponding to new flex-algo topology ?
> >
> > Many thx,
> > Robert
> >
> >
> > -- Forwarded message -
> > From: *Acee Lindem via Datatracker*  > >
> > Date: Mon, May 16, 2022 at 3:36 PM
> > Subject: [Lsr] Publication has been requested for
> > draft-ietf-lsr-ip-flexalgo-06
> > To: mailto:j...@juniper.net>>
> > Cc: mailto:a...@cisco.com>>,
> > mailto:iesg-secret...@ietf.org>>,
> > mailto:lsr-cha...@ietf.org>>,  > >
> >
> >
> > Acee Lindem has requested publication of
> > draft-ietf-lsr-ip-flexalgo-06 as Proposed Standard on behalf of the
> > LSR working group.
> >
> > Please verify the document's state at
> > https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
> > 
> >
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org 
> > https://www.ietf.org/mailman/listinfo/lsr
> > 
> >
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

2022-05-17 Thread Peter Psenak


Hi Robert,


On 17/05/2022 12:11, Robert Raszuk wrote:


Actually I would like to further clarify if workaround 1 is even doable ...

It seems to me that the IP flexalgo paradigm does not have a way for 
more granular then destination prefix forwarding.


that is correct. In IP flex-algo the prefix itself is bound to the 
algorithm.




So if I have http traffic vs streaming vs voice going to the same load 
balancer (same dst IP address) there seems to be no way to map some 
traffic (based on say port number) to take specific topology.


no, you can not do that with IP flex-algo.




That's pretty coarse and frankly very limiting for applicability of IP 
flex-algo. If I am correct the draft should be very explicit about this 
before publication.


please look at the latest version of the draft, section 3:


https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-3

thanks,
Peter



Kind regards
R.

On Tue, May 17, 2022 at 12:01 PM Robert Raszuk > wrote:


Folks,

A bit related to Aijun's point but I have question to the text from
the draft he quoted:

    In cases where a prefix advertisement is received in both a IPv4
    Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability
    TLV, the IPv4 Prefix Reachability advertisement MUST be preferred
    when installing entries in the forwarding plane.

Does this really mean that I can not for a given prefix say /24 use
default topology for best effort traffic and new flex-algo topology
for specific application ?

Is the "workaround 1" to always build two new topologies for such
/24 prefix (one following base topo and one new) and never advertise
it in base topology ?

Is the "workaround 2" to forget about native forwarding and use for
example SR and mark the packets such that SID pool corresponding to
base topology forwarding will be separate from SID pool
corresponding to new flex-algo topology ?

Many thx,
Robert


-- Forwarded message -
From: *Acee Lindem via Datatracker* mailto:nore...@ietf.org>>
Date: Mon, May 16, 2022 at 3:36 PM
Subject: [Lsr] Publication has been requested for
draft-ietf-lsr-ip-flexalgo-06
To: mailto:j...@juniper.net>>
Cc: mailto:a...@cisco.com>>,
mailto:iesg-secret...@ietf.org>>,
mailto:lsr-cha...@ietf.org>>, mailto:lsr@ietf.org>>


Acee Lindem has requested publication of
draft-ietf-lsr-ip-flexalgo-06 as Proposed Standard on behalf of the
LSR working group.

Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/



___
Lsr mailing list
Lsr@ietf.org 
https://www.ietf.org/mailman/listinfo/lsr




___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2022-05-17 Thread Peter Psenak

Hi Aijun,

please see inline:

On 17/05/2022 04:10, Aijun Wang wrote:

Hi, Peter and Acee:
Then the key issues are the node’s capabilities negotiation within one area.
Right?
To deploy the flex-Algo and ensure the forwarding paths are available, should
the nodes within one area be all upgraded in advance?

absolutely not. That has never been a requirement for flex-algo. It can
be deployed incrementally.

If so, why we should still worry about the legacy router? If not, how the
operators confirm/assures there will be available paths when apply one
flex-algorithm? I think it will be a disaster when only some of routers within
the area to support some of flex-algorithms.

no, it will work just fine. Same as if not all routers participate in
the particular flex-alago. That is actually one of the deployment
scenarios that I've seen being deployed - using flex-algo to create
multiple specific planes with a subset of routers only.

Not every node should participate each flex-algorithm, but every node should
support the deployed flex-algorithm.

no, that is absolutely not a requirement.

If the above conditions are not met, such algorithm specified prefixes
shouldn’t be advertised in any node.
Based on the above rule, no possible loop will occur. The standard will be also
simplified.
Or else, why we have the node capabilities advertisements?

there is no negotiation of the flex-algo support. Only the participation
in flex-algo is advertised.

thanks,
Peter

Aijun Wang
China Telecom

On May 17, 2022, at 01:24, Peter Psenak
wrote:

Aijun,

please read the responses from Les and myself on this matter. We can not use
legacy advertisement of prefix for IP algp prefixes, because legacy routers
would treat this as valid advertisement of prefix in algo-0. If that happens
routers with IP algpo support would calculate the path on a different topology
than the routers that do not support IP algo. That at the end would result in
permanent loops.

I don't know what else to add. Seems obvious to me.

thanks,
Peter

On 16/05/2022 17:35, Aijun Wang wrote:
Hi, Acee:
I am curious that you are so hurry to forward this document.
The updated document just describes the followings:
(https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo-06#section-6
)
“To be able to associate the prefix with the Flex-Algorithm, the
existing prefix reachability advertisements can not be used, because
they advertise the prefix reachability in default algorithm 0.
Instead, a new IP Flex-Algorithm reachability advertisements are
defined in IS-IS and OSPF.”
If the above statement is valid, then why the FAPM defined in the base document
can be the sub-TLV of existing prefix advertisements?
Please also refer to the IANA allocation table
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-prefix-reachability

And, I see no any clue of different flex-Algo will influence each other:
If the router doesn’t support FAPM sub-TLV(doesn’t not support flex-Algo) or
the FAPM sub-TLV doesn’t present in the prefix advertisements , the prefixes
will be calculated in algorithm 0. If the router support FAPM sub-TLV(support
flex-Algo) and FAPM is present, the associated prefixes will be calculated in
the appointed Flex-Algorithm.
What’s the difficulty?
I have also noticed your statement in the document write up, but you and the
authors’ responses to the concerns are unreasonable.
Should the AD make the final judgment and give one reasonable explanation?
I respect the works of the authors and all the reviewers’ and shepherd’s
efforts, but think this is not the right direction to accomplish the aim.
Aijun Wang
China Telecom

On May 16, 2022, at 19:50, Acee Lindem (acee)
wrote:

Hi Aijun,

We need to support mixed deployments of routers that do and do not support flex
algorithm and in these deployments the default algorithm, i.e., algorithm 0,
computation must not be impacted. This is clearly stated in the draft. Your
suggestion is noted but what you are suggesting doesn’t satisfy these
requirements.

Thanks,
Acee

*From: *Aijun Wang
*Date: *Saturday, May 14, 2022 at 11:19 PM
*To: *Acee Lindem
*Cc: *"Peter Psenak (ppsenak)" , Ketan Talaulikar ,
"lsr@ietf.org" , "draft-ietf-lsr-ip-flexa...@ietf.org"

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

Hi, Acee and Peter:
I don’t still think this document is necessary, unless you can answer the
following questions clearly:
1) Section 5 about the “Advertising IP Flex-Algorithm Reachability” are not
necessary, since every FAD has need advertised in the FAD advertisements. There
is no

Re: [Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

2022-05-17 Thread Adrian Farrel

All looks good.
I'll watch for the updated draft.
Best,
Adrian

-Original Message-
From: Dongjie (Jimmy)  
Sent: 17 May 2022 10:59
To: adr...@olddog.co.uk; lsr@ietf.org
Cc: draft-zhu-lsr-isis-sr-vtn-flexa...@ietf.org
Subject: RE: A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

Hi Adrian, 

Thanks a lot for your detailed review. All your comments and suggestions
look good and we will produce a new revision to incorporate them. 

And please see replies to some points inline:

Best regards,
Jie

> -Original Message-
> From: Adrian Farrel [mailto:adr...@olddog.co.uk]
> Sent: Monday, May 16, 2022 7:22 PM
> To: lsr@ietf.org
> Cc: draft-zhu-lsr-isis-sr-vtn-flexa...@ietf.org
> Subject: FW: A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04
> 
> Hi LSR and draft authors,
> 
> I read this draft, and it seems to me that it provides a useful
transitional
> mechanism. It can obviously only support a relatively small number of VTNs
> (128 due to the limited number of Flex-Algos the network devices can
> support), but it looks to be a worthwhile first step because it can be
achieved
> with a very minor control plane extension.
> 
> Perhaps this document is a good first step while we work on a longer term
> and more scalable control plane solution. It would also give us the chance
to
> determine the level of interest in VTNs.

Indeed, this is exactly the purpose of this document.

> 
> My comments, below, are mainly editorial, but there are a couple of issues
> around the use of the E flag.
> 
> Best,
> Adrian
> 
> (PS. For those of you saying "What's a VTN?" the "Virtual Transport
> Network"
> is a network construct described in the TEAS WG to support Enhanced VPNs
> (https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/) and
network
> slicing
> (https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/)
> where it maps to a "Network Resource Partition".)
> 
> ===
> 
> As currently defined, I think this document needs to update RFC 8668. This
is
> because that RFC says that other flags in the flag field of the Parent L3
> Neighbor Descriptor in the L2 Bundle Member Attributes TLV "MUST be
> ignored".
> 
> That's easy enough to handle:
> - You add the "updates 8668" element to the XML
> - You add a final paragraph to the Abstract to say
> This document updates RFC 8668 by defining a new flag in the Parent
> L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV.
> - You add a final paragraph to the Introduction to say
> This document updates [RFC8668] by defining a new flag in the Parent
> L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV.
> [RFC8668] states that all bit fields not defined in that document
> "MUST be set to zero on transmission and ignored on receipt".
> Section 3 of this document defines a new flag and specifies both
> when it is set and how it should be processed.
> 
> However, a purist might point out that RFC 8668 should be fixed so that:
> 
> - The unused bits are defined as reserved for future use
> - The text should be updated to describe how the bits are set and handled
>   by implementations that don't understand them
> - There should be an IANA registry for the bits
> 
> You're not responsible for fixing RFC 8668, but you could if you want to.
> 
> Making this document an "update" is also important because of the absence
> of an IANA registry -- it is important to provide a way for people to
track the
> bits so that there is no collision when another bit is defined.
> 
> You could use definitely use this document to create the necessary IANA
> registry, even if you are not fixing the other parts of 8668.

Thanks for your suggestion, we will make this document an update of RFC 8668
to help track the new flag.


> 
> ---
> 
> Would be worth expanding "VTN" in the title to read...
>   Using Flex-Algo for Segment Routing based Virtual Transport Networks
> 
> ---
> 
> Abstract
> 
> The first mention of "Flex-Algo" needs to have some explanation of the
> concept. Not many words, but something like...
> 
> OLD
>The topological constraints of a VTN can be defined using Flex-Algo.
> NEW
>The topological constraints of a VTN can be defined using Flex-Algo,
>a mechanism to provide distributed constraint-path computation.
> END

We will add some description about Flex-Algo. 


> ---
> 
> Abstract
> 
> "SR" should be spelled out as "Segment Routing (SR)"
> 
> ---
> 
> Abstract
> 
> s/L2 bundle/L2 bundles/
> 
> ---
> 
> 1.
> 
> The word "traditional" has other meanings in American English and we are
> now asked to avoid using it.
> 
> OLD
>than that can be provided with traditional overlay VPNs.
> NEW
>than that could be provided with existing overlay VPNs techniques.
> END

OK, will make the change accordingly.

> 
> ---
> 
> 1.
> 
> s/resource-aware SIDs/resource-aware segment identifiers (SIDs)/ s/With
> segment routing/With a segment routing/ s/Segment Identifiers (SIDs) can
> be used/SIDs can be

Re: [Lsr] Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

2022-05-17 Thread Robert Raszuk

Actually I would like to further clarify if workaround 1 is even doable ...

It seems to me that the IP flexalgo paradigm does not have a way for more
granular then destination prefix forwarding.

So if I have http traffic vs streaming vs voice going to the same load
balancer (same dst IP address) there seems to be no way to map some
traffic (based on say port number) to take specific topology.

That's pretty coarse and frankly very limiting for applicability of IP
flex-algo. If I am correct the draft should be very explicit about this
before publication.

Kind regards
R.

On Tue, May 17, 2022 at 12:01 PM Robert Raszuk  wrote:

> Folks,
>
> A bit related to Aijun's point but I have question to the text from the
> draft he quoted:
>
>In cases where a prefix advertisement is received in both a IPv4
>Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability
>TLV, the IPv4 Prefix Reachability advertisement MUST be preferred
>when installing entries in the forwarding plane.
>
> Does this really mean that I can not for a given prefix say /24 use
> default topology for best effort traffic and new flex-algo topology for
> specific application ?
>
> Is the "workaround 1" to always build two new topologies for such /24
> prefix (one following base topo and one new) and never advertise it in base
> topology ?
>
> Is the "workaround 2" to forget about native forwarding and use for
> example SR and mark the packets such that SID pool corresponding to base
> topology forwarding will be separate from SID pool corresponding to new
> flex-algo topology ?
>
> Many thx,
> Robert
>
>
> -- Forwarded message -
> From: Acee Lindem via Datatracker 
> Date: Mon, May 16, 2022 at 3:36 PM
> Subject: [Lsr] Publication has been requested for
> draft-ietf-lsr-ip-flexalgo-06
> To: 
> Cc: , , , <
> lsr@ietf.org>
>
>
> Acee Lindem has requested publication of draft-ietf-lsr-ip-flexalgo-06 as
> Proposed Standard on behalf of the LSR working group.
>
> Please verify the document's state at
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Fwd: Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

2022-05-17 Thread Robert Raszuk

Folks,

A bit related to Aijun's point but I have question to the text from the
draft he quoted:

   In cases where a prefix advertisement is received in both a IPv4
   Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability
   TLV, the IPv4 Prefix Reachability advertisement MUST be preferred
   when installing entries in the forwarding plane.

Does this really mean that I can not for a given prefix say /24 use default
topology for best effort traffic and new flex-algo topology for specific
application ?

Is the "workaround 1" to always build two new topologies for such /24
prefix (one following base topo and one new) and never advertise it in base
topology ?

Is the "workaround 2" to forget about native forwarding and use for example
SR and mark the packets such that SID pool corresponding to base topology
forwarding will be separate from SID pool corresponding to new flex-algo
topology ?

Many thx,
Robert


-- Forwarded message -
From: Acee Lindem via Datatracker 
Date: Mon, May 16, 2022 at 3:36 PM
Subject: [Lsr] Publication has been requested for
draft-ietf-lsr-ip-flexalgo-06
To: 
Cc: , , , <
lsr@ietf.org>


Acee Lindem has requested publication of draft-ietf-lsr-ip-flexalgo-06 as
Proposed Standard on behalf of the LSR working group.

Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

2022-05-17 Thread Dongjie (Jimmy)

Hi Adrian, 

Thanks a lot for your detailed review. All your comments and suggestions look 
good and we will produce a new revision to incorporate them. 

And please see replies to some points inline:

Best regards,
Jie

> -Original Message-
> From: Adrian Farrel [mailto:adr...@olddog.co.uk]
> Sent: Monday, May 16, 2022 7:22 PM
> To: lsr@ietf.org
> Cc: draft-zhu-lsr-isis-sr-vtn-flexa...@ietf.org
> Subject: FW: A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04
> 
> Hi LSR and draft authors,
> 
> I read this draft, and it seems to me that it provides a useful transitional
> mechanism. It can obviously only support a relatively small number of VTNs
> (128 due to the limited number of Flex-Algos the network devices can
> support), but it looks to be a worthwhile first step because it can be 
> achieved
> with a very minor control plane extension.
> 
> Perhaps this document is a good first step while we work on a longer term
> and more scalable control plane solution. It would also give us the chance to
> determine the level of interest in VTNs.

Indeed, this is exactly the purpose of this document.

> 
> My comments, below, are mainly editorial, but there are a couple of issues
> around the use of the E flag.
> 
> Best,
> Adrian
> 
> (PS. For those of you saying "What's a VTN?" the "Virtual Transport
> Network"
> is a network construct described in the TEAS WG to support Enhanced VPNs
> (https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/) and network
> slicing
> (https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/)
> where it maps to a "Network Resource Partition".)
> 
> ===
> 
> As currently defined, I think this document needs to update RFC 8668. This is
> because that RFC says that other flags in the flag field of the Parent L3
> Neighbor Descriptor in the L2 Bundle Member Attributes TLV "MUST be
> ignored".
> 
> That's easy enough to handle:
> - You add the "updates 8668" element to the XML
> - You add a final paragraph to the Abstract to say
> This document updates RFC 8668 by defining a new flag in the Parent
> L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV.
> - You add a final paragraph to the Introduction to say
> This document updates [RFC8668] by defining a new flag in the Parent
> L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV.
> [RFC8668] states that all bit fields not defined in that document
> "MUST be set to zero on transmission and ignored on receipt".
> Section 3 of this document defines a new flag and specifies both
> when it is set and how it should be processed.
> 
> However, a purist might point out that RFC 8668 should be fixed so that:
> 
> - The unused bits are defined as reserved for future use
> - The text should be updated to describe how the bits are set and handled
>   by implementations that don't understand them
> - There should be an IANA registry for the bits
> 
> You're not responsible for fixing RFC 8668, but you could if you want to.
> 
> Making this document an "update" is also important because of the absence
> of an IANA registry -- it is important to provide a way for people to track 
> the
> bits so that there is no collision when another bit is defined.
> 
> You could use definitely use this document to create the necessary IANA
> registry, even if you are not fixing the other parts of 8668.

Thanks for your suggestion, we will make this document an update of RFC 8668 to 
help track the new flag.


> 
> ---
> 
> Would be worth expanding "VTN" in the title to read...
>   Using Flex-Algo for Segment Routing based Virtual Transport Networks
> 
> ---
> 
> Abstract
> 
> The first mention of "Flex-Algo" needs to have some explanation of the
> concept. Not many words, but something like...
> 
> OLD
>The topological constraints of a VTN can be defined using Flex-Algo.
> NEW
>The topological constraints of a VTN can be defined using Flex-Algo,
>a mechanism to provide distributed constraint-path computation.
> END

We will add some description about Flex-Algo. 


> ---
> 
> Abstract
> 
> "SR" should be spelled out as "Segment Routing (SR)"
> 
> ---
> 
> Abstract
> 
> s/L2 bundle/L2 bundles/
> 
> ---
> 
> 1.
> 
> The word "traditional" has other meanings in American English and we are
> now asked to avoid using it.
> 
> OLD
>than that can be provided with traditional overlay VPNs.
> NEW
>than that could be provided with existing overlay VPNs techniques.
> END

OK, will make the change accordingly.

> 
> ---
> 
> 1.
> 
> s/resource-aware SIDs/resource-aware segment identifiers (SIDs)/ s/With
> segment routing/With a segment routing/ s/Segment Identifiers (SIDs) can
> be used/SIDs can be used/ s/using control plane/using the control plane/
> s/scalable Segment Routing (SR)/scalable SR/ s/a unique Flex-Algo/a unique
> Flex-Algo [I-D.ietf-lsr-flex-algo]/
> 
> ---
> 
> Section 1 has just one sentence on the purpose and content of this
> document.
> 
>This

Re: [Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

Re: [Lsr] Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

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

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

Re: [Lsr] Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

Re: [Lsr] Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

Re: [Lsr] Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

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

Re: [Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

Re: [Lsr] Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

[Lsr] Fwd: Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

Re: [Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

12 matches

Site Navigation

Mail list logo

Footer information