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

[Tianran Zhou]

Hi Jeff,

Thanks very much for your review and detailed comments.
All are reasonable to me.
We will work through the document and address your comments.

Thanks,
Tianran

From: Jeffrey Haas [mailto:jh...@pfrc.org]
Sent: Wednesday, July 13, 2022 4:37 AM
To: Tianran Zhou 
Cc: Robert Raszuk ; Yingzhen Qu ; 
idr ; grow ; lsr 
Subject: Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

Tianran,

On Jul 11, 2022, at 10:42 PM, Tianran Zhou 
mailto:zhoutianran=40huawei@dmarc.ietf.org>>
 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

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Lsr] [Idr] 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

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Tianran Zhou]

Hi Robert,

Thanks for sharing your point.
We are actually very open on a new protocol also. We just want to solve real 
problems.
We organized a side meeting in IETF to discuss this. The feedback from that 
meeting is a preference on reusing BMP.  😀

Best,
Tianran






Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Tianran Zhoumailto:zhoutian...@huawei.com>>
抄送： Yingzhen 
Qumailto:yingzhen.i...@gmail.com>>;idrmailto:i...@ietf.org>>;growmailto:grow@ietf.org>>;lsrmailto:l...@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 23:38:49

Hi,

I think BMP is busy enough that loading more on it will be problematic.

Sourcing from two protocols just to leverage single transport session seems not 
best idea.

IMO opening a new unicast session directly by the producer of subject data is 
best way to share/export it.

Many thx,
R.

On Mon, Jul 11, 2022 at 5:34 PM Tianran Zhou 
mailto:zhoutian...@huawei.com>> wrote:
Hi Robert,

Since our work is just follow the BMP which is in GROW in OPS area, we 
presented this in OPSAWG and GROW.

We want to reuse BMP for IGP with some simple extensions. We do not want to 
create a new protocol only because of the BMP name.

Cheers,
Tianran






Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Tianran Zhoumailto:zhoutian...@huawei.com>>
抄送： Yingzhen 
Qumailto:yingzhen.i...@gmail.com>>;idrmailto:i...@ietf.org>>;growmailto:grow@ietf.org>>;lsrmailto:l...@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 23:05:56

Hello Tianran,

Oh I was not aware of such document. Did you ever share it with LSR WG before ?

Quick browsing reveals that you have taken a bit different approach .. very IGP 
centric borrowing IGP encoding at the message level.

For example peer state notification I purposely decided not to include as this 
is already reflected in the LSDB.

I will take a more detail read of your spec. Then we can talk if there is some 
overlap or both approaches are so different then it makes sense to progress 
both. One size does not fit all :)

Best,
R.




On Mon, Jul 11, 2022 at 4:54 PM Tianran Zhou 
mailto:zhoutian...@huawei.com>> wrote:
Hi Robert,

This is very interesting to me. We had a protocol design for IGP monitoring:

https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01

It would be a good idea if we can find some common ground.

Cheers,
Tianran






Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Tianran Zhoumailto:zhoutian...@huawei.com>>
抄送： Yingzhen 
Qumailto:yingzhen.i...@gmail.com>>;idrmailto:i...@ietf.org>>;growmailto:grow@ietf.org>>;lsrmailto:l...@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 22:05:31

Hi Tianran,

Yes it is,

I dedicated entire paragraph in section 1 of the document to highlight that 
point:


   The primary inspiration for this work has been based on the success
   of BGP Monitoring Protocol (BMP) [RFC7854] which in a number of
   aspects shares the same high level requirements - point to point
   routing information distribution, protocol observability and enhanced
   operations.  It also needs to be highlighted that BMP (while it
   technically could) does not use native BGP sessions to propagate such
   information, but is running a separate transport.  IMP authors have
   chosen to reuse selected BMP building blocks and BMP operational and
   deployment experience.



Many thx,
R.

