Hi Jie,
please see inline:
On 12/03/2021 09:03, Dongjie (Jimmy) wrote:
Hi Peter,
Thanks for your comments. Please see some replies inline:
-----Original Message-----
From: Lsr [mailto:[email protected]] On Behalf Of Peter Psenak
Sent: Tuesday, March 9, 2021 5:46 PM
To: [email protected]
Subject: [Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo
Dear authors,
here are couple of comments to draft-zhu-lsr-isis-sr-vtn-flexalgo:
1. whether we want to flood VTN specific link data in IGPs or not is something
that deserves its own discussion.
IGP as one option can be used to distribute the VTN specific link information
among network nodes, and some of these nodes could further distribute this
information to a network controller using BGP-LS. This is similar to the
distribution and collection of the TE link attributes of the underlay network.
I would say the need to distribute VTN specific link information
requires a broader discussion. We already advertise per instance, per
area, per topology, per application link attributes. Adding yet another
dimension needs a careful thinking.
2. Nevertheless, the proposed encoding does not seem to be a fortunate one:
a) it hijacks the L2 bundle member TLV for VTN data. I don't see the need for
that.
It is considered as one option to advertise the VTN specific link information
when Flex-Algo ID is re-used to identify a VTN, as there is no existing
mechanism to advertise per-Flex-Algo link attributes (this is a difference
between MT and Flex-Algo). And based on the L2 bundle mechanism, only minor
extension is needed.
the fact that there are no link attributes per each Flex-algo ID is a
feature, not a miss.
b) the proposed mechanism to associate the VTN specific link data with the VTN
itself by the use of the link affinities is a very user unfriendly way of doing
it. If
the VTN need only the low latency optimization, provisioning additional
affinities seems like a unnecessary provisioning price that would need to be
paid
by the user for the encoding deficiency. You want to flood the VTN specific link
data, put the VTN ID in it.
A VTN is associated with not only the metric types defined in the Flex-Algo, it
is also associated with a subset of network resources. Thus different VTNs with
low latency optimization may need to correlate with different set of resources
for packet forwarding, hence different Admin Groups are needed to distinguish
the different set of link attributes of a L3 link. Using Admin Group (link
affinity) to correlate the link attributes with a Flex-Algo is the mechanism
introduced in the Flex-Algo base document, this document tries to reuse the
existing mechanisms when possible.
not really. Flex-algo specification does not make any correlation
between any link attribute and Flex-algo ID. It can not, as the same
link attributes may be used by many Flex-Algo IDs. Flex-algo uses link
attributes during calculation but these attributes are not tight to any
specific Flex-algo ID.
thanks,
Peter
Introducing a VTN-ID is another option, which would require a little more
extensions. That mechanism is described in draft-dong-lsr-sr-for-enhanced-vpn,
which is targeted to provide a more scalable solution with the additional
protocol extensions.
Hope this provides some background about this design.
Best regards,
Jie
thanks,
Peter
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
