Hi,
> Did you read the draft? The main difference is that since OSPF-GT is
>> generalized to be used for non-routing, there is no installation of routes.
>>
>
> Gyan> So The routes would be application use case specific “non
> routing” routes for example for BGP-LS it would be the related
Hi Acee
Responses in-line
On Mon, Jul 11, 2022 at 10:44 AM Acee Lindem (acee) wrote:
> Hi Gyan,
>
>
>
> *From: *GROW on behalf of Gyan Mishra <
> hayabusa...@gmail.com>
> *Date: *Monday, July 11, 2022 at 1:41 AM
> *To: *Yingzhen Qu
> *Cc: *IDR List , "g...@ietf.org g...@ietf.org" <
>
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
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
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
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
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
See one typo.
From: GROW on behalf of "Acee Lindem (acee)"
Date: Monday, July 11, 2022 at 10:45 AM
To: Gyan Mishra , Yingzhen Qu
Cc: IDR List , "g...@ietf.org g...@ietf.org" ,
lsr
Subject: Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol
Hi Gyan,
From: GROW on behalf of Gyan Mishra
Date:
Hi Gyan,
From: GROW on behalf of Gyan Mishra
Date: Monday, July 11, 2022 at 1:41 AM
To: Yingzhen Qu
Cc: IDR List , "g...@ietf.org g...@ietf.org" ,
lsr
Subject: Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol
Hi Yingzhen
So with OSPFV2 using RFC 6549 would support multiple instances or
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
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>>
抄送：
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
>
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
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
14 matches
Mail list logo
