Re: [spring] I-D Action: draft-ietf-idr-performance-routing-02.txt

"UTTARO, JAMES" <[email protected]>
Newsgroups gmane.ietf.idr,gmane.ietf.spring
Message-ID <B17A6910EEDD1F45980687268941550F4DA16463@MISOUT7MSGUSRCD.ITServices.sbc.com>
At the time the notion was that one could define addl TLVs to suit one's routing design.. The use case I had and still do in mind is a BGP 3107 topology to carry NHs across a set of stripped IGPs, this seems to deviate from that model.

Thanks,
	Jim Uttaro

-----Original Message-----
From: spring <[email protected]> On Behalf Of Ondrej Zajicek
Sent: Wednesday, October 16, 2019 5:37 AM
To: 徐小虎(义先) <[email protected]>
Cc: idr <[email protected]>; SPRING WG List <[email protected]>
Subject: Re: [spring] [Idr] I-D Action: draft-ietf-idr-performance-routing-02.txt

Hi

My main objection to the draft is it uses separate SAFI to signal that
latency based routing is used. I don't think that is a good idea. Latency
based routing is a general concept, which makes sense to use with several
existing SAFIs (at least 1, 4 and 128). Whether or not announce and
use NETWORK_LATENCY TLV should be an independent session property, like
using AIGP TLV or e.g. ADD-PATH extension.

This is an issue that was underspecified in RFC 7311, just kept by
configuration of both sides. Perhaps we need a new capability to specify
which AIGP TLVs (if any) are supposed to be used on the session, so it
can be negotiated automatically like ADD-PATH.

-- 
Ondrej 'Santiago' Zajicek (email: [email protected])

_______________________________________________
spring mailing list
[email protected]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=nTDIog7BhaHv2SH9PKmzhZAYEnJisvMqEfHsCyZoQ2E&s=fzT3zdTC_W3QtjsM2DSzNWzm3QE36Ug8Vc6zI1Mjwbo&e=
_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.