On Mon, Jul 11, 2022 at 4:02 PM Tianran Zhou 
mailto:zhoutian...@huawei.com>> wrote:
Hi Robert,

I see this name very similar to BMP bgp monitoring protocol.
Is this the similar function and scope as BMP?


Best,
Tianran



Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Yingzhen Qumailto:yingzhen.i...@gmail.com>>
抄送： 
idrmailto:i...@ietf.org>>;growmailto:grow@ietf.org>>;lsrmailto:l...@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 18:01:47

Hi Yingzhen,

Yes I understand that OSPF-GT is a new protocol leveraging some OSPF elements.

And please do not get me wrong ... way before OSPF Transport Instance I wrote 
BGP Transport Instance proposal and I do consider such additions to protocols 
as a very useful thing. In fact honestly recent discussions on UPA/PUA/PULSE 
could be very well served by OSPF-GT in a stateful fashion.

But I just do not see this fits well as a replacement of BGP-LS.

Yes, protocol designers like a swiss army knife approach (not to use nail and 
hammer analogy). However I think custom tools in the toolkit work much better 
for specific tasks :)

Cheers,
R.



On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:

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

[Robert Raszuk]

Hi,

I think BMP is busy enough that loading more on it will be problematic.

Sourcing from two protocols just to leverage single transport session seems
not best idea.

IMO opening a new unicast session directly by the producer of subject data
is best way to share/export it.

Many thx,
R.

On Mon, Jul 11, 2022 at 5:34 PM Tianran Zhou  wrote:

> Hi Robert,
>
>
> Since our work is just follow the BMP which is in GROW in OPS area, we 
> presented this in OPSAWG and GROW.
>
>
> We want to reuse BMP for IGP with some simple extensions. We do not want to 
> create a new protocol only because of the BMP name.
>
> Cheers,
> Tianran
>
>
>
>
> --
>
> Sent from WeLink
> *发件人： *Robert Raszuk
> *收件人： *Tianran Zhou
> *抄送： *Yingzhen Qu;idr;grow<
> grow@ietf.org>;lsr
> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
> *时间： *2022-07-11 23:05:56
>
> Hello Tianran,
>
> Oh I was not aware of such document. Did you ever share it with LSR WG
> before ?
>
> Quick browsing reveals that you have taken a bit different approach ..
> very IGP centric borrowing IGP encoding at the message level.
>
> For example peer state notification I purposely decided not to include as
> this is already reflected in the LSDB.
>
> I will take a more detail read of your spec. Then we can talk if there is
> some overlap or both approaches are so different then it makes sense to
> progress both. One size does not fit all :)
>
> Best,
> R.
>
>
>
>
> On Mon, Jul 11, 2022 at 4:54 PM Tianran Zhou 
> wrote:
>
>> Hi Robert,
>>
>>
>> This is very interesting to me. We had a protocol design for IGP monitoring:
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01
>>
>> It would be a good idea if we can find some common ground.
>>
>> Cheers,
>> Tianran
>>
>>
>>
>>
>> --
>>
>> Sent from WeLink
>> *发件人： *Robert Raszuk
>> *收件人： *Tianran Zhou
>> *抄送： *Yingzhen Qu;idr;grow<
>> grow@ietf.org>;lsr
>> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
>> *时间： *2022-07-11 22:05:31
>>
>> Hi Tianran,
>>
>> Yes it is,
>>
>> I dedicated entire paragraph in section 1 of the document to highlight
>> that point:
>>
>>The primary inspiration for this work has been based on the success
>>of BGP Monitoring Protocol (BMP) [RFC7854] which in a number of
>>aspects shares the same high level requirements - point to point
>>routing information distribution, protocol observability and enhanced
>>operations.  It also needs to be highlighted that BMP (while it
>>technically could) does not use native BGP sessions to propagate such
>>information, but is running a separate transport.  IMP authors have
>>chosen to reuse selected BMP building blocks and BMP operational and
>>deployment experience.
>>
>>
>>
>> Many thx,
>> R.
>>
>> On Mon, Jul 11, 2022 at 4:02 PM Tianran Zhou 
>> wrote:
>>
>>> Hi Robert,
>>>
>>> I see this name very similar to BMP bgp monitoring protocol.
>>> Is this the similar function and scope as BMP?
>>>
>>>
>>> Best,
>>> Tianran
>>>
>>> --
>>>
>>> Sent from WeLink
>>> *发件人： *Robert Raszuk
>>> *收件人： *Yingzhen Qu
>>> *抄送： *idr;grow;lsr
>>> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
>>> *时间： *2022-07-11 18:01:47
>>>
>>> Hi Yingzhen,
>>>
>>> Yes I understand that OSPF-GT is a new protocol leveraging some OSPF
>>> elements.
>>>
>>> And please do not get me wrong ... way before OSPF Transport Instance I
>>> wrote BGP Transport Instance proposal and I do consider such additions to
>>> protocols as a very useful thing. In fact honestly recent discussions on
>>> UPA/PUA/PULSE could be very well served by OSPF-GT in a stateful fashion.
>>>
>>> But I just do not see this fits well as a replacement of BGP-LS.
>>>
>>> Yes, protocol designers like a swiss army knife approach (not to use
>>> nail and hammer analogy). However I think custom tools in the toolkit work
>>> much better for specific tasks :)
>>>
>>> Cheers,
>>> R.
>>>
>>>
>>>
>>> On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu 
>>> wrote:
>>>
>>>> Hi Robert,
>>>>
>>>> Please think of OSPF-GT 

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

