[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-ospf
Subject:    Re: [Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo
From:       Peter Psenak <ppsenak=40cisco.com () dmarc ! ietf ! org>
Date:       2021-03-12 11:40:44
Message-ID: c9da0fd8-17e1-8f8a-c400-aee5b739da22 () cisco ! com
[Download RAW message or body]

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:lsr-bounces@ietf.org] On Behalf Of Peter Psenak
> > Sent: Tuesday, March 9, 2021 5:46 PM
> > To: lsr@ietf.org
> > 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
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
> 
> 

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


[prev in list] [next in list] [prev in thread] [next in thread]