Subject: Re: [Lsr] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

From: Jeff Tantsura <[email-masked]>
Date: Tue, 03 Jul 2018 14:15:06 -0700

Robin,

Pretty much same comment as Acee - I'm not clear as to why...
Protocol YANG models developed in the last years clearly provide much better and more scalable approach to what has been proposed in the draft, since we are talking is-is - look at notifications in draft-ietf-isis-yang-isis-cfg. How do you propose to corelate operational state to configuration?

gRPC provides high performance RPC framework  to streaming the telemetry data that is structured, easy to consume and extend. 

I'm not going to go into technical discussion, however would appreciate your response as to why NMP (please do not restate the points in the section 4 of the draft, they are quite incorrect) 

Thanks!

Cheers,
Jeff

On 7/3/18, 09:21, "Lsr on behalf of Acee Lindem (acee)" <[email-masked] on behalf of acee=[email-masked]> wrote:

    Hi Robin, 
    I'm not arguing to deprecate BMP. What I am arguing is that the fact that BMP was created 15 years ago doesn't necessarily mean we should create an analogous IMP for IS-IS given the current IETF OPS technologies and the fact that faster link speeds and Moore's law facilitate deployment of these new OPS technologies. Anyway, I looked at the agenda and I will definitely attend GROW on Wednesday afternoon for the discussion. 
    Thanks,
    Acee 
    
    On 7/3/18, 6:40 AM, "Lizhenbin" <[email-masked]> wrote:
    
        Hi Acee,
        Thank for your attention to the new draft. Please refer to my reply inline.
        
        Best Regards,
        Robin

        -----Original Message-----
        From: OPSAWG [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
        Sent: Monday, July 02, 2018 9:24 PM
        To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email-masked]>; [email-masked]; [email-masked]
        Subject: Re: [OPSAWG] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt
        
        Hi Yunan, Shunwan, and Zhenbin, 
        
        What are the advantages of inventing a new protocol over just using YANG and NETCONF, RESTCONF, or gNMI? 
        [Robin] In the draft we simply mention the difference between NMP and protocols you mentioned for the management plane. Though there is maybe some overlap between the two types of protocols, the protocols you mentioned is not enough for monitoring the control protocol. For example, would we like to use YANG and NETCONF, RESTCONF, or gNMI to export the packets of control protocols such as update message of BGP and/or ISIS PDU, etc. for the purpose of monitoring?

        Operators and vendors are doing this anyway. A second alternative would be to listen passively in IS-IS (or OSPF for that matter). Why would anyone want this? 
        [Robin] In fact we tried the method you proposed. From our point of view, the basic design principle should be that the monitoring entity should be decoupled from the monitored entity. This is to avoid following cases:
        1. The failure of operation of the control protocol may affect the monitoring at the same time.
        2. The limitation of the control protocol will also have effect on the monitoring. For example, for the method of listening passively, if there are multiple hops between the listener and the network devices, it has to set up a tunnel as the virtual link for direct connection. But the TCP-based monitoring protocol need not care about it. 

        As far as where it belongs, we have a rather full agenda in LSR so I don't think we want to devote time to it there at IETF 102.  
        [Robin] Though the WG the draft should belong to is not determined yet, we think the work belongs to OPS area and send the notice to GROW WG and OPSAWG. We also applied for the presentation in the two WGs. We should have copied the notice to the related WGs of RTG area. So the LSR WG and RTGWG WG mailing list are added. More comments and suggestions are welcome.
        
        Thanks,
        Acee

        On 7/2/18, 8:20 AM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[email-masked] on behalf of [email-masked]> wrote:
        
            Dear GROW & OPSAWG WGs,
            
            We have proposed a Network Monitoring Protocol (NMP) for the control plane OAM. NMP for ISIS is illustrated in this draft to showcase the benefit and operation of NMP. Yet, we haven't decided which WG it belongs to. 

            Comments and suggestions are very welcome! 
            
            Thank you!

            Yunan Gu
            Huawei Technologies Co. Ltd
            
            -----Original Message-----
            From: [email-masked] [mailto:[email-masked]] 
            Sent: 2018年7月2日 20:07
            To: Zhuangshunwan <[email-masked]>; Lizhenbin <[email-masked]>; Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email-masked]>
            Subject: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

            A new version of I-D, draft-gu-network-mornitoring-protol-00.txt
            has been successfully submitted by Yunan Gu and posted to the IETF repository.
            
            Name:		draft-gu-network-mornitoring-protol
            Revision:	00
            Title:		Network Monitoring Protocol (NMP)
            Document date:	2018-07-02
            Group:		Individual Submission
            Pages:		15
            URL:            https://www.ietf.org/internet-drafts/draft-gu-network-mornitoring-protol-00.txt
            Status:         https://datatracker.ietf.org/doc/draft-gu-network-mornitoring-protol/
            Htmlized:       https://tools.ietf.org/html/draft-gu-network-mornitoring-protol-00
            Htmlized:       https://datatracker.ietf.org/doc/html/draft-gu-network-mornitoring-protol

            Abstract:
               To enable automated network OAM (Operations, administration and
               management), the availability of network protocol running status
               information is a fundamental step.  In this document, a network
               monitoring protocol (NMP) is proposed to provision the information
               related to running status of IGP (Interior Gateway Protocol) and
               other control protocols.  It can facilitate the network
               troubleshooting of control protocols in a network domain.  Typical
               network issues are illustrated as the usecases of NMP for ISIS to
               showcase the necessity of NMP.  Then the operations and the message
               formats of NMP for ISIS are defined.  In this document ISIS is used
               as the illustration protocol, and the case of OSPF and other control
               protocols will be included in the future version.

            Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
            
            The IETF Secretariat
            
            _______________________________________________
            GROW mailing list
            [email-masked]
            https://www.ietf.org/mailman/listinfo/grow

        _______________________________________________
        OPSAWG mailing list
        [email-masked]
        https://www.ietf.org/mailman/listinfo/opsawg

    _______________________________________________
    Lsr mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/lsr

---

From: Lizhenbin <[email-masked]>
Date: Thu, 5 Jul 2018 10:48:41 +0000