[Tianran Zhou]

Hi Robert,

Since our work is just follow the BMP which is in GROW in OPS area, we 
presented this in OPSAWG and GROW.

We want to reuse BMP for IGP with some simple extensions. We do not want to 
create a new protocol only because of the BMP name.

Cheers,
Tianran






Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Tianran Zhoumailto:zhoutian...@huawei.com>>
抄送： Yingzhen 
Qumailto:yingzhen.i...@gmail.com>>;idrmailto:i...@ietf.org>>;growmailto:grow@ietf.org>>;lsrmailto:l...@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 23:05:56

Hello Tianran,

Oh I was not aware of such document. Did you ever share it with LSR WG before ?

Quick browsing reveals that you have taken a bit different approach .. very IGP 
centric borrowing IGP encoding at the message level.

For example peer state notification I purposely decided not to include as this 
is already reflected in the LSDB.

I will take a more detail read of your spec. Then we can talk if there is some 
overlap or both approaches are so different then it makes sense to progress 
both. One size does not fit all :)

Best,
R.




On Mon, Jul 11, 2022 at 4:54 PM Tianran Zhou 
mailto:zhoutian...@huawei.com>> wrote:
Hi Robert,

This is very interesting to me. We had a protocol design for IGP monitoring:

https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01

It would be a good idea if we can find some common ground.

Cheers,
Tianran






Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Tianran Zhoumailto:zhoutian...@huawei.com>>
抄送： Yingzhen 
Qumailto:yingzhen.i...@gmail.com>>;idrmailto:i...@ietf.org>>;growmailto:grow@ietf.org>>;lsrmailto:l...@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 22:05:31

Hi Tianran,

Yes it is,

I dedicated entire paragraph in section 1 of the document to highlight that 
point:


   The primary inspiration for this work has been based on the success
   of BGP Monitoring Protocol (BMP) [RFC7854] which in a number of
   aspects shares the same high level requirements - point to point
   routing information distribution, protocol observability and enhanced
   operations.  It also needs to be highlighted that BMP (while it
   technically could) does not use native BGP sessions to propagate such
   information, but is running a separate transport.  IMP authors have
   chosen to reuse selected BMP building blocks and BMP operational and
   deployment experience.



Many thx,
R.

