Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt

[Shraddha Hegde]

Authors,

Thanks for the bis version of RFC 8919 and the clarifying text on errata.
The issues raised with respect to the errata have been addressed well in the 
bis version.
However, I believe that the bis version is also an opportunity for us to
address any other ambiguities and clarifications and not just restrict it to 
the raised errata. RFC 8919 is going to serve as base document for many
future applications /attributes and a clear definition and documentation
is necessary for interoperable implementations as well as for future
evolution of the protocol.

I have below comments on the document

1. The definition of what constitutes an application in the scope of this 
document is not
clearly defined in the document. Currently RSVP,SR-TE, LFA, Flex-algo have 
been defined
so it appears that any application that uses TE attributes can be 
defined as a separate application.
The TE mechanisms like RSVP, SR-TE and flex-algo have been defined as 
separate applications
and it appears features having significantly different
forwarding plane is defined as new application. It is not clear if SRv6 
would be 
qualified as a new application. 
LFA for different forwarding planes such as IP, MPLS, SRv6 are not 
separate applications
but LFA is defined as a single application.
I have also seen many drafts confusing application specific to be user 
application.
I  suggest to add a section and describe what is an application clearly 
in the draft that should provide
sufficient input on what can be defined as an application from ASLA 
context in future.


2. "   When SABM or UDABM Length is non-zero and the L-flag is NOT set, all
   applications specified in the bit mask MUST use the link attribute
   advertisements in the sub-TLV."
   Applications such as RSVP, SR-TE, LFA already use legacy advertisements. 
   This document suggests that if any attribute is advertised with an 
application bit set in ASLA
   ASLA advertisements MUST be used by that application.
   Implementations may support ASLA for only some applications. 
   I suggest to add below text.
   
   Until all nodes upgraded to support ASLA for a particular application, 
different values of link attributes
   MUST NOT be advertised for that application in legacy advertisement and ASLA 
advertisements.


Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, June 21, 2022 8:59 AM
To: lsr@ietf.org
Subject: [Lsr] FW: New Version Notification for 
draft-ginsberg-lsr-rfc8919bis-01.txt

[External Email. Be cautious of content]


Folks -

Please note V01 of the RFC8919bis draft has been posted.

This version incorporates comments received from Bruno.

   Les

-Original Message-
From: internet-dra...@ietf.org 
Sent: Monday, June 20, 2022 8:22 PM
To: John Drake ; Les Ginsberg (ginsberg) 
; Peter Psenak (ppsenak) ; Stefano 
Previdi ; Wim Henderickx 
Subject: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt


A new version of I-D, draft-ginsberg-lsr-rfc8919bis-01.txt
has been successfully submitted by Les Ginsberg and posted to the IETF 
repository.

Name:   draft-ginsberg-lsr-rfc8919bis
Revision:   01
Title:  IS-IS Application-Specific Link Attributes
Document date:  2022-06-20
Group:  Individual Submission
Pages:  25
URL:
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ginsberg-lsr-rfc8919bis-01.txt__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlB5e_NMk$
Status: 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlMHc2Gn4$
Html:   
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ginsberg-lsr-rfc8919bis-01.html__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlABYFZnP$
Htmlized:   
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ginsberg-lsr-rfc8919bis__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlJxHVgye$
Diff:   
https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ginsberg-lsr-rfc8919bis-01__;!!NEt6yMaO-gk!GPzaO3U3q5SdDuafGd00fxwDKseki5v69TK_7OWQ6XlbSNK2EwgaJqAIeyd1bbeYOilNpT-2QlLXl7KIf7D24NLUlEG5hZVF$

Abstract:
   Existing traffic-engineering-related link attribute advertisements
   have been defined and are used in RSVP-TE deployments.  Since the
   original RSVP-TE use case was defined, additional applications (e.g.,
   Segment Routing Policy and Loop-Free Alternates) that also make use
   of the link attribute advertisements have been defined.  In cases
   where multiple applications wish to make use 

Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

[Jeffrey Haas]

Tianran,

On Jul 11, 2022, at 10:42 PM, Tianran Zhou 
 wrote:
> 
> Hi Jeff,
>  
> Our work is not to propose a new protocol.
> https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01
>  
> 
> Our idea is to use BMP for IGP monitoring. We just choose BMP as the vehicle.

Thanks for the pointer to this document.  I had not previously read it.

The use case portion of the document is clear and well-written.

I don't pretend to be an expert in any of the IGPs, but here are a few 
observations from my read-through of the document:

- Should the per-adjacency header include something like ifIndex as part of its 
information?  This might help with troubleshooting misconfigured interfaces.
- In places where fields are Reserved, please use text in the form of "MUST be 
set to zero on transmission and SHOULD be ignored on reception".
- Your reason type and statistics type fields should get IANA sections and IANA 
allocation policy for allocating future code points.
- Your statistics TLV could probably be patterned more like that of the main 
BMP RFC.  That would permit more than one statistic to be attached at a time.
   + Statistic Value says that it is always 4 bytes of length.  If it's a fixed 
length, you may not require a length.  But I think you'll want this to be 
variably sized.  Some fields should be a 64-bit gauge; see BMP RFC for examples.
- The document should procedurally describe what happens when a session is 
first established.  For BGP BMP, the full RIB set is exchanged.  For this 
proposal, very likely the intent is that the LSDB is transmitted.  Given the 
incremental nature of IS-IS messages, it may be necessary to describe similar 
"end of rib" procedures that are in the BGP BMP specification in the context of 
your draft.  Afterwards, propagating the raw IS-IS PDUs in your messages will 
likely make sense.

-- Jeff

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

Re: [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

Hi Les,

I agree with your point of view except this statement:

> the consumer now needs to connect to every router in each IGP area (or at
least each router of interest)

Use of Producer's proxy can vastly simplify this if we ever get to
that point.

But yes IMP is just trying to relax BGP from carrying BGP-LS. The only
exception in the current version of the spec is to optionally share local
configuration - which I thought would be helpful. But I am not attached to
it :)

To your point on network management do you think BMP is a network
management protocol ? It reports local RIBs, it reports peer state etc ...

I think there is no clear line here what is and what is not a network mgmt.
And depending who you ask you will get a different answer. Maybe this is
why network management is in such a great shape today :)

Many thx,
Robert








On Tue, Jul 12, 2022 at 4:03 PM Les Ginsberg (ginsberg) 
wrote:

> Hannes -
>
> Thanx for the perspective.
> Your post reminds me of something I wanted to say.
>
> This discussion was started to discuss alternatives to BGP-LS.
> It has quickly broadened to include discussion of what I would call
> network management.
> This is fine - if the community wants to look at both use cases I have no
> objection.
> But I think it is important to understand the difference in requirements.
>
> The consumer of BGP-LS needs to acquire the topology information for
> multiple IGP areas/domains. To get this, the consumer only needs to connect
> to a small number of ABRs/IGP area.
> And currently there is only one standardized way to do this (RFC 7752).
>
> However, once we start talking about information which is NOT part of the
> LSDB (e.g., adjacencies, rib contents) the consumer now needs to connect to
> every router in each IGP area (or at least each router of interest) and the
> existing alternatives to support this are a different set (BMP, YANG data
> models, telemetry).
>
> This does not preclude the use of a single "protocol" (such as IMP) to
> support both use cases, but since the requirements are very different I
> would find it easier to have a meaningful discussion if the two use cases
> were discussed in separate threads.
>
> As it seems likely we are headed towards an interim meeting on such topics
> (based on available time and the WG chair comments) I would also like to
> know if both topics are in scope for a common meeting or if they will be
> split into separate meetings. Either way is fine w me.
>
> Thanx.
>
>Les
>
>
>
> > -Original Message-
> > From: Lsr  On Behalf Of Hannes Gredler
> > Sent: Tuesday, July 12, 2022 6:23 AM
> > To: Robert Raszuk 
> > Cc: bruno.decra...@orange.com; lsr ; idr@ietf. org
> > ; Susan Hares 
> > Subject: Re: [Lsr] IGP Monitoring Protocol
> >
> > Hi Robert,
> >
> > When designing BGP-LS we had to make a fundamental choice for expressing
> > an link-state graph.
> > the two models under consideration:
> >
> > 1) encapsulating raw IGP LS PDUs into some NLRI
> > 2) transcoding all elements of a graph (nodes, links, prefixes, node
> attributes
> > and link attributes)
> >into some NLRI
> >
> > We did see some value for getting visibility of serialized LS PDUs
> (proposal 1),
> > but then decided
> > against it as the primary use-case has been to be friendly to controllers
> > where controller developers
> > told us they do not want to to implement each and every protocol specific
> > IGP extension, but rather be comfortable
> > with a "protocol neutral" representation of a LS graph (proposal 2).
> > So here we are - if a certain feature is relevant to a controller, then
> you need
> > to specify a
> > BGP-LS transcoding scheme / TLV - no way around that if you want to be
> > friendly to controller developers.
> > As the IMP proposal stands today there is not much additional value
> > compared to the local-LSDB that BGP-LS provides already.
> >
> > However, for debugging IGPs there is certainly some value in monitoring
> the
> > flooding subsystem.
> > Now if you want to however monitor what's going on at the flooding level
> of
> > your IGP then there is
> > a tad of information missing in the current proposal.
> >
> > For further illustration let me pull-up the BMP analogy, where there is
> a clear
> > per-RIB orientation:
> > e.g. from which peer a NLRI has been received from ?
> >  what NLRI has been sent to particular peer ?
> >  per-peer stats, global stats ?
> >
> > That per-adj related information is IMO missing for IMP to be useful.
> > additional data of interest -> where (interface) and when a LS PDU has
> been
> > received (redundant copies ?), retransmisison stats,
> > differentiate between LSDB-in / LSDB-out, LSDB-self-originated ?
> >
> > I am sure that bruno and his team have way more ideas for data that they
> > would be interested in ;-)
> >
> > /hannes
> >
> > On Fri, Jul 08, 2022 at 09:20:04PM +0200, Robert Raszuk wrote:
> > |Dear LSR WG,
> > |Based on ongoing discussion in respect to the fu