Hi Jeff,
Before we propose the NMP idea, we carefully compared it with the existing NETCONF, gRPC and YANG models work:
1. Based on my experience in the YANG model work, it may be not satisfactory for these models does not define config/oper of all features of specific protocol and these models have much relation with each other and it is difficult to stabilize the definition.
2. For monitoring the control protocol, it is not enough based on the existing YANG models such as the packets of control protocol which should be monitored but not defined in YANG models. 
3. Performance concern on the existing NETCONF.
4. Standardization of the existing gRPC.

We would like to define the NMP based on the usecases. That is, a specific set of parameters exported by NMP can satisfy the purpose of a specific usecase. Thus the protocol can be deployed incrementally.

Best Regards,
Robin

-----Original Message-----
From: Jeff Tantsura [mailto:[email-masked]] 
Sent: Wednesday, July 04, 2018 5:15 AM
To: Acee Lindem (acee) <acee=[email-masked]>; Lizhenbin <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email-masked]>
Subject: Re: [Lsr] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

Robin,

Thanks!

Cheers,
Jeff

    Hi Robin, 

        Hi Acee,
        
        Best Regards,
        Robin

        -----Original Message-----
        From: OPSAWG [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
        Sent: Monday, July 02, 2018 9:24 PM
        To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email-masked]>; [email-masked]; [email-masked]
        Subject: Re: [OPSAWG] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

        
        Thanks,
        Acee

        
            Dear GROW & OPSAWG WGs,

            
            Thank you!

            Yunan Gu
            
            -----Original Message-----

            Abstract:

            
            The IETF Secretariat

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Thu, 5 Jul 2018 11:45:48 +0000

Robin,

With respect to your points below:

  *   #1 – The draft ISIS model doesn’t seem to have many lateral dependencies as far as I can see. And if it is incomplete from the perspective of monitoring the health of ISIS, then it should be extended. I’m not sure why it would be difficult to stabilise the definition?
  *   #2 – This seems to be the same issue of an incomplete model. Can you clearly articulate any data that you think should be available that cannot be modelled in YANG?
  *   #3 – Agreed that exporting high volume, low latency telemetry one the baseline transport suggested in ietf-netconf-yang-push would perhaps have issues. This is one of the reasons why transport extensibility is an explicit part of the draft.
  *   #4 – IMO, as long as the encoding for data is clearly defined in an "open" way, then this is not really an issue yet. I still think we need to experiment with encodings, but I do not think an entirely new protocol will serve network operators.

I’d also like to add to the last point and say that I do not think adding new protocols and new encodings will serve network operators well. Over the last few years operators have been making it clear that they want to simplify their interactions with the network, and not have more things they need to understand thrown at them. Acee isn’t suggesting deprecating BMP, and neither am I, but in at least two discussions with operators I have attended, when introduced to BMP, their initial reaction could be summarised as "this looks interesting, but why have you introduced another protocol for this?"

I completely support identifying the use cases you have, but would really like to see us focus on rectifying any deficiencies we can identify with existing proposals, rather than dilute our efforts.

Cheers,

Einar

On 5 Jul 2018, at 11:48, Lizhenbin <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jeff,

Best Regards,
Robin

-----Original Message-----
From: Jeff Tantsura [mailto:[email-masked]]
Sent: Wednesday, July 04, 2018 5:15 AM
To: Acee Lindem (acee) <acee=[email-masked]<mailto:acee=[email-masked]>>; Lizhenbin <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

Robin,

Thanks!

Cheers,
Jeff

On 7/3/18, 09:21, "Lsr on behalf of Acee Lindem (acee)" <[email-masked]<mailto:[email-masked]> on behalf of acee=[email-masked]<mailto:acee=[email-masked]>> wrote:

   Hi Robin,

   On 7/3/18, 6:40 AM, "Lizhenbin" <[email-masked]<mailto:[email-masked]>> wrote:

       Hi Acee,

       Best Regards,
       Robin

       -----Original Message-----
       From: OPSAWG [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
       Sent: Monday, July 02, 2018 9:24 PM
       To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
       Subject: Re: [OPSAWG] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

       Thanks,
       Acee

       On 7/2/18, 8:20 AM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

           Dear GROW & OPSAWG WGs,

           Thank you!

           Yunan Gu

           -----Original Message-----
           From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
           Sent: 2018年7月2日 20:07
           To: Zhuangshunwan <[email-masked]<mailto:[email-masked]>>; Lizhenbin <[email-masked]<mailto:[email-masked]>>; Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email-masked]<mailto:[email-masked]>>
           Subject: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

           Abstract:

           Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

           The IETF Secretariat

           _______________________________________________
           GROW mailing list
           [email-masked]<mailto:[email-masked]>
           https://www.ietf.org/mailman/listinfo/grow

       _______________________________________________
       OPSAWG mailing list
       [email-masked]<mailto:[email-masked]>
       https://www.ietf.org/mailman/listinfo/opsawg

   _______________________________________________
   Lsr mailing list
   [email-masked]<mailto:[email-masked]>
   https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 5 Jul 2018 22:03:33 +0000

Hi Robin, 

I know for a fact that there have been applications written that do passive monitoring using IS-IS and simply advertising yourself in overload mode. Additionally, given that all routes in an area have the same LSDB, you don't really have the same requirements as BGP. 

With respect to scalability, I believe the advantage of the YANG models is more in terms of consumption and having a single network programmability paradigm rather unique per-protocol monitoring. Additionally, YANG, NETCONF, RESTCONF, gNMI, and streaming telemetry are happening now irrespective of your proposal. 

I agree that a custom protocol will result in fewer bits on the wire and potentially less processing on the network device. However, I certainly don't believe that this alone is a reason to do it. 

Thanks,
Acee 

On 7/5/18, 6:49 AM, "GROW on behalf of Lizhenbin" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Jeff,

    Best Regards,
    Robin

    -----Original Message-----
    From: Jeff Tantsura [mailto:[email-masked]] 
    Sent: Wednesday, July 04, 2018 5:15 AM
    To: Acee Lindem (acee) <acee=[email-masked]>; Lizhenbin <[email-masked]>; [email-masked]; [email-masked]
    Cc: [email-masked]; [email-masked]; Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email-masked]>
    Subject: Re: [Lsr] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt
    
    Robin,

    
    
    Thanks!
    
    Cheers,
    Jeff

        Hi Robin, 

            Hi Acee,
            
            Best Regards,
            Robin

            -----Original Message-----

            
            Thanks,
            Acee

            
                Dear GROW & OPSAWG WGs,

                
                Thank you!

                Yunan Gu
                
                -----Original Message-----

                Abstract:

                
                The IETF Secretariat

