Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

[Robert Raszuk <[e-mail]>]

Well Jeff if you would completely remove CSPF and Flex Algo from IGPs I am
fully with you.

But till we still have them running in the routers I am of the opinion that
we need both ... bigger and slower PCE based path computation and
sufficient information (not only static data) for routers itself to be able
to adjust forwarding state based on the live path constraints.

I realize I am thinking outside of the box here but hopefully one day this
will become a norm rather then abstraction :)

Best,
R.,

On Fri, Apr 3, 2020 at 12:24 AM Jeff Tantsura <[e-mail]>
wrote:

> Robert,
>
> That is why we have a possibility to signal in-band/as per device data
> that could be used by PCE to compute a path that meets the constrains (RFC 7471/7810),
> e.g per node BW  reserved/available or cumulative delay, and similar,
> computed by the PCE.
> However if the objective functions used by CSPF are coming from outside
> (end2end latency measurement/$$ of a link  as an example) we don’t feed
> them back into IGP, telemetry analysis (done by an external system) are of
> no business of IGP and should be fed (normalized) into PCE directly.
> We are not discussing the value of telemetry, which is obvious, but need
> to autodiscover telemetry capability’s and feed (pollute) them into
> IGP->BGP-LS->controller.
> I don’t see how this information would be used in route/path computation
> and hence IMHO it doesn’t belong in IGP. Given the need for configuration
> (besides ability to support particular technology) makes this a clear
> candidate for management plane operations. (Chris’ comment about YANG)
>
> Cheers,
> Jeff
> On Apr 2, 2020, 2:17 PM -0700, Robert Raszuk <[e-mail]>, wrote:
>
> Jeff.
>
> > The role of a routing protocol is to distribute: reachability (doh :-))
> > *and any additional data that could influence routing decision wrt
> reachability.  *
>
> The bolded text is precisely the point here.
>
> So let me provide a very simple example.
>
> Today routers already compute CSPF. Moreover today routers are asked to
> use custom/flexible algorithm to choose reachability paths.
>
> So just imagine an operator who says:
>
> Please compute my SPT with the consideration that end to end inband jitter
> is not greater then 10 ms otherwise I do not want to see nodes which do not
> meet that criteria in the reachability graph for application X.
>
> or
>
> Please compute my SPT with the consideration that end to end drop rate is
> not greater then  5pps otherwise I do not want to see nodes which do not
> meet that criteria in the reachability graph for application Y.
>
> etc ...
>
> If you consider such constrains to provide reachability for applications
> you will likely see value that in-situ telemetry is your friend here.
> Really best friend as without him you can not do the proper end to end path
> exclusion for SPT computations.
>
> Hint: All per link extensions which were added to IGPs are not going to
> help here as drops or jitter may equally happen in the routers fabric on
> fabric to LC boundaries or on the line cards and links. So you need end to
> end test stream.
>
> Many thx,
> R.
>
> PS. As we are talking LSR here it is strange that joining virtual LSR
> meeting is not for everyone. I was waiting and tried three times today for
> host approval to join which was not granted.
>
> On Thu, Apr 2, 2020 at 11:00 PM Jeff Tantsura <[e-mail]>
> wrote:
>
>> Robert,
>>
>> This is unnecessary leakage of management plane into control plane.
>> The role of a routing protocol is to distribute: reachability (doh :-))
>> and any additional data that could influence routing decision wrt
>> reachability.
>> There are precedences of using IGP’s for different tasks, e.g. RFC 5088
>> and similar, however should we do it again?
>>
>> Specifically to use case described - I really don’t see how this
>> information would be used in routing decisions (PCE computation). Moreover,
>> if the end-goal is to build a connected graph of the devices that have a
>> coherent iFIT feature set it would require reoptimization on every change
>> and quite complex computation logic (talking SR - on top of regular
>> constrains, MSD, etc).I’d also think that there’s mandatory configuration
>> of name-spaces and features supported, in other words - autodiscovery is
>> meaningless, it would still require as per device configuration (hello
>> YANG). Most of telemetry solutions are designed to pass thought nodes that
>> don’t support it transparently, so the real requirement is really to know
>> the sink-node (the one that is egress of the telemetry domain and must
>> remove all additional encapsulations).
>>
>> As to the last point - we already have a kitchen-sink routing protocol
>>  ;-)
>>
>> Cheers,
>> Jeff
>> On Apr 2, 2020, 6:10 AM -0700, Robert Raszuk <[e-mail]>, wrote:
>>
>>
>> Hi Les,
>>
>> Ok very well.
>>
>> So till this draft provides a text or reference to some other document
>> how IGPs may use inband telemetry data for real path selection it does not
>> fit to LSR charter. Fair.
>>
>> Hi Chris,
>>
>> I am afraid we are looking at this from completely different
>> perspectives.
>>
>> I consider this data to be a necessity for routing and you simply treat
>> it as some opaque telemetry. If we would think of it in the latter sense
>> sure you would be right. IGP is not a configuration push protocol.
>> Sufficient to observe how BGP became one :)
>>
>> Many thx,
>> R.
>>
>>
>> On Thu, Apr 2, 2020 at 8:46 AM Les Ginsberg (ginsberg) <
>> [e-mail]> wrote:
>>
>>> Robert -
>>>
>>> First, +1 to what Chris has said.
>>>
>>> There is nothing in the lfit-capability draft that defines any
>>> information that can be used by IGPs to do what you suggest.
>>> Perhaps it is possible that information gleaned via a telemetry
>>> application could be used by the IGPs to do something like what you suggest
>>> - but this draft is not discussing/defining that. It is simply proposing to
>>> advertise information about the capabilities of the lfit application on a
>>> given node..
>>>
>>>    Les
>>>
>>> > -----Original Message-----
>>> > From: Christian Hopps <[e-mail]>
>>> > Sent: Thursday, April 02, 2020 5:13 AM
>>> > To: Robert Raszuk <[e-mail]>
>>> > Cc: Christian Hopps <[e-mail]>; Les Ginsberg (ginsberg)
>>> > <[e-mail]>; wangyali <[e-mail]>; Acee Lindem
>>> > (acee) <[e-mail]>; lsr@ietf..org <[e-mail]>; Tianran Zhou
>>> > <[e-mail]>
>>> > Subject: Re: [Lsr] A new version of I-D,
>>> draft-liu-lsr-isis-ifit-node-capability-02
>>> >
>>> > We have defined a perfectly acceptable and quite powerful way to do
>>> query
>>> > and configuration for routers, it's YANG. I'd like to hear why the the
>>> IETF
>>> > standard mechanism for query and configuration can't work for this
>>> > application.
>>> >
>>> > Telemetry is important, I don't think anyone has said or would say
>>> that it isn't,
>>> > but that seems orthogonal to this discussion.
>>> >
>>> > Thanks,
>>> > Chris.
>>> > [as WG member]
>>> >
>>> >
>>> > > On Apr 2, 2020, at 5:17 AM, Robert Raszuk <[e-mail]> wrote:
>>> > >
>>> > > Hi Les,
>>> > >
>>> > > I would like to respectfully disagree with your assessment.
>>> > >
>>> > > The fact that today's IGP (or for that matter BGP) routing is static
>>> from the
>>> > perspective of not taking into consideration real performance
>>> measurements
>>> > from the data plane to me is a bug not a feature.
>>> > >
>>> > > Building SPT based on static link metrics which in vast majority of
>>> cases
>>> > today are emulated circuits on someone else IP backbone. It was a
>>> great idea
>>> > when you constructed the network with connection oriented paradigm
>>> > (Sonet,SDH, dark fiber, TDM ...) not connection less often best effort
>>> one.
>>> > >
>>> > > So I find this proposal very useful and would vote for adopting it
>>> in LSR WG.
>>> > To me in-situ telemetry is not just some monitoring tool. It is an
>>> extremely
>>> > important element to influence how we compute reachability or at least
>>> how
>>> > we choose active forwarding paths from protocol RIBs to main RIB.
>>> > >
>>> > > If we extended IGPs to carry TE information, if we extended them to
>>> > enable flexible algorithm based path computation I fail to understand
>>> why
>>> > would we resist to natively enable all of the above with getting the
>>> inputs
>>> > from real networks to be used as to the parameters to the above
>>> mentioned
>>> > tools.
>>> > >
>>> > > Kind regards,
>>> > > R.
>>> > >
>>> > > On Thu, Apr 2, 2020 at 8:32 AM Les Ginsberg (ginsberg)
>>> > <ginsberg=[e-mail]> wrote:
>>> > > Yali -
>>> > >
>>> > > There is a very significant difference between having IGPs advertise
>>> an
>>> > identifier for a service that they use as clients (BFD) and having IGPs
>>> > advertise a set of capabilities/options for a telemetry application
>>> which has
>>> > no direct bearing on the function of the routing protocol.
>>> > >
>>> > > You are not the first to find using IGPs to flood application
>>> information very
>>> > convenient.  But this is not the appropriate role for the IGPs and
>>> over the
>>> > years we have consistently resisted attempts to do so.
>>> > >
>>> > > Everything advertised in Router Capabilities today has some close
>>> > relationship with the operation of the protocol. Do some of the
>>> existing
>>> > advertisements "bend the rules" a bit more than I would prefer? Yes -
>>> but
>>> > there has always been at least a close relationship to routing protocol
>>> > function.
>>> > > Here there is none.
>>> > >
>>> > > If you feel compelled to use IGPs to advertise application
>>> information, you
>>> > have RF6823 available (at least for IS-IS). But it is a "high bar"
>>> since it requires
>>> > you also to use a separate IS-IS instance dedicated to advertising the
>>> > application information (see RFC8202).
>>> > > I think Chris Hopps's suggestion to use Netconf/YANG to
>>> configure/retrieve
>>> > what you need is most likely more attractive - but I will leave that
>>> for you to
>>> > decide.
>>> > >
>>> > > Using IGP Router Capabilities here is wrong in my view.
>>> > >
>>> > >    Les
>>> > >
>>> > >
>>> > > > -----Original Message-----
>>> > > > From: wangyali <[e-mail]>
>>> > > > Sent: Wednesday, April 01, 2020 8:12 PM
>>> > > > To: Acee Lindem (acee) <[e-mail]>; Les Ginsberg (ginsberg)
>>> > > > <[e-mail]>; Christian Hopps <[e-mail]>
>>> > > > Cc: [e-mail]; Tianran Zhou <[e-mail]>
>>> > > > Subject: 答复: [Lsr] A new version of I-D,
>>> draft-liu-lsr-isis-ifit-node-
>>> > capability-
>>> > > > 02
>>> > > >
>>> > > > Hi Acee, Chris and Les,
>>> > > >
>>> > > > This is Yali. Many thanks for your kind comments and suggestion.
>>> > > >
>>> > > > Besides of signaling MSD by IGP node CAPABILITY TLV, we learned
>>> that
>>> > > > there's another RFC7883 that advertising S-BFD discriminators in
>>> IS-IS. In
>>> > my
>>> > > > understand, BFD is a protocol to detect faults in the
>>> bidirectional path
>>> > > > between two forwarding engines, including interface, data links,
>>> etc.
>>> > > >
>>> > > > Similarly, IFIT provides a complete framework of a family of
>>> on-path
>>> > > > telemetry techniques, which are used to monitoring performance
>>> metrics
>>> > of
>>> > > > service flows, e.g. packet loss, delay. So we consider there's a
>>> same
>>> > > > methodology with S-BFD that advertising IFIT node capabilities.
>>> > > >
>>> > > > Please let us know your comments and opinion. Thanks.
>>> > > >
>>> > > > Best regards,
>>> > > > Yali
>>> > > >
>>> > > > -----邮件原件-----
>>> > > > 发件人: Acee Lindem (acee) [mailto:[e-mail]]
>>> > > > 发送时间: 2020年4月1日 20:29
>>> > > > 收件人: Tianran Zhou <[e-mail]>; Les Ginsberg
>>> > (ginsberg)
>>> > > > <[e-mail]>; Christian Hopps <[e-mail]>
>>> > > > 抄送: [e-mail]; wangyali <[e-mail]>
>>> > > > 主题: Re: [Lsr] A new version of I-D,
>>> draft-liu-lsr-isis-ifit-node-capability-
>>> > 02
>>> > > >
>>> > > > Speak as WG Member...
>>> > > >
>>> > > > On 4/1/20, 8:08 AM, "Acee Lindem (acee)" <[e-mail]> wrote:
>>> > > >
>>> > > >     There is also a difference between some of the existing
>>> applications
>>> > > > advertised in IGP capabilities. For example, MSD is used with the
>>> routing
>>> > > > information to construct SR paths. The information for all these
>>> OAM
>>> > > > mechanisms doesn't share this affinity. Also, it seems like a
>>> slippery slope
>>> > in
>>> > > > what is needed for each of the mechanism.
>>> > > >     Thanks,
>>> > > >     Acee
>>> > > >
>>> > > >     On 4/1/20, 4:01 AM, "Lsr on behalf of Tianran Zhou" <lsr-
>>> > [e-mail]
>>> > > > on behalf of [e-mail]> wrote:
>>> > > >
>>> > > >         Hi Les,
>>> > > >
>>> > > >         Thanks very much for your suggestion. I have a quick look
>>> at rfc6823.
>>> > > > Sounds like a good idea. I will think about it.
>>> > > >
>>> > > >         Cheers,
>>> > > >         Tianran
>>> > > >
>>> > > >         -----Original Message-----
>>> > > >         From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
>>> > > >         Sent: Wednesday, April 1, 2020 1:47 PM
>>> > > >         To: Tianran Zhou <[e-mail]>; Christian Hopps
>>> > > > <[e-mail]>
>>> > > >         Cc: wangyali <[e-mail]>; [e-mail]
>>> > > >         Subject: RE: [Lsr] A new version of I-D,
>>> draft-liu-lsr-isis-ifit-node-
>>> > > > capability-02
>>> > > >
>>> > > >         Tianran -
>>> > > >
>>> > > >         I am very much in agreement with the points Chris has made.
>>> > > >
>>> > > >         IGPs do not exist to advertise capabilities/configure
>>> applications -
>>> > which
>>> > > > seems to me to be what you are proposing here.
>>> > > >         The fact that you can easily define the encodings does not
>>> make it
>>> > the
>>> > > > right thing to do.
>>> > > >
>>> > > >         This issue was discussed at length in the context of
>>> > > > https://tools.ietf.org/html/rfc6823 . If you were proposing to use
>>> > GENAPP I
>>> > > > would not object - though I do think Chris has correctly pointed
>>> out that
>>> > > > NETCONF/YANG is likely a more appropriate solution for your use
>>> case.
>>> > > >
>>> > > >            Les
>>> > > >
>>> > > >
>>> > > >         > -----Original Message-----
>>> > > >         > From: Tianran Zhou <[e-mail]>
>>> > > >         > Sent: Tuesday, March 31, 2020 7:53 PM
>>> > > >         > To: Christian Hopps <[e-mail]>
>>> > > >         > Cc: wangyali <[e-mail]>; Les Ginsberg
>>> (ginsberg)
>>> > > >         > <[e-mail]>; [e-mail]
>>> > > >         > Subject: RE: [Lsr] A new version of I-D,
>>> > > >         > draft-liu-lsr-isis-ifit-node-capability-02
>>> > > >         >
>>> > > >         > Hi Chris,
>>> > > >         > Thanks for your quick reply, and please see inline.
>>> > > >         >
>>> > > >         > Cheers,
>>> > > >         > Tianran
>>> > > >         >
>>> > > >         > -----Original Message-----
>>> > > >         > From: Christian Hopps [mailto:[e-mail]]
>>> > > >         > Sent: Wednesday, April 1, 2020 10:00 AM
>>> > > >         > To: Tianran Zhou <[e-mail]>
>>> > > >         > Cc: Christian Hopps <[e-mail]>; wangyali
>>> > > >         > <[e-mail]>; Les Ginsberg (ginsberg)
>>> > > > <[e-mail]>;
>>> > > >         > [e-mail]
>>> > > >         > Subject: Re: [Lsr] A new version of I-D,
>>> > > >         > draft-liu-lsr-isis-ifit-node-capability-02
>>> > > >         >
>>> > > >         >
>>> > > >         >
>>> > > >         > > On Mar 31, 2020, at 9:28 PM, Tianran Zhou
>>> > > > <[e-mail]>
>>> > > >         > wrote:
>>> > > >         > >
>>> > > >         > > ZTR> Let's not boil the ocean to compare NETCONF/YANG
>>> or
>>> > routing
>>> > > >         > protocol, which is better. But I did not see the
>>> modification to
>>> > > >         > routing protocol with some TLVs is a heavy work, or more
>>> complex
>>> > than
>>> > > >         > NETCONF/YANG.  I see both are available and useful.
>>> > > >         >
>>> > > >         > I'm not sure what you mean by boiling the ocean. I'm
>>> saying that
>>> > YANG
>>> > > >         > is built and intended for querying capabilities and
>>> configuring
>>> > > >         > routers. Why isn't that where you are looking first for
>>> configuring
>>> > your
>>> > > > monitoring application?
>>> > > >         >
>>> > > >         > ZTR> I know NETCONF can do both query and configuration.
>>> And I
>>> > > > know
>>> > > >         > resent YANG-Push improvements to reduce the polling.  But
>>> > routing
>>> > > >         > protocol solutions are also widely used for this. There
>>> are already
>>> > > >         > many RFCs and implementation practices. We considered
>>> both
>>> > ways,
>>> > > > and
>>> > > >         > aimed for different scenarios.
>>> > > >         >
>>> > > >         > You don't see the major difference between writing a
>>> YANG model
>>> > vs
>>> > > >         > modifying all of the standard IETF routing protocols?
>>> > > >         >
>>> > > >         > ZTR> I know many differences between NETCONF and routing
>>> > > > protocol.
>>> > > >         > There are many details on both interfaces,
>>> implementations,
>>> > scenarios
>>> > > >         > when comparing them. That's what I mean boil the ocean.
>>> > > >         > Here I do not know what's the "major difference" you
>>> mean?
>>> > > >         >
>>> > > >         > Thanks,
>>> > > >         > Chris.
>>> > > >
>>> > > >         _______________________________________________
>>> > > >         Lsr mailing list
>>> > > >         [e-mail]
>>> > > >         https://www..ietf.org/mailman/listinfo/lsr
>>> <https://www.ietf..org/mailman/listinfo/lsr>
>>> > > >
>>> > > >
>>> > > >
>>> > >
>>> > > _______________________________________________
>>> > > Lsr mailing list
>>> > > [e-mail]
>>> > > https://www.ietf.org/mailman/listinfo/lsr
>>>
>>> _______________________________________________
>> Lsr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>>