Re: [Lsr] IGP Monitoring Protocol

[Les Ginsberg (ginsberg)]

Hannes -

Thanx for the perspective.
Your post reminds me of something I wanted to say.

This discussion was started to discuss alternatives to BGP-LS.
It has quickly broadened to include discussion of what I would call network 
management.
This is fine - if the community wants to look at both use cases I have no 
objection.
But I think it is important to understand the difference in requirements.

The consumer of BGP-LS needs to acquire the topology information for multiple 
IGP areas/domains. To get this, the consumer only needs to connect to a small 
number of ABRs/IGP area.
And currently there is only one standardized way to do this (RFC 7752).

However, once we start talking about information which is NOT part of the LSDB 
(e.g., adjacencies, rib contents) the consumer now needs to connect to every 
router in each IGP area (or at least each router of interest) and the existing 
alternatives to support this are a different set (BMP, YANG data models, 
telemetry).

This does not preclude the use of a single "protocol" (such as IMP) to support 
both use cases, but since the requirements are very different I would find it 
easier to have a meaningful discussion if the two use cases were discussed in 
separate threads.

As it seems likely we are headed towards an interim meeting on such topics 
(based on available time and the WG chair comments) I would also like to know 
if both topics are in scope for a common meeting or if they will be split into 
separate meetings. Either way is fine w me.

Thanx.

   Les



> -Original Message-
> From: Lsr  On Behalf Of Hannes Gredler
> Sent: Tuesday, July 12, 2022 6:23 AM
> To: Robert Raszuk 
> Cc: bruno.decra...@orange.com; lsr ; idr@ietf. org
> ; Susan Hares 
> Subject: Re: [Lsr] IGP Monitoring Protocol
> 
> Hi Robert,
> 
> When designing BGP-LS we had to make a fundamental choice for expressing
> an link-state graph.
> the two models under consideration:
> 
> 1) encapsulating raw IGP LS PDUs into some NLRI
> 2) transcoding all elements of a graph (nodes, links, prefixes, node 
> attributes
> and link attributes)
>into some NLRI
> 
> We did see some value for getting visibility of serialized LS PDUs (proposal 
> 1),
> but then decided
> against it as the primary use-case has been to be friendly to controllers
> where controller developers
> told us they do not want to to implement each and every protocol specific
> IGP extension, but rather be comfortable
> with a "protocol neutral" representation of a LS graph (proposal 2).
> So here we are - if a certain feature is relevant to a controller, then you 
> need
> to specify a
> BGP-LS transcoding scheme / TLV - no way around that if you want to be
> friendly to controller developers.
> As the IMP proposal stands today there is not much additional value
> compared to the local-LSDB that BGP-LS provides already.
> 
> However, for debugging IGPs there is certainly some value in monitoring the
> flooding subsystem.
> Now if you want to however monitor what's going on at the flooding level of
> your IGP then there is
> a tad of information missing in the current proposal.
> 
> For further illustration let me pull-up the BMP analogy, where there is a 
> clear
> per-RIB orientation:
> e.g. from which peer a NLRI has been received from ?
>  what NLRI has been sent to particular peer ?
>  per-peer stats, global stats ?
> 
> That per-adj related information is IMO missing for IMP to be useful.
> additional data of interest -> where (interface) and when a LS PDU has been
> received (redundant copies ?), retransmisison stats,
> differentiate between LSDB-in / LSDB-out, LSDB-self-originated ?
> 
> I am sure that bruno and his team have way more ideas for data that they
> would be interested in ;-)
> 
> /hannes
> 
> On Fri, Jul 08, 2022 at 09:20:04PM +0200, Robert Raszuk wrote:
> |Dear LSR WG,
> |Based on ongoing discussion in respect to the future of BGP-LS I
> |committed myself to put together an alternate proposal.Â
> |The main goal is not to just publish a -00 version of the draft using
> |different encapsulation. The goal is to make a useful tool which can help
> |to export link state information from network elements as well as assist
> |in network observability.Â
> |The IGP Monitoring Protocol (IMP) draft has been posted and should be
> |available at:
> |https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/
> |One of the key points I wanted to accomplish was full backwards
> |compatibility with TLVs defined for BGP-LS. In parallel other formats
> |(optional) are also supported.Â
> |The PUB-SUB nature or FILTERING capabilities are in the spec however
> as
> |noted in the deployment section there is no expectation that this should
> |be supported directly on routers. Concept of Producer's Proxies has been
> |introduced to support this added functionality as well as provide fan-out
> |(analogy to BGP route reflectors).Â
> |I e