---

From: Lizhenbin <[email-masked]>
Date: Fri, 6 Jul 2018 07:41:32 +0000

Hi Acee and Randy,
We do not think NMP is a competitive solutions. We also do not think NMP can solve all issues. From these point of view we are same with you. Similarly I do not think Yang models can solve all issues.
I would also like to propose following draft for your reference which trigger us to move forward for better network maintenance with multiple tools in which gRPC/NETCOF and NMP/BMP may play different roles:
https://datatracker.ietf.org/doc/draft-song-ntf/

Best Regards,
Robin

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Friday, July 06, 2018 6:04 AM
To: Lizhenbin <[email-masked]>; Jeff Tantsura <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [GROW] [Lsr] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

Hi Robin, 

Thanks,
Acee 

    Hi Jeff,

    Best Regards,
    Robin

    -----Original Message-----
    From: Jeff Tantsura [mailto:[email-masked]] 
    Sent: Wednesday, July 04, 2018 5:15 AM
    To: Acee Lindem (acee) <acee=[email-masked]>; Lizhenbin <[email-masked]>; [email-masked]; [email-masked]
    Cc: [email-masked]; [email-masked]; Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email-masked]>
    Subject: Re: [Lsr] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt
    
    Robin,

    
    
    Thanks!
    
    Cheers,
    Jeff

        Hi Robin, 

            Hi Acee,
            
            Best Regards,
            Robin

            -----Original Message-----

            
            Thanks,
            Acee

            
                Dear GROW & OPSAWG WGs,

                
                Thank you!

                Yunan Gu
                
                -----Original Message-----

                Abstract:

                
                The IETF Secretariat

---

From: Robert Wilton <[email-masked]>
Date: Fri, 6 Jul 2018 10:46:47 +0100

> I agree that a custom protocol will result in fewer bits on the wire and potentially less processing on the network device. However, I certainly don't believe that this alone is a reason to do it.
If we want less bits on the wire, then adding support for a binary 
encoding (e.g. CBOR) to the existing YANG management protocols seems 
like a better path forwards to me since that seems to have the widest 
benefit.  CBOR encoded YANG (if using numerical "SIDs" rather than 
strings for the field names, draft-ietf-core-yang-cbor) is a pretty 
tight encoding, and is designed for IOT and constrained devices.  A CBOR 
encoding probably won't be quite as compact as custom TLVs, but I doubt 
that it would be significantly bigger either, and it has quite a few 
other benefits (code reuse, can be generically decoded).

Thanks,
Rob

> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Fri, 6 Jul 2018 09:59:28 +0000

+1

On 6 Jul 2018, at 10:46, Robert Wilton <rwilton=[email-masked]<mailto:rwilton=[email-masked]>> wrote:

I agree that a custom protocol will result in fewer bits on the wire and potentially less processing on the network device. However, I certainly don't believe that this alone is a reason to do it.
If we want less bits on the wire, then adding support for a binary encoding (e.g. CBOR) to the existing YANG management protocols seems like a better path forwards to me since that seems to have the widest benefit.  CBOR encoded YANG (if using numerical "SIDs" rather than strings for the field names, draft-ietf-core-yang-cbor) is a pretty tight encoding, and is designed for IOT and constrained devices.  A CBOR encoding probably won't be quite as compact as custom TLVs, but I doubt that it would be significantly bigger either, and it has quite a few other benefits (code reuse, can be generically decoded).

Thanks,
Rob

Thanks,
Acee

On 7/5/18, 6:49 AM, "GROW on behalf of Lizhenbin" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Hi Jeff,
                                 -----Original Message-----

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Randy Bush <[email-masked]>
Date: Sat, 07 Jul 2018 20:25:19 -0700

robin,

i am not ignoring you.  i did not want to write unless i had something
possibly useful to say; and that requires pretending to think, always
difficult.

> I would also like to propose following draft for your reference which
> trigger us to move forward for better network maintenance with
> multiple tools in which gRPC/NETCOF and NMP/BMP may play different
> roles: https://datatracker.ietf.org/doc/draft-song-ntf/

[ warning: my memory is likely fuzzy, and the glass is dark ]

at an ietf in the late '90s[0], there was a hastily called meeting of
the snmp standards bearers and a bunch of operators.  the snmp folk were
shocked to learn that no operators used snmp for other than monitoring;
no one had snmp write enabled on devices; ops configured with the
cli[1].  from this was born netconf and the xml path.  credit where due:
phil eng was already well down this path at the time of that meeting.

but netconf/xml was a mechanism and lacked a model.  snmp had models,
whether we thought they were pretty or not.  thus yang was born, and ,
of course, a new generation wants to use the latest modern toys such as
restconf, openconfig, json, ...

draft-song-ntf yearns for an "architectural framework for network
telemetry," a lofty and worthwhile goal not, a priori, a bad one.  but a
few comments from a jaded old dog.

for a new paradigm to gain traction, it must be *significantly* better
than the old one, or the old paradigm must be clearly failing.  in the
story above, snmp was clearly failing, aside from using an unfashionable
encoding.  and yang clearly provided something needed and missing from
netconf.  note that this paradigm shift has taken over 20 years; and we
dis the itu et alia.

second, draft-song-ntf is an export-only model.  while telemetry is
extremely important, i will be very frustrated if i can only hear and
may not speak.  and the more it evolves to a really attractive paradigm
and model, the more annoyed i will be that i can not use it for control.

and lastly, to quote don knuth, "premature optimization is the root of
all evil."  do not get distracted by squeezing bits out of an encoding.
focus on things such as simple, clear, securable, extensible ...

randy

---

0 - i would love help pinning down which meeting

1 - i still have the "it's the cli, stupid" tee shirt.  an american
    political slogan of the era was "it's the economy, stupid."

---