On Mon, Jul 11, 2022 at 4:02 PM Tianran Zhou 
mailto:zhoutian...@huawei.com>> wrote:
Hi Robert,

I see this name very similar to BMP bgp monitoring protocol.
Is this the similar function and scope as BMP?


Best,
Tianran



Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Yingzhen Qumailto:yingzhen.i...@gmail.com>>
抄送： 
idrmailto:i...@ietf.org>>;growmailto:grow@ietf.org>>;lsrmailto:l...@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 18:01:47

Hi Yingzhen,

Yes I understand that OSPF-GT is a new protocol leveraging some OSPF elements.

And please do not get me wrong ... way before OSPF Transport Instance I wrote 
BGP Transport Instance proposal and I do consider such additions to protocols 
as a very useful thing. In fact honestly recent discussions on UPA/PUA/PULSE 
could be very well served by OSPF-GT in a stateful fashion.

But I just do not see this fits well as a replacement of BGP-LS.

Yes, protocol designers like a swiss army knife approach (not to use nail and 
hammer analogy). However I think custom tools in the toolkit work much better 
for specific tasks :)

Cheers,
R.



On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:
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 
mailto:rob...@raszuk.net>> 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) 
mailto:a...@cisco.com>> 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

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

[Robert Raszuk]

Hello Tianran,

Oh I was not aware of such document. Did you ever share it with LSR WG
before ?

Quick browsing reveals that you have taken a bit different approach .. very
IGP centric borrowing IGP encoding at the message level.

For example peer state notification I purposely decided not to include as
this is already reflected in the LSDB.

I will take a more detail read of your spec. Then we can talk if there is
some overlap or both approaches are so different then it makes sense to
progress both. One size does not fit all :)

Best,
R.




On Mon, Jul 11, 2022 at 4:54 PM Tianran Zhou  wrote:

> Hi Robert,
>
>
> This is very interesting to me. We had a protocol design for IGP monitoring:
>
>
> https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01
>
> It would be a good idea if we can find some common ground.
>
> Cheers,
> Tianran
>
>
>
>
> --
>
> Sent from WeLink
> *发件人： *Robert Raszuk
> *收件人： *Tianran Zhou
> *抄送： *Yingzhen Qu;idr;grow<
> grow@ietf.org>;lsr
> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
> *时间： *2022-07-11 22:05:31
>
> Hi Tianran,
>
> Yes it is,
>
> I dedicated entire paragraph in section 1 of the document to highlight
> that point:
>
>The primary inspiration for this work has been based on the success
>of BGP Monitoring Protocol (BMP) [RFC7854] which in a number of
>aspects shares the same high level requirements - point to point
>routing information distribution, protocol observability and enhanced
>operations.  It also needs to be highlighted that BMP (while it
>technically could) does not use native BGP sessions to propagate such
>information, but is running a separate transport.  IMP authors have
>chosen to reuse selected BMP building blocks and BMP operational and
>deployment experience.
>
>
>
> Many thx,
> R.
>
> On Mon, Jul 11, 2022 at 4:02 PM Tianran Zhou 
> wrote:
>
>> Hi Robert,
>>
>> I see this name very similar to BMP bgp monitoring protocol.
>> Is this the similar function and scope as BMP?
>>
>>
>> Best,
>> Tianran
>>
>> --
>>
>> Sent from WeLink
>> *发件人： *Robert Raszuk
>> *收件人： *Yingzhen Qu
>> *抄送： *idr;grow;lsr
>> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
>> *时间： *2022-07-11 18:01:47
>>
>> Hi Yingzhen,
>>
>> Yes I understand that OSPF-GT is a new protocol leveraging some OSPF
>> elements.
>>
>> And please do not get me wrong ... way before OSPF Transport Instance I
>> wrote BGP Transport Instance proposal and I do consider such additions to
>> protocols as a very useful thing. In fact honestly recent discussions on
>> UPA/PUA/PULSE could be very well served by OSPF-GT in a stateful fashion.
>>
>> But I just do not see this fits well as a replacement of BGP-LS.
>>
>> Yes, protocol designers like a swiss army knife approach (not to use nail
>> and hammer analogy). However I think custom tools in the toolkit work much
>> better for specific tasks :)
>>
>> Cheers,
>> R.
>>
>>
>>
>> On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu 
>> wrote:
>>
>>> 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  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 , "grow@ietf.org grow@ietf.org" 

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

