[Lsr] I-D Action: draft-ietf-lsr-isis-sr-vtn-mt-03.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : Using IS-IS Multi-Topology (MT) for Segment Routing 
based Virtual Transport Network
Authors : Chongfeng Xie
  Chenhao Ma
  Jie Dong
  Zhenbin Li
  Filename: draft-ietf-lsr-isis-sr-vtn-mt-03.txt
  Pages   : 9
  Date: 2022-07-10

Abstract:
   Enhanced VPN (VPN+) aims to provide enhanced VPN service to support
   some application's needs of enhanced isolation and stringent
   performance requirements.  VPN+ requires integration between the
   overlay VPN connectivity and the characteristics provided by the
   underlay network.  A Virtual Transport Network (VTN) is a virtual
   underlay network which consists of a subset of network resources
   allocated on network nodes and links in a customized topology of the
   physical network.  A VTN could be used as the underlay to support one
   or a group of VPN+ services.

   In some network scenarios, each VTN can be associated with a unique
   logical network topology.  This document describes a mechanism to
   build the SR based VTNs using IS-IS Multi-Topology together with
   other well-defined IS-IS extensions.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-sr-vtn-mt/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-sr-vtn-mt-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-sr-vtn-mt-03


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

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

[Robert Raszuk]

Hello Thomas,

Many thx for your comments and review. See inline ..

On Sun, Jul 10, 2022 at 7:13 AM  wrote:

> Dear Robert,
>
>
>
> I reviewed draft-raszuk-lsr-imp-00 and have some firsts comments and
> suggestions.
>
>
>
> First of all, speaking as a network operator who is using BMP to gain
> visibility into the BGP control-plane, seeing the real benefits in
> operation every day, I was looking very forward at IETF seeing a similar
> debugging kind of approach being applied to IGP. You addressed that aspect
> very well. Thank you very much.
>
>
>
> I would like to understand if data type 3-9 described in section 5
> exporting the initial LSDB state when the transport session is being
> established and once fully exported, only the subsequential updates?
> Comparable to route-monitoring in BMP.
>

Yes this is exactly the intention. I will make it more clear in the text.


> In section 5 you are describing data type 7, 8 and 9. Exporting LSDB as
> structured data in YANG. I like the idea in general but doubt that vendors
> will fancy implementations due to the additional I/O impact on the IGP
> process.
>

Well that addition was actually inspired by NOKIA claiming existing support
for it already. I had some discussions with Gunter off line on this.

Furthermore I think telemetry with YANG model is reality. Architecture wise
conversion to YANG does not need to happen in the IGP process itself. There
can be a standalone encoder process which takes feed from IGP process in
any internal format as prepared and packs it into YANG envelops. Many
modern vendors keep all protocol data in a database. The database can on
changes just push "raw" data to such YANG export engine.



> However I think it is very valuable to have the LSDB modelled in YANG for
> data correlation purposes. I suggest that the YANG modelling can happen on
> the producer with data type 7, 8 and 9 or on the receiver side by
> converting data type 3-6 and 10-13 into JSON/XML with the YANG data model.
>

Indeed - that very well can be the case if YANG model for IGPs will be up
to speed with all extensions. And I wanted to try to stay out of
specifying anything how Receiver(s) can consume and modify the data. The
only exception I made here was a statement that DATA Types 1 & 2 are 100%
compatible by design with today's BGP-LS SAFI 71 & 72.



> I suspect that the YANG model itself for modelling the LSDB itself is not
> part of the document, therefore a reference to existing drafts such as
> draft-ietf-ospf-yang would help to better understand that context.
>

Indeed. Will add it !


In section 5 you are describing in figure 2 the data message header. Here I
> suggest to add besides the "Router Identifier" also the "Process
> Identifier" to have the proper device context if more than one process is
> running.
>

Well This is exactly why I have Section 8 :) Do you think in the light of
that section we still need to carry process ID ?


> Lessons learned from BMP is that knowing the control-plane state alone
> isn't enough for proper data correlation for IPFIX Flow Aggregation as
> described in RFC 7015. We need also to understand how (active, passive,
> ecmp, not considered etc.) the path is being installed into the RIB. At BMP
> we are addressing this with draft-cppy-grow-bmp-path-marking-tlv. I
> suggest to include this RIB aspect into IMP from day 1. If that makes sense
> to you as well, I gladly make a proposal.
>

Very interesting comment !  I was thinking for a while if I should add
anything in respect to direct peer's state. I decided not to as part of
that is reflected in LSDB.

You are suggesting the RIB side. I agree on the importance of it but I
think we have two challenges:

A) The RIB interactions with local subsystems are almost always
proprietary. There is no standard there. So may be a bit hard to spec.