From: Jeff Tantsura <[email-masked]>
Date: Sun, 8 Jul 2018 18:04:50 -0700

Robin,

Einar pointed exactly right points, very little to add.
Let’s keep is-is (narrow) scope.
1. There’s operational state of the protocol - I don’t really see what’s
missing in IETF/OpenConfig YANG models that would nessesarily require new
work?
Please be specific in your answers

2. What’s in LSDB - to my understanding you are not looking at that?
Reading your draft - it only concerns operational state,  not the content,
so BMP is not really a comparable solution either...

Wrt gRPC and some other work being done by OpenConfig/open source community
- besides Einar’s points - we have got great working relationship with the
team working on these technologies, there are gRPC and gNMI drafts in RTGWG
that would be updated when the need arise.
Wrt performance - there’s significant amount of research/testing and
comparisons of gRPC vs most of other RPC solutions, at scale, we in
networking won’t reach in quite some time, I’d advice to look it up. We
could discuss other advantages of running on top of HTTPv2 separately.

Please note - I’m not judging your proposal, but trying to understand why,
we as the community should be spending time and effort on it, so far you
you didn’t manage to convince me.

Looking forward to your reply.

Thanks,
Jeff

On Thu, Jul 5, 2018 at 04:45 Einar Nilsen-Nygaard (einarnn) <
[email-masked]> wrote:

>    - #1 – The draft ISIS model doesn’t seem to have many lateral
>    dependencies as far as I can see. And if it is incomplete from the
>    perspective of monitoring the health of ISIS, then it should be extended.
>    I’m not sure why it would be difficult to stabilise the definition?
>    - #2 – This seems to be the same issue of an incomplete model. Can you
>    clearly articulate any data that you think should be available that *cannot
>    be modelled in YANG*?
>    - #3 – Agreed that exporting high volume, low latency telemetry one
>    the baseline transport suggested in ietf-netconf-yang-push would
>    perhaps have issues. This is one of the reasons why transport extensibility
>    is an explicit part of the draft.
>    - #4 – IMO, as long as the encoding for data is clearly defined in an
>    "open" way, then this is not really an issue yet. I still think we need to
>    experiment with encodings, but I do not think an entirely new protocol will
>    serve network operators.
>
>
> I’d also like to add to the last point and say that I do not think adding
> new protocols and new encodings will serve network operators well. Over the
> last few years operators have been making it clear that they want to
> simplify their interactions with the network, and not have more things they
> need to understand thrown at them. Acee isn’t suggesting deprecating BMP,
> and neither am I, but in at least two discussions with operators I have
> attended, when introduced to BMP, their initial reaction could be
> summarised as "this looks interesting, but why have you introduced
> *another* protocol for this?"
>
> I completely support identifying the use cases you have, but would really
> like to see us focus on rectifying any deficiencies we can identify with
> existing proposals, rather than dilute our efforts.
>
> Cheers,
>
> Einar
>
> On 5 Jul 2018, at 11:48, Lizhenbin <[email-masked]> wrote:
>
> Hi Jeff,
> 1. Based on my experience in the YANG model work, it may be not
> satisfactory for these models does not define config/oper of all features
> of specific protocol and these models have much relation with each other
> and it is difficult to stabilize the definition.
> 2. For monitoring the control protocol, it is not enough based on the
> existing YANG models such as the packets of control protocol which should
> be monitored but not defined in YANG models.
> We would like to define the NMP based on the usecases. That is, a specific
> set of parameters exported by NMP can satisfy the purpose of a specific
> usecase. Thus the protocol can be deployed incrementally.
>
>
> Best Regards,
> Robin
>
>
>
> From: Jeff Tantsura [mailto:[email-masked]
> <[email-masked]>]
> To: Acee Lindem (acee) <acee=[email-masked]>; Lizhenbin <
> [email-masked]>; [email-masked]; [email-masked]
> Subject: Re: [Lsr] [GROW] FW: New Version Notification for
> draft-gu-network-mornitoring-protol-00.txt
>
> Robin,
>
> Protocol YANG models developed in the last years clearly provide much
> better and more scalable approach to what has been proposed in the draft,
> since we are talking is-is - look at notifications in
> draft-ietf-isis-yang-isis-cfg. How do you propose to corelate operational
> state to configuration?
>
> gRPC provides high performance RPC framework  to streaming the telemetry
> data that is structured, easy to consume and extend.
>
> I'm not going to go into technical discussion, however would appreciate
> your response as to why NMP (please do not restate the points in the
> section 4 of the draft, they are quite incorrect)
>
> Thanks!
>
> Cheers,
> Jeff
>
> On 7/3/18, 09:21, "Lsr on behalf of Acee Lindem (acee)" <
> [email-masked] on behalf of acee=[email-masked]> wrote:
>
>    Hi Robin,
>    I'm not arguing to deprecate BMP. What I am arguing is that the fact
> that BMP was created 15 years ago doesn't necessarily mean we should create
> an analogous IMP for IS-IS given the current IETF OPS technologies and the
> fact that faster link speeds and Moore's law facilitate deployment of these
> new OPS technologies. Anyway, I looked at the agenda and I will definitely
> attend GROW on Wednesday afternoon for the discussion.
>    Thanks,
>    Acee
>
>        From: OPSAWG [mailto:[email-masked]
> <[email-masked]>] On Behalf Of Acee Lindem (acee)
>        To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) <
> [email-masked]>; [email-masked]; [email-masked]
>        Subject: Re: [OPSAWG] [GROW] FW: New Version Notification for
> draft-gu-network-mornitoring-protol-00.txt
>
>        [Robin] In the draft we simply mention the difference between NMP
> and protocols you mentioned for the management plane. Though there is maybe
> some overlap between the two types of protocols, the protocols you
> mentioned is not enough for monitoring the control protocol. For example,
> would we like to use YANG and NETCONF, RESTCONF, or gNMI to export the
> packets of control protocols such as update message of BGP and/or ISIS PDU,
> etc. for the purpose of monitoring?
>
>
>        Operators and vendors are doing this anyway. A second alternative
> would be to listen passively in IS-IS (or OSPF for that matter). Why would
> anyone want this?
>        [Robin] In fact we tried the method you proposed. From our point of
> view, the basic design principle should be that the monitoring entity
> should be decoupled from the monitored entity. This is to avoid following
> cases:
>        2. The limitation of the control protocol will also have effect on
> the monitoring. For example, for the method of listening passively, if
> there are multiple hops between the listener and the network devices, it
> has to set up a tunnel as the virtual link for direct connection. But the
> TCP-based monitoring protocol need not care about it.
>
>
>        As far as where it belongs, we have a rather full agenda in LSR so
> I don't think we want to devote time to it there at IETF 102.
>        [Robin] Though the WG the draft should belong to is not determined
> yet, we think the work belongs to OPS area and send the notice to GROW WG
> and OPSAWG. We also applied for the presentation in the two WGs. We should
> have copied the notice to the related WGs of RTG area. So the LSR WG and
> RTGWG WG mailing list are added. More comments and suggestions are welcome.
>
>        Thanks,
>        Acee
>
>
>
>        On 7/2/18, 8:20 AM, "GROW on behalf of Guyunan (Yunan Gu, IP
> Technology Research Dept. NW)" <[email-masked] on behalf of
> [email-masked]> wrote:
>
>            Dear GROW & OPSAWG WGs,
>
>            We have proposed a Network Monitoring Protocol (NMP) for the
> control plane OAM. NMP for ISIS is illustrated in this draft to showcase
> the benefit and operation of NMP. Yet, we haven't decided which WG it
> belongs to.
>
>
>            From: [email-masked] [mailto:[email-masked]
> <[email-masked]>]
>            Sent: 2018年7月2日 20:07
>            To: Zhuangshunwan <[email-masked]>; Lizhenbin <
> [email-masked]>; Guyunan (Yunan Gu, IP Technology Research Dept.
> NW) <[email-masked]>
>            Subject: New Version Notification for
> draft-gu-network-mornitoring-protol-00.txt
>
>
>            URL:
> https://www.ietf.org/internet-drafts/draft-gu-network-mornitoring-protol-00.txt
>            Status:
> https://datatracker.ietf.org/doc/draft-gu-network-mornitoring-protol/
>            Htmlized:
> https://tools.ietf.org/html/draft-gu-network-mornitoring-protol-00
>            Htmlized:
> https://datatracker.ietf.org/doc/html/draft-gu-network-mornitoring-protol
>
>
>            Abstract:
>            Please note that it may take a couple of minutes from the time
> of submission until the htmlized version and diff are available at
> tools.ietf.org.
>
>            The IETF Secretariat
>