Re: [Lsr] IGP Monitoring Protocol

[Robert Raszuk]

Hey Hannes,

Nice to hear from you !

Yes I was around when this "thing" happened :) Spoke with Stefano a lot
about it ... And as you can see from my proposal I do value a lot of
usability for existing controllers and I do support unification of exported
data into common format. That is why DATA type 1 and 2 use BGP-LS TLVs as
is.

Btw this independent attempt by two WG groups to normalize link state data
is a clear proof that the YANG model has failed here.

> As the IMP proposal stands today there is not much additional value
> compared to the local-LSDB that BGP-LS provides already.

The advantage is that it does not need to touch BGP. Does not need to make
an avalanche of drafts asking for extensions in IDR WG.

See you know the BGP-LS started very innocently .. Let's ship over BGP
session some topology and TE info for ALTO. But now it is growing out of
propositions. And no matter if the info is useful or not we see drafts of
people to just put their name on BGP RFC. And if it approved in LSR WG,
SPRING, DETNET ... the gate is wide open.

Do you think this makes sense ?

> That per-adj related information is IMO missing for IMP to be useful.
> additional data of interest -> where (interface) and when a LS PDU has
been received (redundant copies ?),
> retransmisison stats, differentiate between LSDB-in / LSDB-out,
LSDB-self-originated ?

Now as far as your comment about RIB data - that deserves a separate draft.
On the other hand peer's state I already had in the draft - but decided to
remove it for simplicity. Especially knowing that that peer state will be
reflected in LSDB anyway.

Also most of the info you listed is already available via telemetry. So I
am not trying to duplicate this on purpose. However as I said if anyone
finds it useful I will copy and paste it back to the draft.

Kind regards,
Robert


On Tue, Jul 12, 2022 at 3:23 PM Hannes Gredler  wrote:

> Hi Robert,
>
> When designing BGP-LS we had to make a fundamental choice for expressing
> an link-state graph.
> the two models under consideration:
>
> 1) encapsulating raw IGP LS PDUs into some NLRI
> 2) transcoding all elements of a graph (nodes, links, prefixes, node
> attributes and link attributes)
>into some NLRI
>
> We did see some value for getting visibility of serialized LS PDUs
> (proposal 1), but then decided
> against it as the primary use-case has been to be friendly to controllers
> where controller developers
> told us they do not want to to implement each and every protocol specific
> IGP extension, but rather be comfortable
> with a "protocol neutral" representation of a LS graph (proposal 2).
> So here we are - if a certain feature is relevant to a controller, then
> you need to specify a
> BGP-LS transcoding scheme / TLV - no way around that if you want to be
> friendly to controller developers.
> As the IMP proposal stands today there is not much additional value
> compared to the local-LSDB that BGP-LS provides already.
>
> However, for debugging IGPs there is certainly some value in monitoring
> the flooding subsystem.
> Now if you want to however monitor what's going on at the flooding level
> of your IGP then there is
> a tad of information missing in the current proposal.
>
> For further illustration let me pull-up the BMP analogy, where there is a
> clear per-RIB orientation:
> e.g. from which peer a NLRI has been received from ?
>  what NLRI has been sent to particular peer ?
>  per-peer stats, global stats ?
>
> That per-adj related information is IMO missing for IMP to be useful.
> additional data of interest -> where (interface) and when a LS PDU has
> been received (redundant copies ?), retransmisison stats,
> differentiate between LSDB-in / LSDB-out, LSDB-self-originated ?
>
> I am sure that bruno and his team have way more ideas for data that they
> would be interested in ;-)
>
> /hannes
>
> On Fri, Jul 08, 2022 at 09:20:04PM +0200, Robert Raszuk wrote:
> |Dear LSR WG,
> |Based on ongoing discussion in respect to the future of BGP-LS I
> |committed myself to put together an alternate proposal.
> |The main goal is not to just publish a -00 version of the draft using
> |different encapsulation. The goal is to make a useful tool which can
> help
> |to export link state information from network elements as well as
> assist
> |in network observability.
> |The IGP Monitoring Protocol (IMP) draft has been posted and should be
> |available at:
> |https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/
> |One of the key points I wanted to accomplish was full backwards
> |compatibility with TLVs defined for BGP-LS. In parallel other formats
> |(optional) are also supported.
> |The PUB-SUB nature or FILTERING capabilities are in the spec however
> as
> |noted in the deployment section there is no expectation that this
> should
> |be supported directly on routers. Concept of Producer's Proxies has
> been
> |introduced to support this added 

Re: [Lsr] IGP Monitoring Protocol

[Hannes Gredler]

Hi Robert,

When designing BGP-LS we had to make a fundamental choice for expressing an 
link-state graph.
the two models under consideration:

1) encapsulating raw IGP LS PDUs into some NLRI
2) transcoding all elements of a graph (nodes, links, prefixes, node attributes 
and link attributes)
   into some NLRI

We did see some value for getting visibility of serialized LS PDUs (proposal 
1), but then decided
against it as the primary use-case has been to be friendly to controllers where 
controller developers
told us they do not want to to implement each and every protocol specific IGP 
extension, but rather be comfortable
with a "protocol neutral" representation of a LS graph (proposal 2).
So here we are - if a certain feature is relevant to a controller, then you 
need to specify a
BGP-LS transcoding scheme / TLV - no way around that if you want to be friendly 
to controller developers.
As the IMP proposal stands today there is not much additional value compared to 
the local-LSDB that BGP-LS provides already.

However, for debugging IGPs there is certainly some value in monitoring the 
flooding subsystem.
Now if you want to however monitor what's going on at the flooding level of 
your IGP then there is
a tad of information missing in the current proposal.

For further illustration let me pull-up the BMP analogy, where there is a clear 
per-RIB orientation:
e.g. from which peer a NLRI has been received from ?
 what NLRI has been sent to particular peer ?
 per-peer stats, global stats ?

That per-adj related information is IMO missing for IMP to be useful.
additional data of interest -> where (interface) and when a LS PDU has been 
received (redundant copies ?), retransmisison stats,
differentiate between LSDB-in / LSDB-out, LSDB-self-originated ?

I am sure that bruno and his team have way more ideas for data that they would 
be interested in ;-)

/hannes

On Fri, Jul 08, 2022 at 09:20:04PM +0200, Robert Raszuk wrote:
|Dear LSR WG,
|Based on ongoing discussion in respect to the future of BGP-LS I
|committed myself to put together an alternate proposal. 
|The main goal is not to just publish a -00 version of the draft using
|different encapsulation. The goal is to make a useful tool which can help
|to export link state information from network elements as well as assist
|in network observability. 
|The IGP Monitoring Protocol (IMP) draft has been posted and should be
|available at:
|https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/
|One of the key points I wanted to accomplish was full backwards
|compatibility with TLVs defined for BGP-LS. In parallel other formats
|(optional) are also supported. 
|The PUB-SUB nature or FILTERING capabilities are in the spec however as
|noted in the deployment section there is no expectation that this should
|be supported directly on routers. Concept of Producer's Proxies has been
|introduced to support this added functionality as well as provide fan-out
|(analogy to BGP route reflectors). 
|I encourage everyone interested to take a look and provide comments. At
|this point this document is nothing more than my individual submission.
|Offline I have had few conversations with both operators and vendors
|expressing some level of interest in this work. How we proceed further (if
|at all :) depends on WG feedback. 
|Kind regards,
|Robert.
|PS, I do believe this work belongs in LSR WG pretty squerly. 

| ___
| 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