B) I think this is very important and to do it well perhaps a separate
document would be a better idea ? RIB Monitoring Protocol (RMP) ?

To your analogy with draft-cppy-grow-bmp-path-marking-tlv it is mainly
about best path selection criteria. Not sure if this is applicable to link
state protocols where protocol's local RIB is a product of SPF algo and
insertion to main RIB is subject to admin distance comparison.


> Regarding the subscription aspect described in section 3. Here I would
> prefer a similar approach as draft-cptb-grow-bmp-yang, being done through a
> NETCONF/RESTCONF configured subscription. A YANG model gives the
> possibility not only to define but also to monitor the subscription which
> is fundamental for proper data collection. 
> draft-arokiarajseda-ipfix-data-export-yang-model
> does the same for IPFIX. For YANG push this is defined in RFC 8641.
>

Please observe that the PUB-SUB subscription only happens at the DATA
Types. That IMO is an IMP property. I agree that what specific elements are
sent can be done with the NETCONF/RESTCONF mechanism.

For now I refrained from adding this to the spec. Only added top

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

[Robert Raszuk]

Hi Yingzhen & OSPF-GT authors,

UP front I must state that anything is better to export IGP information
from routers to interested nodes than using BGP for it.

But to propose using OSPF to transport ISIS seems pretty brave :) I must
admit it !

With that I have few questions to the proposal - assuming the use case is
to distribute links state info in a *point to point* fashion:

A) What is the advantage - if any - to use a new OSPF instance/process to
send link state data over a unicast session to a controller ?

B) The draft is pretty silent on the nature of such a p2p session. Please
be explicit if this is TCP, QUIC or what ?

C) The draft is pretty silent on types of authentication for such sessions.
Security considerations are pretty weak in that respect as well.

   The security considerations for OSPF-GT will be similar to those for
   OSPFv2 [RFC2328] and OSPFv3 [RFC5340].  However, since OSPF-GT is not
   used to update OSPF routing, the consequences of attacks will be
   dependent on advertised non-routing information.

I would actually argue that security considerations of p2p remote neighbors
are actually quite different from security considerations of flooding data.

Along the same lines security is not about protecting your routing ... it
is much more about protecting the entire network by exposing critical
information externally to non authorized parties.

D) Are there any PUB-SUB options possible for OSPF-GT ?

E) Is there any filtering possible for OSPF-GT ?

F) Are you envisioning use of OSPF-GT proxies and if so are you planning to
add this to the document ?

G) How are you going to address Receivers which do not support OSPF-GT
parser ?

H) As you know many operators are attracted to BGP-LS based on the fact
that it offers the same view of information irrespective of what is the
protocol producing the data. Is there some thought on such normalization in
the OSPF-GT proposal ?

I) What's the take of OSPF-GT draft authors on the YANG model in respect of
using it for normalization of exported data ?

To summarize IMHO we should not stretch routing protocols be it OSPF, ISIS
or BGP to be messengers of link state data running and to artificially
force them to run in a point-to-point model between router and controller.

Kind regards,
Robert


On Sun, Jul 10, 2022 at 7:04 AM Yingzhen Qu  wrote:

> Hi,
>
> Since we’re discussing possible solutions, I’d like to bring up the draft:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/
>
> We just submitted a new version. The name of the document is changed to
> “OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT
> as a possible replacement of BGP-LS.
>
> Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate
> routes. It uses the reachability info calculated by routing protocols,
> OSPF, ISIS or static routing etc.. It provides mechanisms to advertise
> non-routing information, and remote neighbor is supported.
>
> Reviews and comments are welcome.
>
>
> Thanks,
> Yingzhen
>
> On Jul 9, 2022, at 5:33 PM, Gyan Mishra  wrote:
>
>
> During the interim meeting we should keep it open to discuss all possible
> alternatives to BGP-LS.
>
> Thanks
>
> Gyan
>
> On Sat, Jul 9, 2022 at 4:45 PM Susan Hares  wrote:
>
>> Jeff:
>>
>>
>>
>> An interim sounds like a good plan.
>>
>>
>>
>> [IDR-chair hat]
>>
>> Alvaro has indicated that since all of the proposal received on the IDR
>> list are new protocol proposals,
>>
>>- Capturing IDR’s input on BGP-LS problems and potential solutions is
>>appropriate for IDR as BGP-LS home.
>>- Refining any potential non-BGP solutions is outside of the scope of
>>IDR.
>>
>>
>>
>> [IDR-chair hat off]
>>
>> [rtgwg WG member]
>>
>> I’d love to attend an interim on this topic.
>>
>>
>>
>> Sue Hares
>>
>>
>>
>>
>>
>> *From:* Jeff Tantsura 
>> *Sent:* Saturday, July 9, 2022 3:40 PM
>> *To:* Robert Raszuk 
>> *Cc:* Acee Lindem (acee) ; lsr ;
>> i...@ietf.org; Susan Hares ; g...@ietf.org g...@ietf.org
>> 
>> *Subject:* Re: [Idr] [Lsr] IGP Monitoring Protocol
>>
>>
>>
>>
>>
>> Speaking as RTGWG chair:
>>
>>
>>
>> Robert - I don’t think we’d have enough time to accommodate a good
>> discussion during IETF114 (we got only 1 slot), however would be happy to
>> provide a platform for an interim.
>>
>> The topic is important and personally (being a very large BGP-LS user)
>> I’d like to see it progressing.
>>
>> Cheers,
>>
>> Jeff
>>
>>
>>
>> On Jul 8, 2022, at 14:44, Robert Raszuk  wrote:
>>
>> 
>>
>> Hi Acee,
>>
>>
>>
>> Yes, by all means input from the operator's community is needed. It can
>> be collected through LSR WG, IDR WG or GROW WG. RTGWG could also
>> contribute. We have already seen input from some operators and their
>> opinion on adding and distributing more and more link state protocol and
>> topology data in BGP. More such input is very welcome.
>>
>>
>>
>> And to your point about RFC9086 - I see nothing wrong in keeping BGP
>> information in BGP. So

Re: [Lsr] [Idr] IGP Monitoring Protocol

[Jeff Tantsura]

Thanks Sue!We don’t have to always reinvent the wheel (at least not every time 😊)I’m aware of at least 1 implementation streaming LSDB for TE consumers (gRPC)There are most probably some other vendor specific encodings/methods to steam to do that I believe – there has been some work around Kafka. Would be great to  do some study around existing solutions, see what worked, what didn’t’ (and why)   Cheers,Jeff From: Susan HaresSent: Saturday, July 9, 2022 1:44 PMTo: Jeff Tantsura; Robert RaszukCc: Acee Lindem (acee); lsr; i...@ietf.org; g...@ietf.org g...@ietf.orgSubject: RE: [Idr] [Lsr] IGP Monitoring Protocol Jeff: An interim sounds like a good plan.   [IDR-chair hat] Alvaro has indicated that since all of the proposal received on the IDR list are new protocol proposals, Capturing IDR’s input on BGP-LS problems and potential solutions is appropriate for IDR as BGP-LS home. Refining any potential non-BGP solutions is outside of the scope of IDR.  [IDR-chair hat off] [rtgwg WG member] I’d love to attend an interim on this topic.  Sue Hares  From: Jeff Tantsura  Sent: Saturday, July 9, 2022 3:40 PMTo: Robert Raszuk Cc: Acee Lindem (acee) ; lsr ; i...@ietf.org; Susan Hares ; g...@ietf.org g...@ietf.org Subject: Re: [Idr] [Lsr] IGP Monitoring Protocol  Speaking as RTGWG chair: Robert - I don’t think we’d have enough time to accommodate a good discussion during IETF114 (we got only 1 slot), however would be happy to provide a platform for an interim.The topic is important and personally (being a very large BGP-LS user) I’d like to see it progressing.Cheers,Jeff On Jul 8, 2022, at 14:44, Robert Raszuk  wrote:Hi Acee,  Yes, by all means input from the operator's community is needed. It can be collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute. We have already seen input from some operators and their opinion on adding and distributing more and more link state protocol and topology data in BGP. More such input is very welcome.  And to your point about RFC9086 - I see nothing wrong in keeping BGP information in BGP. So IGP Monitoring Protocol does not target to shut down BGP-LS. It only aims to remove 100% of non BGP sourced information from it.  Controllers which today listen to BGP-LS need a number of information sources and that spread will only keep increasing as more inputs are becoming necessary for its computations.  Regards,Robert.  On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee)  wrote:Hi Robert, From: Robert Raszuk Date: Friday, July 8, 2022 at 4:36 PMTo: Acee Lindem Cc: lsr , IDR List , Susan Hares Subject: Re: [Lsr] IGP Monitoring Protocol Hi Acee, Thank you. I was not planning to present it in the upcoming IETF.  > Let’s see how many stakeholders actually want to this protocol - then we can talk about a WG home.   An alternative approach could be to see how many stakeholders do not want to further (for no good reason) to trash BGP. That to me would be in this specific case a much better gauge.   In that case, it seems to me that this discussion should be relegated to IDR. Note that there is already non-IGP information transported in BGP-LS, e.g., Egress Peer Engineering (https://datatracker.ietf.org/doc/rfc9086/). I implemented this on our data center routers (NXOS) years and it is solely BGP specific.  Thanks,Acee Kind regards,Robert  On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee)  wrote:Speaking as WG chair:  From: Lsr  on behalf of Robert Raszuk Date: Friday, July 8, 2022 at 3:21 PMTo: lsr Cc: IDR List , Susan Hares Subject: [Lsr] IGP Monitoring Protocol 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 ex

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