---

From: Greg Skinner <[email-masked]>
Date: Sun, 08 Jul 2018 20:58:35 -0700

Randy,

Is the OPS-NM Configuration Management Requirements (ops-nm) Bof <https://www.ietf.org/proceedings/52/176.htm> from IETF 52 (10 December 2001) the meeting you were thinking of?  There are also references to an IAB meeting in 2002 about the lack of use of SNMP for network configuration in SNMP compared with CLI, Netconf, Netflow <https://www.snmpcenter.com/snmp-versus-other-protocols/> that culminated in RFC 3535 <https://tools.ietf.org/html/rfc3535>.

Robin,

Regarding the draft in question, I generally agree with the concerns others have made that it doesn’t appear to provide anything that other technologies such as YANG provide.  Also, IMO, the draft needs considerable work to be more easily understood.  For example, there are many acronyms such as CSNP and PSNP that are not defined, and may be misunderstood by readers not familiar with ISIS.  In the packet format sections, there are several uncapitalized uses of ‘should’.  Do the authors consider these to be non-normative requirements?  There are also statements such as "Network OAM statistics show that a relatively large part of the network issues are caused by the disfunction of various routing protocols and MPLS signalings” that are offered without citations.

Regards,
Greg

> On Jul 7, 2018, at 8:25 PM, Randy Bush <[email-masked]> wrote:
> 
> robin,
>

---

From: Haoyu song <[email-masked]>
Date: Mon, 9 Jul 2018 21:57:17 +0000

Hi Randy,

Thank you for comments on draft-song-ntf.
I'm not sure I understand your second point. Could you please clarify it?
Please note we didn't enforce any specific model on the telemetry yet. This doc only concerns the aspect on how to acquire data from networks. It does support the dynamic and interactive configuration for data acquirement. But control is out of scope of this document, although we confirm that telemetry plus control complete the closed control loop. Maybe I misunderstood your point.
Thanks!

Haoyu

-----Original Message-----
From: OPSAWG [mailto:[email-masked]] On Behalf Of Randy Bush
Sent: Saturday, July 07, 2018 8:25 PM
To: Lizhenbin <[email-masked]>
Cc: [email-masked]; GMO Crops <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [OPSAWG] [GROW] [Lsr] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

robin,

i am not ignoring you.  i did not want to write unless i had something possibly useful to say; and that requires pretending to think, always difficult.

at an ietf in the late '90s[0], there was a hastily called meeting of the snmp standards bearers and a bunch of operators.  the snmp folk were shocked to learn that no operators used snmp for other than monitoring; no one had snmp write enabled on devices; ops configured with the cli[1].  from this was born netconf and the xml path.  credit where due:
phil eng was already well down this path at the time of that meeting.

but netconf/xml was a mechanism and lacked a model.  snmp had models, whether we thought they were pretty or not.  thus yang was born, and , of course, a new generation wants to use the latest modern toys such as restconf, openconfig, json, ...

draft-song-ntf yearns for an "architectural framework for network telemetry," a lofty and worthwhile goal not, a priori, a bad one.  but a few comments from a jaded old dog.

for a new paradigm to gain traction, it must be *significantly* better than the old one, or the old paradigm must be clearly failing.  in the story above, snmp was clearly failing, aside from using an unfashionable encoding.  and yang clearly provided something needed and missing from netconf.  note that this paradigm shift has taken over 20 years; and we dis the itu et alia.

second, draft-song-ntf is an export-only model.  while telemetry is extremely important, i will be very frustrated if i can only hear and may not speak.  and the more it evolves to a really attractive paradigm and model, the more annoyed i will be that i can not use it for control.

and lastly, to quote don knuth, "premature optimization is the root of all evil."  do not get distracted by squeezing bits out of an encoding.
focus on things such as simple, clear, securable, extensible ...