[Tianran Zhou]

Hi Robert,

This is very interesting to me. We had a protocol design for IGP monitoring:

https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01

It would be a good idea if we can find some common ground.

Cheers,
Tianran






Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Tianran Zhoumailto:zhoutian...@huawei.com>>
抄送： Yingzhen 
Qumailto:yingzhen.i...@gmail.com>>;idrmailto:i...@ietf.org>>;growmailto:grow@ietf.org>>;lsrmailto:l...@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 22:05:31

Hi Tianran,

Yes it is,

I dedicated entire paragraph in section 1 of the document to highlight that 
point:


   The primary inspiration for this work has been based on the success
   of BGP Monitoring Protocol (BMP) [RFC7854] which in a number of
   aspects shares the same high level requirements - point to point
   routing information distribution, protocol observability and enhanced
   operations.  It also needs to be highlighted that BMP (while it
   technically could) does not use native BGP sessions to propagate such
   information, but is running a separate transport.  IMP authors have
   chosen to reuse selected BMP building blocks and BMP operational and
   deployment experience.



Many thx,
R.

On Mon, Jul 11, 2022 at 4:02 PM Tianran Zhou 
mailto:zhoutian...@huawei.com>> wrote:
Hi Robert,

I see this name very similar to BMP bgp monitoring protocol.
Is this the similar function and scope as BMP?


Best,
Tianran



Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Yingzhen Qumailto:yingzhen.i...@gmail.com>>
抄送： 
idrmailto:i...@ietf.org>>;growmailto:grow@ietf.org>>;lsrmailto:l...@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 18:01:47

Hi Yingzhen,

Yes I understand that OSPF-GT is a new protocol leveraging some OSPF elements.

And please do not get me wrong ... way before OSPF Transport Instance I wrote 
BGP Transport Instance proposal and I do consider such additions to protocols 
as a very useful thing. In fact honestly recent discussions on UPA/PUA/PULSE 
could be very well served by OSPF-GT in a stateful fashion.

But I just do not see this fits well as a replacement of BGP-LS.

Yes, protocol designers like a swiss army knife approach (not to use nail and 
hammer analogy). However I think custom tools in the toolkit work much better 
for specific tasks :)

Cheers,
R.



On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:
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 
mailto:rob...@raszuk.net>> 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) 
mailto:a...@cisco.com>> 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 
mailto:i...@ietf.org>>, "grow@ietf.org<mailto:grow@ietf.org> 
grow@ietf.org<mailto:grow@ietf.org>" mailto:grow@ietf.org>>, lsr 
mailto:l...@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:


  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 T

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

[Robert Raszuk]

Hi Tianran,

Yes it is,

I dedicated entire paragraph in section 1 of the document to highlight that
point:

   The primary inspiration for this work has been based on the success
   of BGP Monitoring Protocol (BMP) [RFC7854] which in a number of
   aspects shares the same high level requirements - point to point
   routing information distribution, protocol observability and enhanced
   operations.  It also needs to be highlighted that BMP (while it
   technically could) does not use native BGP sessions to propagate such
   information, but is running a separate transport.  IMP authors have
   chosen to reuse selected BMP building blocks and BMP operational and
   deployment experience.



Many thx,
R.

On Mon, Jul 11, 2022 at 4:02 PM Tianran Zhou  wrote:

> Hi Robert,
>
> I see this name very similar to BMP bgp monitoring protocol.
> Is this the similar function and scope as BMP?
>
>
> Best,
> Tianran
>
> --
>
> Sent from WeLink
> *发件人： *Robert Raszuk
> *收件人： *Yingzhen Qu
> *抄送： *idr;grow;lsr
> *主题： *Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
> *时间： *2022-07-11 18:01:47
>
> Hi Yingzhen,
>
> Yes I understand that OSPF-GT is a new protocol leveraging some OSPF
> elements.
>
> And please do not get me wrong ... way before OSPF Transport Instance I
> wrote BGP Transport Instance proposal and I do consider such additions to
> protocols as a very useful thing. In fact honestly recent discussions on
> UPA/PUA/PULSE could be very well served by OSPF-GT in a stateful fashion.
>
> But I just do not see this fits well as a replacement of BGP-LS.
>
> Yes, protocol designers like a swiss army knife approach (not to use nail
> and hammer analogy). However I think custom tools in the toolkit work much
> better for specific tasks :)
>
> Cheers,
> R.
>
>
>
> On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu 
> wrote:
>
>> 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  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 , "grow@ietf.org grow@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, 

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

[Tianran Zhou]

Hi Robert,

I see this name very similar to BMP bgp monitoring protocol.
Is this the similar function and scope as BMP?


Best,
Tianran



Sent from WeLink
发件人： Robert Raszukmailto:rob...@raszuk.net>>
收件人： Yingzhen Qumailto:yingzhen.i...@gmail.com>>
抄送： 
idrmailto:i...@ietf.org>>;growmailto:grow@ietf.org>>;lsrmailto:l...@ietf.org>>
主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
时间： 2022-07-11 18:01:47

Hi Yingzhen,

Yes I understand that OSPF-GT is a new protocol leveraging some OSPF elements.

And please do not get me wrong ... way before OSPF Transport Instance I wrote 
BGP Transport Instance proposal and I do consider such additions to protocols 
as a very useful thing. In fact honestly recent discussions on UPA/PUA/PULSE 
could be very well served by OSPF-GT in a stateful fashion.

But I just do not see this fits well as a replacement of BGP-LS.

Yes, protocol designers like a swiss army knife approach (not to use nail and 
hammer analogy). However I think custom tools in the toolkit work much better 
for specific tasks :)

Cheers,
R.



On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:
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 
mailto:rob...@raszuk.net>> 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) 
mailto:a...@cisco.com>> 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 
mailto:i...@ietf.org>>, "grow@ietf.org<mailto:grow@ietf.org> 
grow@ietf.org<mailto:grow@ietf.org>" mailto:grow@ietf.org>>, lsr 
mailto:l...@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:


  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 o

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

[Robert Raszuk]

Hi Yingzhen,

Yes I understand that OSPF-GT is a new protocol leveraging some OSPF
elements.

And please do not get me wrong ... way before OSPF Transport Instance I
wrote BGP Transport Instance proposal and I do consider such additions to
protocols as a very useful thing. In fact honestly recent discussions on
UPA/PUA/PULSE could be very well served by OSPF-GT in a stateful fashion.

But I just do not see this fits well as a replacement of BGP-LS.

Yes, protocol designers like a swiss army knife approach (not to use nail
and hammer analogy). However I think custom tools in the toolkit work much
better for specific tasks :)

Cheers,
R.



On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu  wrote:

> 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  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 , "grow@ietf.org grow@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

Re: [GROW] [Lsr] [Idr] 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  >, "grow@ietf.org  grow@ietf.org 
> " mailto:grow@ietf.org>>, lsr 
> mailto:l...@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-G

Re: [GROW] [Lsr] [Idr] 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 , "grow@ietf.org grow@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: [GROW] [Lsr] [Idr] 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 , "grow@ietf.org grow@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:l...@ietf.org>>; i...@ietf.org; 
Susan Hares mailto:sha...@ndzh.com>>; 
grow@ietf.org grow@ietf.org