[Acee Lindem (acee)]

Hi Robert,

From: Lsr  on behalf of Robert Raszuk 
Date: Sunday, July 10, 2022 at 1:32 PM
To: Yingzhen Qu 
Cc: Gyan Mishra , Susan Hares , IDR 
List , "g...@ietf.org g...@ietf.org" , lsr 

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

Hi Yingzhen & OSPF-GT authors,

UP front I must state that anything is better to export IGP information from 
routers to interested nodes than using BGP for it.

But to propose using OSPF to transport ISIS seems pretty brave :) I must admit 
it !

With that I have few questions to the proposal - assuming the use case is to 
distribute links state info in a point to point fashion:


  1.  What is the advantage - if any - to use a new OSPF instance/process to 
send link state data over a unicast session to a controller ?

It doesn’t have to be unicast, the remote neighbor construct just extends the 
possibilities in OSPF-GT. With an OSPF LSDB, the obvious advantage is all the 
protocol machinery is in place.  Note that LSDB streaming is just but one use 
case and of OSPF-GT. The detals of this application would be specified in a 
separate draft.



  1.  The draft is pretty silent on the nature of such a p2p session. Please be 
explicit if this is TCP, QUIC or what ?

It is OSPF, OSPF has its own protocol identifier (89). This draft just extends 
OSPF. I think you’ve misinterpreted the draft. Hence, your other questions 
aren’t really applicable or would be answered in a draft of the OSPF/IS-IS LSDB 
usage of OSPF-GT.

Thanks,
Acee



C) The draft is pretty silent on types of authentication for such sessions. 
Security considerations are pretty weak in that respect as well.

   The security considerations for OSPF-GT will be similar to those for
   OSPFv2 [RFC2328] and OSPFv3 [RFC5340].  However, since OSPF-GT is not
   used to update OSPF routing, the consequences of attacks will be
   dependent on advertised non-routing information.

I would actually argue that security considerations of p2p remote neighbors are 
actually quite different from security considerations of flooding data.

Along the same lines security is not about protecting your routing ... it is 
much more about protecting the entire network by exposing critical information 
externally to non authorized parties.

D) Are there any PUB-SUB options possible for OSPF-GT ?

E) Is there any filtering possible for OSPF-GT ?

F) Are you envisioning use of OSPF-GT proxies and if so are you planning to add 
this to the document ?

G) How are you going to address Receivers which do not support OSPF-GT parser ?

H) As you know many operators are attracted to BGP-LS based on the fact that it 
offers the same view of information irrespective of what is the protocol 
producing the data. Is there some thought on such normalization in the OSPF-GT 
proposal ?

I) What's the take of OSPF-GT draft authors on the YANG model in respect of 
using it for normalization of exported data ?

To summarize IMHO we should not stretch routing protocols be it OSPF, ISIS or 
BGP to be messengers of link state data running and to artificially force them 
to run in a point-to-point model between router and controller.

Kind regards,
Robert


On Sun, Jul 10, 2022 at 7:04 AM Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:
Hi,

Since we’re discussing possible solutions, I’d like to bring up the draft: 
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/

We just submitted a new version. The name of the document is changed to 
“OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT as a 
possible replacement of BGP-LS.

Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate routes. 
It uses the reachability info calculated by routing protocols, OSPF, ISIS or 
static routing etc.. It provides mechanisms to advertise non-routing 
information, and remote neighbor is supported.

Reviews and comments are welcome.


Thanks,
Yingzhen


On Jul 9, 2022, at 5:33 PM, Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:


During the interim meeting we should keep it open to discuss all possible 
alternatives to BGP-LS.

Thanks

Gyan

On Sat, Jul 9, 2022 at 4:45 PM Susan Hares 
mailto:sha...@ndzh.com>> wrote:
Jeff:

An interim sounds like a good plan.

[IDR-chair hat]
Alvaro has indicated that since all of the proposal received on the IDR list 
are new protocol proposals,
· Capturing IDR’s input on BGP-LS problems and potential solutions is 
appropriate for IDR as BGP-LS home.
· Refining any potential non-BGP solutions is outside of the scope of 
IDR.