randy

---

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Wed, 11 Jul 2018 00:40:58 +0000

Hi Robin, Yunan, Shunwan,

I'm a little late to this thread due to being preoccupied with a newborn.

Below are my comments, which take into consideration the other comments… sans the YANG/telemetry debate.  Considering we do use BGP-LS extensively, I don't think YANG is the only solution to these link-state monitoring use-cases.

BMP doesn't change or limit what's available in BGP. It encapsulates and multiplexes BGP over a single stream for remote monitoring.   BGP-LS (RFC7752) can be used today to monitor link state protocols (ISIS, OSPF).  BGP-LS also can be used to monitor EPE and direct/static routes, which is a bit of a stretch on putting that in BGP-LS, but nonetheless…  BGP-LS is available via BMP.

"Section 3.1, ISIS Adjacency Issues"

As written, this is covered by BGP-LS LINK NLRI.  We see a LINK change (advertised verses withdrawn) when the adjacency changes.  If the router dies or the control-plane fails in some way, we still see the NLRI change from the other side of the adjacency (perspective).

What we are missing is a BGP-LS "attribute" tlv (on local entries) for links/nodes that indicates the REASON why the LINK (also NODE) is withdrawn, but.... this is not available without changing the IGP protocol itself (e.g. new ISIS TLV) or by implementing a solution architecture that requires BGP-LS feeds from all ISIS/OSPF nodes.  As written, I see NMP (including Netconf/gNMI/telemetry) requiring sessions from all nodes since the targeted data is not available in ISIS TLV's today.   For example, the ISIS LSDB on node-A does not have any local (device specific) information from all the other nodes unless there are TLV's to convey that information.

Regarding requiring BGP-LS feeds from many or all nodes...  We need this regardless of this draft because of segment-routing/egress peer engineering.   Due to EPE, we already recommend BGP-LS peering (feeds) from all EPE nodes (normally via a peering server) so that we can collect/monitor EPE (hopefully using https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-01). Adding LINK/NODE withdrawal/down reason should not overstep into YANG/Netconf/Telemetry.

"3.2.  Forwarding Path Disconnection"

This seems to be more of a fit for telemetry with interface/link monitoring.  Although, if the link was working at some point and it goes down due to MTU or otherwise, the BGP-LS REASON attribute should be able to convey that.  BGP-LS wouldn't convey anything if the link was never established.  Currently, it's assumed that the link advertisement means it's established.  This could be changed if we added a LINK NLRI state TLV.   The LINK could be updated (advertised) multiple times, changing based on state.   If the LINK doesn't establish, the withdrawal could indicate the reason.

"3.3.  ISIS LSP Synchronization Failure"

If a new BGP-LS LINK attribute is used as mentioned above to convey LINK adv state, it should then be feasible to add a state to indicate inconsistency. If the link/adj changes to down, then the withdrawal LINK reason attribute could indicate the cause.

The BGP-LS reason and state tlv's would only apply to the links/nodes that originate from the BGP-LS speaker.  Other node/link advertisements would not have the attribute/tlv.   This is why the solution would recommend enabling BGP-LS feeds from nodes that matter enough to get this level of local info.  This btw would solve a problem we have with BGP-LS today where optional TLV's are not present unless ISIS/OSPF have specific features enabled, such as traffic-engineering... even IPv4/IPv6 router ID's are not included unless enabled specifically (isis) per node.

"4.  Extensions of NMP for ISIS"

Most of the new messages are redundant to the existing BGP-LS advertisements and withdrawals.  Telemetry of course could also convey this…

The initiation message could lead to overloading it with all kinds of device specific info.   Some constraint is needed.

The per peer (adjacency) header is missing multi-topology.  BGP-LS includes the protocol type (e.g. CT) and MT (missing from this draft).

All in all, I believe the use-cases described have merit and I think we can do this with BGP-LS, which doesn't require BMP but could be used.

Thanks,
Tim

On 7/8/18, 8:59 PM, "GROW on behalf of Greg Skinner" <[email-masked]<mailto:[email-masked]> on behalf of gregskinner0=[email-masked]<mailto:gregskinner0=[email-masked]>> wrote:

Randy,

Is the OPS-NM Configuration Management Requirements (ops-nm) Bof<https://www.ietf.org/proceedings/52/176.htm> from IETF 52 (10 December 2001) the meeting you were thinking of?  There are also references to an IAB meeting in 2002 about the lack of use of SNMP for network configuration in SNMP compared with CLI, Netconf, Netflow<https://www.snmpcenter.com/snmp-versus-other-protocols/> that culminated in RFC 3535<https://tools.ietf.org/html/rfc3535>.

Robin,

Regards,
Greg

On Jul 7, 2018, at 8:25 PM, Randy Bush <[email-masked]<mailto:[email-masked]>> wrote:

robin,

randy

---

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Jul 2018 11:24:52 +0200

Tim,

I already suggested use of BGP-LS *as-is* in this thread on Jul 6th.

But I guess we all agree that this is not the best use of BGP protocol to
be now a vehicle of NMS only because it is easy with BGP to establish a TCP
session and to distribute "stuff" in a relatively loop free fashion.

Thx,
R.

On Wed, Jul 11, 2018 at 2:40 AM, Tim Evens (tievens) <
tievens=[email-masked]> wrote:

> Below are my comments, which take into consideration the other comments…
> sans the YANG/telemetry debate.  Considering we do use BGP-LS extensively,
> I don't think YANG is the only solution to these link-state monitoring
> use-cases.
>
>
>
> BMP doesn't change or limit what's available in BGP. It encapsulates and
> multiplexes BGP over a single stream for remote monitoring.   BGP-LS
> (RFC7752) can be used today to monitor link state protocols (ISIS, OSPF).
> BGP-LS also can be used to monitor EPE and direct/static routes, which is a
> bit of a stretch on putting that in BGP-LS, but nonetheless…  BGP-LS is
> available via BMP.
>
>
>
> As written, this is covered by BGP-LS LINK NLRI.  We see a LINK change
> (advertised verses withdrawn) when the adjacency changes.  If the router
> dies or the control-plane fails in some way, we still see the NLRI change
> from the other side of the adjacency (perspective).
>
>
>
> What we are missing is a BGP-LS "attribute" tlv (on local entries) for
> links/nodes that indicates the REASON why the LINK (also NODE) is
> withdrawn, but.... this is not available without changing the IGP protocol
> itself (e.g. new ISIS TLV) or by implementing a solution architecture that
> requires BGP-LS feeds from all ISIS/OSPF nodes.  As written, I see NMP
> (including Netconf/gNMI/telemetry) requiring sessions from all nodes since
> the targeted data is not available in ISIS TLV's today.   For example, the
> ISIS LSDB on node-A does not have any local (device specific) information
> from all the other nodes unless there are TLV's to convey that information.
>
>
>
> Regarding requiring BGP-LS feeds from many or all nodes...  We need this
> regardless of this draft because of segment-routing/egress peer
> engineering.   Due to EPE, we already recommend BGP-LS peering (feeds) from
> all EPE nodes (normally via a peering server) so that we can
> collect/monitor EPE (hopefully using https://tools.ietf.org/html/
> draft-ietf-grow-bmp-local-rib-01). Adding LINK/NODE withdrawal/down
> reason should not overstep into YANG/Netconf/Telemetry.
>
>
>
> This seems to be more of a fit for telemetry with interface/link
> monitoring.  Although, if the link was working at some point and it goes
> down due to MTU or otherwise, the BGP-LS REASON attribute should be able to
> convey that.  BGP-LS wouldn't convey anything if the link was never
> established.  Currently, it's assumed that the link advertisement means
> it's established.  This could be changed if we added a LINK NLRI state
> TLV.   The LINK could be updated (advertised) multiple times, changing
> based on state.   If the LINK doesn't establish, the withdrawal could
> indicate the reason.
>
>
>
> If a new BGP-LS LINK attribute is used as mentioned above to convey LINK
> adv state, it should then be feasible to add a state to indicate
> inconsistency. If the link/adj changes to down, then the withdrawal LINK
> reason attribute could indicate the cause.
>
>
>
> The BGP-LS reason and state tlv's would only apply to the links/nodes that
> originate from the BGP-LS speaker.  Other node/link advertisements would
> not have the attribute/tlv.   This is why the solution would recommend
> enabling BGP-LS feeds from nodes that matter enough to get this level of
> local info.  This btw would solve a problem we have with BGP-LS today where
> optional TLV's are not present unless ISIS/OSPF have specific features
> enabled, such as traffic-engineering... even IPv4/IPv6 router ID's are not
> included unless enabled specifically (isis) per node.
>
>
>
> Most of the new messages are redundant to the existing BGP-LS
> advertisements and withdrawals.  Telemetry of course could also convey
> this…
>
>
>
> The initiation message could lead to overloading it with all kinds of
> device specific info.   Some constraint is needed.
>
>
>
> The per peer (adjacency) header is missing multi-topology.  BGP-LS
> includes the protocol type (e.g. CT) and MT (missing from this draft).
>
>
>
> All in all, I believe the use-cases described have merit and I think we
> can do this with BGP-LS, which doesn't require BMP but could be used.
>
>
>
> Thanks,
>
> Tim
>
>
>
>
>
> On 7/8/18, 8:59 PM, "GROW on behalf of Greg Skinner" <
> [email-masked] on behalf of gregskinner0=40icloud.com@
> dmarc.ietf.org> wrote:
>
>
>
> Randy,
>
>
>
> Is the OPS-NM Configuration Management Requirements (ops-nm) Bof
> <https://www.ietf.org/proceedings/52/176.htm> from IETF 52 (10 December
> 2001) the meeting you were thinking of?  There are also references to an
> IAB meeting in 2002 about the lack of use of SNMP for network configuration
> in SNMP compared with CLI, Netconf, Netflow
> <https://www.snmpcenter.com/snmp-versus-other-protocols/> that culminated
> in RFC 3535 <https://tools.ietf.org/html/rfc3535>.
>
>
>
> Robin,
>
>
>
> Regarding the draft in question, I generally agree with the concerns
> others have made that it doesn’t appear to provide anything that other
> technologies such as YANG provide.  Also, IMO, the draft needs considerable
> work to be more easily understood.  For example, there are many acronyms
> such as CSNP and PSNP that are not defined, and may be misunderstood by
> readers not familiar with ISIS.  In the packet format sections, there are
> several uncapitalized uses of ‘should’.  Do the authors consider these to
> be non-normative requirements?  There are also statements such as "Network
> OAM statistics show that a relatively large part of the network issues are
> caused by the disfunction of various routing protocols and MPLS signalings”
> that are offered without citations.
>
>
>
> Regards,
>
> Greg
>
>
>

---

From: Randy Bush <[email-masked]>
Date: Wed, 11 Jul 2018 08:56:30 -0400

> session and to distribute "stuff" in a relatively loop free fashion.

now that dns over tcp/tls is being deployed, we can return to the other
overused protocol.  < emoji for drippinng sarcasm >

randy

---

From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[email-masked]>
Date: Thu, 12 Jul 2018 02:34:32 +0000

Hi Greg, Jeff, Acee, Robert Wilton, Einar,

and anyone who has concern with NMP vs. gRPC/YANG, thanks for your interest in our draft and your valuable comments. Regarding this question, we’d like to state the following two points.

1.      Control plane (CP) and management plane (MP) information retrieval/manipulation decoupling:

As stated in the draft, we propose NMP to monitor the running status of routing protocols, which can be considered as a CP telemetry approach (so is BMP). MP telemetry approaches, such as SNMP, NETCONF and so on, have longer histories and are better developed than CP telemetry. However, there exists differences between the CP and MP data, and it’s not necessarily appropriate to reuse the existing MP approaches for CP monitoring.

