Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

Robert Raszuk writes: Les, I don't think this is noise.  Your examples are missing key operational consideration .. Link attribute applicable to ANY application may be advertised well ahead of enabling such application in a network.  So requesting operator to always advertise tuple of app 

Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

I agree with Tony that these other PUB/SUB efforts aren’t directly applicable. I don’t necessarily agree that YANG is evil though  However, note that the I2RS effort (where such a route monitoring capability was envisioned) was for the most part unsuccessful. Thanks, Acee From: Lsr on

Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

Les, I don't think this is noise. Your examples are missing key operational consideration .. Link attribute applicable to ANY application may be advertised well ahead of enabling such application in a network. So requesting operator to always advertise tuple of app + attr is not looking forward

Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

Les, There is clearly a valid case for having attributes common to all applications. Duplicating those on a per application is perhaps a way, but is this the most efficient way encoding wise ? Thx, R. On Fri, Mar 25, 2022 at 1:02 PM Les Ginsberg (ginsberg) wrote: > Robert – > > > > As I have

Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

Robert – As I have stated in my original comments: Existing encoding defined in RFCs 8919/8920 is fully functional i.e., the introduction of ANY application does not add support for deployment scenarios that could not otherwise be supported. I don’t think there is anything else that needs

Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

I am afraid not .. I am exploring how to solve requirement. Proposed method is natural and reuses ASLA encoding. There is apparently a wall this proposal is facing. So trying to see how to bypass that wall (or jump over it). Cheers, R. On Fri, Mar 25, 2022 at 12:50 PM Les Ginsberg (ginsberg)

Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

Robert – I find your post a non-sequitar. ASLA ANY is NOT discussing advertising a new attribute. It is discussing a new format for the ASLA sub-TLV container inside of which link attribute values are advertised. You are off-topic with your post. Les From: Robert Raszuk Sent: Friday,

Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

Hi Les, Let me clarify if I read you correctly ... Are you saying that because quoted RFCs have been published in Oct 2020 no one has a right to define any new standard link attributes any more as implementations are closed ? Including those which would be common to all applications on a link ?

Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

Hi Aijun, > Thanks for your clarification of the NLP mechanism during the meeting. > 1. Regarding to the PUB/SUB model within IETF, there are already some of > them: > 1) https://datatracker.ietf.org/doc/html/rfc8641 > (Subscription to

Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

Shraddha - RFCs 8919/8920 were published in October 2020 - and implementations based on draft versions of those document date back as much as two years before that. They all are written to support the encoding formats defined in the RFCs. The introduction of an additional way of encoding the

Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

I believe we still have an opportunity to simplify ASLA as it is not that widely deployed. The inter-operability issues are almost always due to unclear and ambiguous documentation of standards. All we need is to ensure is that the protocol extensions have unambiguous documentation. The two

Re: [Lsr] draft-lin-lsr-flex-algo-metric-00

Hi Mengxiao, please see inline: On 25/03/2022 07:35, Chenmengxiao wrote: Hi Peter, Thank you for the comments. Time for the presentation is very limited. Glad to receive your comments here. I agree that flex-algo is much easier to deploy and manage than MT, which make it a popular tool

Re: [Lsr] draft-lin-lsr-flex-algo-metric-00

Hi Peter, Thank you for the comments. Time for the presentation is very limited. Glad to receive your comments here. I agree that flex-algo is much easier to deploy and manage than MT, which make it a popular tool now. But I think using algorithm-specific link metric will not cause the