[IDR-chair hat off]
[rtgwg WG member]
I’d love to attend an interim on this topic.

Sue Hares


From: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Sent: Saturday, July 9, 2022 3:40 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Acee Lindem (acee) mailto:a...@cisco.com>>; lsr 
mailto:lsr@ietf.org>>; i...@ietf.org; Susan 
Hares mailto:sha...@ndzh.com>>; 
g...@ietf.org g...@ietf.org

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

[Robert Raszuk]

Hi Acee,

My questions were based on section 3.4 of the latest version of the draft.

So I do not think I misinterpreted it.

Thank you,
R.



On Mon, Jul 11, 2022 at 12:38 AM Acee Lindem (acee)  wrote:

> Hi Robert,
>
>
>
> *From: *Lsr  on behalf of Robert Raszuk <
> rob...@raszuk.net>
> *Date: *Sunday, July 10, 2022 at 1:32 PM
> *To: *Yingzhen Qu 
> *Cc: *Gyan Mishra , Susan Hares ,
> IDR List , "g...@ietf.org g...@ietf.org" ,
> lsr 
> *Subject: *Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol
>
>
>
> Hi Yingzhen & OSPF-GT authors,
>
>
>
> UP front I must state that anything is better to export IGP information
> from routers to interested nodes than using BGP for it.
>
>
>
> But to propose using OSPF to transport ISIS seems pretty brave :) I must
> admit it !
>
>
>
> With that I have few questions to the proposal - assuming the use case is
> to distribute links state info in a *point to point* fashion:
>
>
>
>1. What is the advantage - if any - to use a new OSPF instance/process
>to send link state data over a unicast session to a controller ?
>
>
>
> It doesn’t have to be unicast, the remote neighbor construct just extends
> the possibilities in OSPF-GT. With an OSPF LSDB, the obvious advantage is
> all the protocol machinery is in place.  Note that LSDB streaming is just
> but one use case and of OSPF-GT. The detals of this application would be
> specified in a separate draft.
>
>
>
>
>
>1. The draft is pretty silent on the nature of such a p2p session.
>Please be explicit if this is TCP, QUIC or what ?
>
>
>
> It is OSPF, OSPF has its own protocol identifier (89). This draft just
> extends OSPF. I think you’ve misinterpreted the draft. Hence, your other
> questions aren’t really applicable or would be answered in a draft of the
> OSPF/IS-IS LSDB usage of OSPF-GT.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
>
>
> C) The draft is pretty silent on types of authentication for such
> sessions. Security considerations are pretty weak in that respect as well.
>
>
>
>The security considerations for OSPF-GT will be similar to those for
>OSPFv2 [RFC2328] and OSPFv3 [RFC5340].  However, since OSPF-GT is not
>used to update OSPF routing, the consequences of attacks will be
>dependent on advertised non-routing information.
>
>
>
> I would actually argue that security considerations of p2p remote
> neighbors are actually quite different from security considerations of
> flooding data.
>
>
>
> Along the same lines security is not about protecting your routing ... it
> is much more about protecting the entire network by exposing critical
> information externally to non authorized parties.
>
>
>
> D) Are there any PUB-SUB options possible for OSPF-GT ?
>
>
>
> E) Is there any filtering possible for OSPF-GT ?
>
>
>
> F) Are you envisioning use of OSPF-GT proxies and if so are you planning
> to add this to the document ?
>
>
>
> G) How are you going to address Receivers which do not support OSPF-GT
> parser ?
>
>
>
> H) As you know many operators are attracted to BGP-LS based on the fact
> that it offers the same view of information irrespective of what is the
> protocol producing the data. Is there some thought on such normalization in
> the OSPF-GT proposal ?
>
>
>
> I) What's the take of OSPF-GT draft authors on the YANG model in respect
> of using it for normalization of exported data ?
>
>
>
> To summarize IMHO we should not stretch routing protocols be it OSPF, ISIS
> or BGP to be messengers of link state data running and to artificially
> force them to run in a point-to-point model between router and controller.
>
>
>
> Kind regards,
>
> Robert
>
>
>
>
>
> On Sun, Jul 10, 2022 at 7:04 AM Yingzhen Qu 
> wrote:
>
> Hi,
>
>
>
> Since we’re discussing possible solutions, I’d like to bring up the draft:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/
>
>
>
> We just submitted a new version. The name of the document is changed to
> “OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT
> as a possible replacement of BGP-LS.
>
>
>
> Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate
> routes. It uses the reachability info calculated by routing protocols,
> OSPF, ISIS or static routing etc.. It provides mechanisms to advertise
> non-routing information, and remote neighbor is supported.
>
>
>
> Reviews and comments are welcome.
>
>
>
>
>
> Thanks,
>
> Yingzhen
>
>
>
> On Jul 9, 2022, at 5:33 PM, Gyan Mishra  wrote:
>
>
>
>
>
> During the interim meeting we should keep it open to discuss all possible
> alternatives to BGP-LS.
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Sat, Jul 9, 2022 at 4:45 PM Susan Hares  wrote:
>
> Jeff:
>
>
>
> An interim sounds like a good plan.
>
>
>
> [IDR-chair hat]
>
> Alvaro has indicated that since all of the proposal received on the IDR
> list are new protocol proposals,
>
> · Capturing IDR’s input on BGP-LS problems and potential
> solutions is appropriate for IDR as BGP-LS home.
>
> · Refining a

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-10.txt