First of all, MP data reflects information from the device viewpoint, including the device status information (e.g., CPU, interface, memory…) and configuration actions (e.g., set timer…), while CP data reflects information from the protocol viewpoint, e.g., protocol PDU (e.g., ISIS LSP/Hello) and protocol statistics. Specifically, the availability of real-time protocol PDUs collected from all monitored routers is necessary for NMP troubleshooting analysis. Such per-router PDU monitoring of NMP provides much more information than one LSDB collected from a single router in an area/AS using BGP-LS. For example, in the case an ISIS adjacency fails to set up due to mismatched authentications, analyzing the Hello statistics alone is not sufficient. Comparing the Hello PDUs sent from both devices can provide insight into authentication differences. Another example that in a route flapping case, caused by corrupted LSP remaining lifetime, a locally sent LSP and an LSP received at the remote device can be compared/analyzed to localize the corruption.

Secondly, MP telemetry mainly focuses on things like VPN configuration, tunnel configuration and so on, while NMP are proposed to facilitate protocol troubleshooting. Apparently, troubleshooting is more time-sensitive compared with things like VPN configuration. In addition, CP information, e.g., protocol PDUs, is updating continuously with time and thus needing real-time report. MP data are less dynamic compared to CP.

Thirdly, a key principle of CP telemetry is to keep the monitoring protocol independent from the monitored protocol. Thus a unidirectional monitoring protocol, just like BMP, could avoid any possible interference to the monitored protocol.

Thus, we believe it’s necessary to decouple the CP monitoring from the MP telemetry.

2.      Why not gRPC/YANG for CPT?

We agree that it’s technically workable to use gRPC/YANG to model and convey CP data, like Hello/LSP, however we think it’s simply not the best choice for CP monitoring.

First all, as the major component of CP monitoring data, the protocol PDUs are already in binary format, and are transmission-ready with nice performance. The protocol statistics can be easily encoded as TLVs and added to transmission. Thus, modeling CP data into YANG first and then encoding it as XML/protobuf for transmission is just extra work.

Secondly, in case of route flapping caused by timer issue (e.g., 100 times faster), the updates of LSP, Hello, and LSP purge could be in massive quantity, the modeling of all these PDUs into YANG may slow down the data export, thus delaying the troubleshooting process.

Thirdly, it might be not clear yet, but it could be possible that the YANG modeling process may affect the PDU data integrity in case when a bit-by-bit comparison of two PDUs is needed.

We also agree that information, like system ID/MTU, is more fit to be reported using gRPC/YANG. All in all, NMP is not meant to replace any existing OAM approach, but to work side by side with it and even data plane telemetry (e.g., iOAM) for better network troubleshooting.

BR,

Yunan

From: GROW [mailto:[email-masked]] On Behalf Of Greg Skinner
Sent: 2018年7月9日 11:59
To: Randy Bush <[email-masked]>; Lizhenbin <[email-masked]>
Cc: [email-masked]; GMO Crops <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [GROW] [Lsr] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

Randy,

Robin,

Regards,
Greg

robin,

randy

---

---

From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[email-masked]>
Date: Thu, 12 Jul 2018 06:36:23 +0000

Hi Tim, Robert,

Thanks a lot for your comments. Regarding the idea of using BGP-LS for troubleshooting, we have also considered the possible pros and cons.

BGP-LS is initially proposed for carrying link state information using BGP, and is currently used for applications like topology visualization. However, I would not consider it as a strict “monitoring” protocol. NMP is intended for network troubleshooting, which monitors the protocol running status, exporting information more than just link state. For example, as also pointed out by Tim, in the NMP adjacency up/down event notification, possible reasons are included. Such non-link-state information is not defined in BGP-LS. It might be technically worktable for BGP-LS to carry the reason data by adding some “attribute” TLV, or to carry any other non-link-state data used for troubleshooting (e.g., PDU statistics), but it kind of deviates from the original intention of proposing BGP-LS.

In addition, whatever data conveyed by BGP-LS NLRI needs to be supported/encapsulated in the ISIS/OSPF PDUs. This bring scalability issue and extra IGP extension work whenever new information for new troubleshooting use cases is required. Besides, the extra data is to be flooded with ISIS/OSPF throughout the area/AS, which consumes extra bandwidth and is unwanted.

Another concern for BGP-LS is the lack of per-device feed. As we have stated in another email: The availability of real-time protocol PDUs collected from all monitored routers is necessary for troubleshooting analysis. As Tim pointed out that:
“BGP-LS also can be used to monitor EPE and direct/static routes, which is a bit of a stretch on putting that in BGP-LS, but nonetheless…”
 “Regarding requiring BGP-LS feeds from many or all nodes...  We need this regardless of this draft because of segment-routing/egress peer engineering.   Due to EPE, we already recommend BGP-LS peering (feeds) from all EPE nodes (normally via a peering server) so that we can collect/monitor EPE (hopefully using https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-01).”
Although BGP-LS might be extended for multiple feeds in the future for specific purposes, to me, it again deviates from its original intention. And if we insist on extending BGP-LS for the purpose of troubleshooting, it just becomes NMP.

Regarding the comparison with other telemetry approaches, specifically gRPC/YANG, we have stated our points in the other email. To avoid repeating in this thread, please kindly refer to our previous email.

We agree with Tim that “The initiation message could lead to overloading it with all kinds of device specific info. Some constraint is needed. The per peer (adjacency) header is missing multi-topology.  BGP-LS includes the protocol type (e.g. CT) and MT (missing from this draft).”
In fact, not only during the initiation phase of the NMP session, but also during some network failure, e.g., route flapping, massive PDUs and other data are reported to the server. We think enabling different working modes (e.g., PDU compress mode, normal mode) of NMP at the device side could be a workable solution. We can refine this idea in the next version, as well as adding MT into the per-adjacency header.

BR,

Yunan

From: GROW [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: 2018年7月11日 17:25
To: Tim Evens (tievens) <tievens=[email-masked]>
Cc: Greg Skinner <gregskinner0=[email-masked]>; GMO Crops <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [GROW] [Lsr] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

Tim,

But I guess we all agree that this is not the best use of BGP protocol to be now a vehicle of NMS only because it is easy with BGP to establish a TCP session and to distribute "stuff" in a relatively loop free fashion.

Thx,
R.

On Wed, Jul 11, 2018 at 2:40 AM, Tim Evens (tievens) <tievens=[email-masked]<mailto:tievens=[email-masked]>> wrote:
Hi Robin, Yunan, Shunwan,

Thanks,
Tim

Randy,

Robin,

Regards,
Greg

robin,

randy

---