[Aijun Wang]

Hi, All:

We have submitted the update version about "Prefix Unreachable Announcement" 
draft, which contains signification simplification for its contents and the 
clarification of some key points of the mechanism, based on the discussion on 
the list and off the list with LSR experts.
We will try to make some summarizations on the coming IETF meetings. 
Please feel free to comments on the updated contents, or the overall solution.

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: internet-dra...@ietf.org  
Sent: Monday, July 11, 2022 8:50 AM
To: Aijun Wang ; Gyan Mishra 
; Yaqun Xiao ; Zhibo Hu 

Subject: New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-10.txt


A new version of I-D, draft-wang-lsr-prefix-unreachable-annoucement-10.txt
has been successfully submitted by Aijun Wang and posted to the IETF repository.

Name:   draft-wang-lsr-prefix-unreachable-annoucement
Revision:   10
Title:  Prefix Unreachable Announcement
Document date:  2022-07-11
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/archive/id/draft-wang-lsr-prefix-unreachable-annoucement-10.txt
Status: 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-prefix-unreachable-annoucement-10

Abstract:
   This document describes a mechanism that can trigger the switchover
   of the services which rely on the reachability of the peer endpoints,
   for example the BGP or the tunnel services.  It is mainly used in the
   scenarios that the summary prefixes are advertised at the border
   routers whereas the services endpoints are located in different IGP
   areas or levels, whose reachabilities are covered by the summary
   prefixes.

   It introduces a new signaling mechanism using a negative prefix
   announcement called Prefix Unreachable Announcement Mechanism(PUAM),
   utilized to detect a link or node down event and signal the overlay
   services that the event has occurred to force immediate switchover.


  


The IETF Secretariat



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

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

[Yingzhen Qu]

Hi Robert,

Please think of OSPF-GT as a new protocol and it borrows ideas from OSPF. 
BGP-LS is one use case. In LSR WG, there have been proposals asking IGPs to 
carry non-routing information which will have impacts on protocol convergence, 
and OSPF-GT is meant to be the vehicle for such information.

BMP started before YANG, now with NETCONF/YANG or gNMI, you can retrieve the 
entire LSDB or part of it from a router, or subscribe to some data instances. 

Thanks,
Yingzhen

> On Jul 10, 2022, at 3:44 PM, Robert Raszuk  wrote:
> 
> Hi Acee,
> 
> My questions were based on section 3.4 of the latest version of the draft. 
> 
> So I do not think I misinterpreted it. 
> 
> Thank you,
> R.
> 
> 
> 
> On Mon, Jul 11, 2022 at 12:38 AM Acee Lindem (acee)  > wrote:
> Hi Robert,
> 
>  
> 
> From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
> Robert Raszuk mailto:rob...@raszuk.net>>
> Date: Sunday, July 10, 2022 at 1:32 PM
> To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
> Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>, Susan 
> Hares mailto:sha...@ndzh.com>>, IDR List  >, "g...@ietf.org  g...@ietf.org 
> " mailto:g...@ietf.org>>, lsr 
> mailto:lsr@ietf.org>>
> Subject: Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol
> 
>  
> 
> Hi Yingzhen & OSPF-GT authors,
> 
>  
> 
> UP front I must state that anything is better to export IGP information from 
> routers to interested nodes than using BGP for it.
> 
>  
> 
> But to propose using OSPF to transport ISIS seems pretty brave :) I must 
> admit it ! 
> 
>  
> 
> With that I have few questions to the proposal - assuming the use case is to 
> distribute links state info in a point to point fashion: 
> 
>  
> 
> What is the advantage - if any - to use a new OSPF instance/process to send 
> link state data over a unicast session to a controller ? 
>  
> 
> It doesn’t have to be unicast, the remote neighbor construct just extends the 
> possibilities in OSPF-GT. With an OSPF LSDB, the obvious advantage is all the 
> protocol machinery is in place.  Note that LSDB streaming is just but one use 
> case and of OSPF-GT. The detals of this application would be specified in a 
> separate draft.
> 
>  
> 
>  
> 
> The draft is pretty silent on the nature of such a p2p session. Please be 
> explicit if this is TCP, QUIC or what ? 
>  
> 
> It is OSPF, OSPF has its own protocol identifier (89). This draft just 
> extends OSPF. I think you’ve misinterpreted the draft. Hence, your other 
> questions aren’t really applicable or would be answered in a draft of the 
> OSPF/IS-IS LSDB usage of OSPF-GT.
> 
>  
> 
> Thanks,
> Acee
> 
>  
> 
>  
> 
>  
> 
> C) The draft is pretty silent on types of authentication for such sessions. 
> Security considerations are pretty weak in that respect as well. 
> 
>  
> 
>The security considerations for OSPF-GT will be similar to those for
>OSPFv2 [RFC2328] and OSPFv3 [RFC5340].  However, since OSPF-GT is not
>used to update OSPF routing, the consequences of attacks will be
>dependent on advertised non-routing information.
> 
>  
> 
> I would actually argue that security considerations of p2p remote neighbors 
> are actually quite different from security considerations of flooding data. 
> 
>  
> 
> Along the same lines security is not about protecting your routing ... it is 
> much more about protecting the entire network by exposing critical 
> information externally to non authorized parties. 
> 
>  
> 
> D) Are there any PUB-SUB options possible for OSPF-GT ? 
> 
>  
> 
> E) Is there any filtering possible for OSPF-GT ? 
> 
>  
> 
> F) Are you envisioning use of OSPF-GT proxies and if so are you planning to 
> add this to the document ? 
> 
>  
> 
> G) How are you going to address Receivers which do not support OSPF-GT parser 
> ? 
> 
>  
> 
> H) As you know many operators are attracted to BGP-LS based on the fact that 
> it offers the same view of information irrespective of what is the protocol 
> producing the data. Is there some thought on such normalization in the 
> OSPF-GT proposal ?  
> 
>  
> 
> I) What's the take of OSPF-GT draft authors on the YANG model in respect of 
> using it for normalization of exported data ? 
> 
>  
> 
> To summarize IMHO we should not stretch routing protocols be it OSPF, ISIS or 
> BGP to be messengers of link state data running and to artificially force 
> them to run in a point-to-point model between router and controller.  
> 
>  
> 
> Kind regards,
> 
> Robert
> 
>  
> 
>  
> 
> On Sun, Jul 10, 2022 at 7:04 AM Yingzhen Qu  > wrote:
> 
> Hi,
> 
>  
> 
> Since we’re discussing possible solutions, I’d like to bring up the draft: 
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/ 
> 
>  
> 
> We just submitted a new version. The name of the document is changed to 
> “OSPF-GT

Re: [Lsr] IETF 114 LSR Slot Request

[Shraddha Hegde]

Chairs,

Authors of draft-white-lsr-distoptflood would like to request a slot for 
presentation in IETF 114.

Draft: draft-white-lsr-distoptflood
Time duration: 10 mins



Rgds
Shraddha


Juniper Business Use Only
From: Lsr  On Behalf Of Yingzhen Qu
Sent: Tuesday, June 28, 2022 12:34 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org
Subject: [Lsr] IETF 114 LSR Slot Request

[External Email. Be cautious of content]

Hi,

The preliminary agenda for IETF 114 has been posted: 
https://datatracker.ietf.org/meeting/114/agenda/

LSR will have one session:

Friday, July 29, 2022
12:30 - 14:30 Session II
Liberty B

Please send slot request to lsr-cha...@ietf.org. 
Please include draft name, presenter, slot length including Q&A.

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

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

[Gyan Mishra]

Hi Yingzhen

So with OSPFV2 using RFC 6549 would support multiple instances or OSPFV3
already supports instances, how is the GT instance differentiated from any
other routed instance?

For OSPFV2 it would use Opaque LSA Type 9,10,21 similar to RSVP-TE with an
opaque option code for GTI.

For OSPFV3 it would use an OSPFV3 function code for GTI.

So the NBI BGP-LS peering to the PCE/SDN controller would be replaced with
a   OSPF GTI neighbor ?

Would you still need a standard routed OSPF neighbor for reachability or I
guess you could put a static route on the controller across the NBI for
reachability.

Is that correct?

Are there any operators implementations of this using OSPF GTI in place of
BGP-LS?

RFC 6823 provides the same GTI solution for ISIS.


Are there any operators implementations of this using OSPF GTI in place of
BGP-LS?

Kind Regards

Gyan

On Sun, Jul 10, 2022 at 1:04 AM Yingzhen Qu  wrote:

> Hi,
>
> Since we’re discussing possible solutions, I’d like to bring up the draft:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/
>
> We just submitted a new version. The name of the document is changed to
> “OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT
> as a possible replacement of BGP-LS.
>
> Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate
> routes. It uses the reachability info calculated by routing protocols,
> OSPF, ISIS or static routing etc.. It provides mechanisms to advertise
> non-routing information, and remote neighbor is supported.
>
> Reviews and comments are welcome.
>
>
> Thanks,
> Yingzhen
>
>
> On Jul 9, 2022, at 5:33 PM, Gyan Mishra  wrote:
>
>
> During the interim meeting we should keep it open to discuss all possible
> alternatives to BGP-LS.
>
> Thanks
>
> Gyan
>
> On Sat, Jul 9, 2022 at 4:45 PM Susan Hares  wrote:
>
>> Jeff:
>>
>>
>>
>> An interim sounds like a good plan.
>>
>>
>>
>> [IDR-chair hat]
>>
>> Alvaro has indicated that since all of the proposal received on the IDR
>> list are new protocol proposals,
>>
>>- Capturing IDR’s input on BGP-LS problems and potential solutions is
>>appropriate for IDR as BGP-LS home.
>>- Refining any potential non-BGP solutions is outside of the scope of
>>IDR.
>>
>>
>>
>> [IDR-chair hat off]
>>
>> [rtgwg WG member]
>>
>> I’d love to attend an interim on this topic.
>>
>>
>>
>> Sue Hares
>>
>>
>>
>>
>>
>> *From:* Jeff Tantsura 
>> *Sent:* Saturday, July 9, 2022 3:40 PM
>> *To:* Robert Raszuk 
>> *Cc:* Acee Lindem (acee) ; lsr ;
>> i...@ietf.org; Susan Hares ; g...@ietf.org g...@ietf.org
>> 
>> *Subject:* Re: [Idr] [Lsr] IGP Monitoring Protocol
>>
>>
>>
>>
>>
>> Speaking as RTGWG chair:
>>
>>
>>
>> Robert - I don’t think we’d have enough time to accommodate a good
>> discussion during IETF114 (we got only 1 slot), however would be happy to
>> provide a platform for an interim.
>>
>> The topic is important and personally (being a very large BGP-LS user)
>> I’d like to see it progressing.
>>
>> Cheers,
>>
>> Jeff
>>
>>
>>
>> On Jul 8, 2022, at 14:44, Robert Raszuk  wrote:
>>
>> 
>>
>> Hi Acee,
>>
>>
>>
>> Yes, by all means input from the operator's community is needed. It can
>> be collected through LSR WG, IDR WG or GROW WG. RTGWG could also
>> contribute. We have already seen input from some operators and their
>> opinion on adding and distributing more and more link state protocol and
>> topology data in BGP. More such input is very welcome.
>>
>>
>>
>> And to your point about RFC9086 - I see nothing wrong in keeping BGP
>> information in BGP. So IGP Monitoring Protocol does not target to shut down
>> BGP-LS. It only aims to remove 100% of non BGP sourced information from it.
>>
>>
>>
>> Controllers which today listen to BGP-LS need a number of information
>> sources and that spread will only keep increasing as more inputs are
>> becoming necessary for its computations.
>>
>>
>>
>> Regards,
>>
>> Robert.
>>
>>
>>
>>
>>
>> On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee) 
>> wrote:
>>
>> Hi Robert,
>>
>>
>>
>> *From: *Robert Raszuk 
>> *Date: *Friday, July 8, 2022 at 4:36 PM
>> *To: *Acee Lindem 
>> *Cc: *lsr , IDR List , Susan Hares <
>> sha...@ndzh.com>
>> *Subject: *Re: [Lsr] IGP Monitoring Protocol
>>
>>
>>
>> Hi Acee,
>>
>>
>>
>> Thank you. I was not planning to present it in the upcoming IETF.
>>
>>
>>
>> > Let’s see how many stakeholders actually want to this protocol - then
>> we can talk about a WG home.
>>
>>
>>
>> An alternative approach could be to see how many stakeholders do not want
>> to further (for no good reason) to trash BGP. That to me would be in this
>> specific case a much better gauge.
>>
>>
>>
>> In that case, it seems to me that this discussion should be relegated to
>> IDR. Note that there is already non-IGP information transported in BGP-LS,
>> e.g., Egress Peer Engineering (https://datatracker.ietf.org/doc/rfc9086/).
>> I implemented this on our data center routers (NXOS) years and it is solely
>> BGP specific.
>>
>>