Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif

From: Kent Watsen <[email-masked]>
Date: Mon, 21 Sep 2020 22:13:28 +0000

Hi Andy,

Does Tianran’s response resolve your "I do not understand why the client needs this feature” comment?   As it currently stands, your comment reads like an objection.

The comment regarding if this work should be in its own RFC or as a Bis is a process-question to chairs can ask the WG after determining support for moving the work forward.

Kent and Mahesh, as NETCONF chairs.

> On Aug 10, 2020, at 11:28 PM, Tianran Zhou <[email-masked]> wrote:
> 
> Hi Andy,
>  
> Thanks for your review.
> Basically your understanding is correct.
> The background is about the distributed notif, which the global subscription will be decomposed to several component subscriptions.
> And the client need to compose the data from multiple publishers. It need to know if all the pieces of one data are received.
> Current solution depends on ietf-netconf-notification-messages. I just found it’s expired!
> I would like to discuss with authors about the plan on that draft. Fortunately you are one coauthor. Could you please help on the answer?
> Otherwise, we can seek other way.
>  
> Best,
> Tianran
>  
> From: netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Tuesday, August 11, 2020 3:39 AM
> To: Kent Watsen <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif
>  
> Hi,
>  
> I am trying to understand what problem this draft attempts to solve.
> It appears from the solution proposal is that the problem to be solved is
> the lack of message generator identifiers associated with configured subscriptions.
> These identifiers could presumably help a client understand some implementation details
> related to a subscription.  The solution seems to rely on the message-generator-id
> field in the notification message (which does not exist in current RFCs).
>  
> I do not understand why the client needs this feature.
>  
>  
> Andy
>  
>  
> On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen <[email-masked] <mailto:[email-masked]>> wrote:
> NETCONF WG,
> 
> Per the previous email sent moments ago, the chairs would like to solicit input on the following draft:
>  
>    Title: Subscription to Distributed Notifications
>    Link: https://tools.ietf.org/html/draft-unyte-netconf-distributed-notif <https://tools.ietf.org/html/draft-unyte-netconf-distributed-notif>
>    Abstract:
> 
>       This documents describes extensions to the YANG notifications
>       subscription to allow metrics being published directly from
>       processors on line cards to target receivers, while subscription is
>       still maintained at the route processor in a distributed forwarding
>       system.
>  
> 
> In particular, please discuss adoption-suitability as it regards to the following questions:
>  
>     1) is the problem important for the NETCONF WG to solve?
>     2) is the draft a suitable basis for the work?
> 
> 
> PS: this message is itself not an adoption poll, but rather an attempt to gauge interest/support for a potential future adoption poll.
> 
> NETCONF Chairs
> _______________________________________________
> netconf mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Sep 2020 15:31:05 -0700

On Mon, Sep 21, 2020 at 3:13 PM Kent Watsen <[email-masked]> wrote:

> Hi Andy,
>
> Does Tianran’s response resolve your "I do not understand why the client
> needs this feature” comment?   As it currently stands, your comment reads
> like an objection.
>
> The comment regarding if this work should be in its own RFC or as a Bis is
> a process-question to chairs can ask the WG after determining support for
> moving the work forward.
>

The overall approach to the binary push features seems a bit incoherent to
me.
I don't see much value in this draft, but no harm either so I do not have
an objection
to adoption.  Perhaps there is some debugging value here but since the
architecture
really does not define message generators as sub-components of a configured
subscription,
a client cannot expect any sort of consistent implementation of this field.

Andy

> The background is about the distributed notif, which the global
> subscription will be decomposed to several component subscriptions.
>
> And the client need to compose the data from multiple publishers. It need
> to know if all the pieces of one data are received.
>
> I would like to discuss with authors about the plan on that draft.
> Fortunately you are one coauthor. Could you please help on the answer?
>
> *From:* netconf [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Andy Bierman
> *Sent:* Tuesday, August 11, 2020 3:39 AM
> *To:* Kent Watsen <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [netconf] Adoption-suitability for
> draft-unyte-netconf-distributed-notif
>
>
>
> Hi,
>
>
>
> On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen <[email-masked]> wrote:
>
> NETCONF WG,
>
>    Link: https://tools.ietf.org/html/draft-unyte-netconf-distributed-notif
>    Abstract:
>
> PS: this message is itself not an adoption poll, but rather an attempt to
> gauge interest/support for a potential future adoption poll.
>
> NETCONF Chairs
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>
>
>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 21 Sep 2020 22:55:00 +0000

[As an individual contributor]

> The overall approach to the binary push features seems a bit incoherent to me.
> I don't see much value in this draft, but no harm either so I do not have an objection
> to adoption.  Perhaps there is some debugging value here but since the architecture
> really does not define message generators as sub-components of a configured subscription,

Good point. If I understand you correctly, what seems to be missing is an ability for the client to determine which generator-id is used by which publisher (e.g., line card).  The solution enables the client to partition notifications coming from different publishers, but that is it.  What value does this have to the client, I don’t know.  

Answering myself here, perhaps it enables two servers on the same IP address to send to the same receiver, as then the receiver doesn’t solely rely on source-IP address (assuming unauthenticated push) to designate the publisher?

Can the authors help resolve the value-proposition question here?

K.

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 22 Sep 2020 02:04:32 +0000

Thanks Andy for your opinion. And thank Kent for your expansion and further question.
The goal is to allow the client to know if it has received all the data pieces. Furthermore, the client know which publisher failed to send data. Then it depend on the client to do the action, e.g., ignore, require the data one more, …
We just use the generator-id to indicate the publisher, as we find it in ietf-netconf-notification-messages, and it’s very convenient for this usage.
One use case is exactly as Kent mentioned “Answering myself here, perhaps it enables two servers on the same IP address to send to the same receiver, as then the receiver doesn’t solely rely on source-IP address (assuming unauthenticated push) to designate the publisher”.
It’s also OK for us to use another indicator if the generator-id is not feasible.
“what seems to be missing is an ability for the client to determine which generator-id is used by which publisher (e.g., line card). ”
If necessary, maybe we can extend this mapping in some initial exchanges. To be clear, how do you want to name the publisher?

Thanks,
Tianran

From: netconf [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Tuesday, September 22, 2020 6:55 AM
To: Andy Bierman <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif

K.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 22 Sep 2020 08:10:28 -0700

[As a contributor]

Hi Tianran,

I am confused by the value statement. Maybe you can help clarify.

It would help if we can use a single terminology of publisher/subscriber instead of mixing it with client, which I understand to be the subscriber and server which I understand to be the publisher. Note, if HTTPS is used, the role of client and server would be reversed, so it is best to avoid using those terms.

See inline with [mj].

> On Sep 21, 2020, at 7:04 PM, Tianran Zhou <[email-masked]> wrote:
> 

[mj] What usage would be that? The usage of generator-id to indicate who is the publisher and thereby have the subscriber request for any missing data? I would like to note that nothing prevents usage of a reliable transport, e.g. HTTPS or TCP, with this draft. Would you still need a generator-id?

> It’s also OK for us to use another indicator if the generator-id is not feasible.

[mj] Precisely. If you use a reliable transport, you would have other means to identify the source of the notifications, in which case you would not need the generator-id.

Which goes back to the question of why we need a generator-id. If we do not want data loss, we should be using a reliable transport, in which case we do not need a generator-id. If we can tolerate data loss, e.g. with statistics, we do not care for generator-id because we are not going to ask for missing data. What use case requires us to use unreliable transport and yet need a generator-id?

Thanks.

> Can the authors help resolve the value-proposition question here?

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Sep 2020 09:57:40 -0700

On Mon, Sep 21, 2020 at 3:55 PM Kent Watsen <[email-masked]> wrote:

> Good point. If I understand you correctly, what seems to be missing is an
> ability for the client to determine which generator-id is used by which
> publisher (e.g., line card).  The solution enables the client to partition
> notifications coming from different publishers, but that is it.  What
> value does this have to the client, I don’t know.
>
>

The draft does not even have a section discussing the problem that needs to
be solved.
It is useful to distinguish between adoption of a problem-to-be-solved and
adoption of a draft.

Since I have to guess what problem this draft is solving, I suspect the
proposed solution
is just wrong.  The ietf-hardware module should be augmented
with a generator-id, not the subscriptions. The assumed problem is that
data reported from multiple publishers for the same subscription needs to
be correlated somehow.
The client can use the ietf-hardware info to determine the standard and
vendor-specific details
about the hardware sending the generator-id.

Andy

Answering myself here, perhaps it enables two servers on the same IP
> address to send to the same receiver, as then the receiver doesn’t solely
> rely on source-IP address (assuming unauthenticated push) to designate the
> publisher?
>

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 23 Sep 2020 06:51:03 +0000

Hi Mahesh,

Please see in line about my thoughts.

Thanks,
Tianran

From: Mahesh Jethanandani [mailto:[email-masked]]
Sent: Tuesday, September 22, 2020 11:10 PM
To: Tianran Zhou <[email-masked]>
Cc: Kent Watsen <[email-masked]>; Andy Bierman <[email-masked]>; [email-masked]
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif

[As a contributor]

Hi Tianran,

See inline with [mj].

On Sep 21, 2020, at 7:04 PM, Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:

ztr> Yes. But I just think if we can use the generator-id, we do not need to develop different ways for each transport. So that the procedure could be consistent.

ztr> Here we want to check the integrity, not the precise packet loss. For reliable transport, the receiver know how many sessions need to establish for one subscription. On the other hand,  if one session get lost, which subscriptions are impacted.
For the unreliable transport, one more case is, if one session is really bad (say 50% packet loss), the subscriber may need to do some action/adjustment. Yes we can tolerate data loss, but I think it should be a threshold.

Thanks.

Thanks,
Tianran

From: netconf [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Tuesday, September 22, 2020 6:55 AM
To: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif

K.

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

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 23 Sep 2020 07:44:22 -0700

Hi Tianran,

I think you are finally articulating some of the reasons why you need the generator-id. But they have nothing to do with being able to do data recovery.

In 108, the discussion on the mike made it clear that there was no expectation of data recovery if it got lost over the unreliable transport. The characteristics of the data, e.g. statistics, over that transport had to be such that subsequent updates would fill any gaps that were encountered because of packet loss. If you stop receiving updates on a particular session, you do not know if it was because the line card has nothing to send or it has been removed. 

So the reasons for having a generator-id have to do with identifying the session or the line card where the data is originating from. The point that Andy raised about ietf-hardware therefore is relevant here. What happens if the line card is removed and replaced with another but similar line card? What generator-id would be used? What happens if the same line card is removed and reinserted? What generator-id would be used?

The draft needs to describe these as the problems it is solving, and how it is going to solve it.

> On Sep 22, 2020, at 11:51 PM, Tianran Zhou <[email-masked]> wrote:
> 
>  
> [As a contributor]
>  
> Hi Tianran,
>  
> On Sep 21, 2020, at 7:04 PM, Tianran Zhou <[email-masked] <mailto:[email-masked]>> wrote:
>  
> From: netconf [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Kent Watsen
> To: Andy Bierman <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
>  
>  
>  
> 
>  

Mahesh Jethanandani
[email-masked]

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 24 Sep 2020 06:27:15 +0000

Hi Mahesh,

Your understanding is correct. Sorry for not making it clear.
Thanks for your advice. We will work on the text as you suggested in the working version.

Cheers,
Tianran

Sent: Wednesday, September 23, 2020 10:44 PM

Hi Tianran,

On Sep 22, 2020, at 11:51 PM, Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:

[As a contributor]

Hi Tianran,

See inline with [mj].

Thanks.

Thanks,
Tianran

K.

Mahesh Jethanandani

Mahesh Jethanandani

---

From: <[email-masked]>
Date: Sun, 27 Sep 2020 16:55:24 +0000

Hi Andy and Mahesh,

As a coauthor of draft-unyte-netconf-distributed-notif. Thank you very much for the feedback. Your remarks about reasoning of generator-id and augmenting ietf-hardware.yang. Both are valid inputs which need to be further clarified. I like them very much.

Same to IPFIX, draft-unyte-netconf-distributed-notif enables RFC8641 to work with distributed forwarding systems as described in Section 1 of draft-unyte-netconf-distributed-notif.

https://tools.ietf.org/html/draft-unyte-netconf-distributed-notif-00#section-1<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-unyte-netconf-distributed-notif-00%23section-1&data=02%7C01%7CThomas.Graf%40swisscom.com%7C50d6123d5c9f43799de908d862c0205f%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637367924602767119&sdata=LEeMr1Cl19DTSQtAWHika1IuRfknZXNs1trjZJMQkec%3D&reserved=0>

   This documents complement the general subscription requirements

   defined in section 4.2.1 of [RFC7923]<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7923%23section-4.2.1&data=02%7C01%7CThomas.Graf%40swisscom.com%7C50d6123d5c9f43799de908d862c0205f%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637367924602767119&sdata=49IVDvV%2BgkgaoghXoLIU%2BcUXs%2FToSXckxRtDpCRm02A%3D&reserved=0> by the paragraph: A

   Subscription Service MAY support the ability to export from multiple

   software processes on a single routing system and expose the

   information which software process produced which message to maintain

   data integrity.

Since we are not re-inventing the wheel, generator-id Is already existing in IPFIX. It is called "Observation Domain ID".

RFC 7011 Section 2 and Section 3.1 describe the terms "Observation Domain" and "Observation Domain ID"

https://tools.ietf.org/html/rfc7011#section-2<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7011%23section-2&data=02%7C01%7CThomas.Graf%40swisscom.com%7C50d6123d5c9f43799de908d862c0205f%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637367924602777092&sdata=zdQgtg%2B0OZ8Yqo94HHE0faOd1W2lz0JUfhXEpoUA1Qo%3D&reserved=0>

   Observation Domain

      An Observation Domain is the largest set of Observation Points for

      which Flow information can be aggregated by a Metering Process.

      For example, a router line card may be an Observation Domain if it

      is composed of several interfaces, each of which is an Observation

      Point.  In the IPFIX Message it generates, the Observation Domain

      includes its Observation Domain ID, which is unique per Exporting

      Process.  That way, the Collecting Process can identify the

      specific Observation Domain from the Exporter that sends the IPFIX

      Messages.  Every Observation Point is associated with an

      Observation Domain.  It is RECOMMENDED that Observation Domain IDs

      also be unique per IPFIX Device.

https://tools.ietf.org/html/rfc7011#section-3.1<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7011%23section-3.1&data=02%7C01%7CThomas.Graf%40swisscom.com%7C50d6123d5c9f43799de908d862c0205f%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637367924602777092&sdata=lRYHtxKHe8LN0Vdw07ZmBglERBnR4fdfbvVV6Pcja3g%3D&reserved=0>

   Observation Domain ID

      A 32-bit identifier of the Observation Domain that is locally
      unique to the Exporting Process.  The Exporting Process uses the
      Observation Domain ID to uniquely identify to the Collecting
      Process the Observation Domain that metered the Flows.  It is
      RECOMMENDED that this identifier also be unique per IPFIX Device.
      Collecting Processes SHOULD use the Transport Session and the
      Observation Domain ID field to separate different export streams
      originating from the same Exporter.  The Observation Domain ID
      SHOULD be 0 when no specific Observation Domain ID is relevant for
      the entire IPFIX Message, for example, when exporting the
      Exporting Process Statistics, or in the case of a hierarchy of
      Collectors when aggregated Data Records are exported.

These are the only two paragraphs I found in RFC 7011 describing the reasoning and application of "Observation Domain ID".

Speaking from an network operators and a data-collection perspective, one of the reasons we use "Observation Domain ID" in IPFIX and "generator-id" in YANG Notifications is to pin point from which network processor loss or corrupt metrics are coming from. In the last 12 months, we experienced twice, that a network processor was programmed falsely. Just to give an example.

As Tianran pointed out already and described in Section 7 of draft-unyte-netconf-distributed-notif

https://tools.ietf.org/html/draft-unyte-netconf-distributed-notif-00#section-7<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-unyte-netconf-distributed-notif-00%23section-7&data=02%7C01%7CThomas.Graf%40swisscom.com%7C50d6123d5c9f43799de908d862c0205f%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637367924602787040&sdata=u5U91Jft7j6eMDDm6uhGhfdTISxFm4UCe3ez8FGq5Ec%3D&reserved=0>

   All Publisher Agents share the same source IP address for data

   export.  For connectionless data transport such as UDP based

   transport [I-D.unyte-netconf-udp-notif<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-unyte-netconf-distributed-notif-00%23ref-I-D.unyte-netconf-udp-notif&data=02%7C01%7CThomas.Graf%40swisscom.com%7C50d6123d5c9f43799de908d862c0205f%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637367924602787040&sdata=3vXJPChHfW%2BDRdZo1FQA1bPLGTkZyWsxUnPCY3vljM4%3D&reserved=0>] the same Layer 4 source port

   for data export can be used.  For connection based data transport

   such as HTTPS based transport [I-D.ietf-netconf-https-notif<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-unyte-netconf-distributed-notif-00%23ref-I-D.ietf-netconf-https-notif&data=02%7C01%7CThomas.Graf%40swisscom.com%7C50d6123d5c9f43799de908d862c0205f%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637367924602796993&sdata=5UbHYmbt6k%2B4TDwgfjsJ16vjO6ZTeFnz%2F3EiORsN4L0%3D&reserved=0>], each

   Publisher Agent MUST be able to acknowledge packet retrieval from

   Receivers, and therefore requires a dedicated Layer 4 source port per

   software process.

The IP address and Layer 4 port transport information is not enough to identify the export process of the network processor on the line card.

This is also described in draft-unyte-netconf-udp-notif In section 3.2

https://tools.ietf.org/html/draft-unyte-netconf-udp-notif-00#section-3.2<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-unyte-netconf-udp-notif-00%23section-3.2&data=02%7C01%7CThomas.Graf%40swisscom.com%7C50d6123d5c9f43799de908d862c0205f%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637367924602796993&sdata=ecy89L6tqNZW6a0D6Lz2fJu1A83f4fjQndpnrxiYcTM%3D&reserved=0>

   The UDP-Notif Message Header contains information that facilitate the

   message transmission before deserializing the notification message.

   The data format is shown in Figure 2.

     0                   1                   2                   3

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-------+-------+---------------+-------------------------------+

     | Vers. |  ET   |  Header Len   |      Message Length           |

     +-------+-------+---------------+-------------------------------+

     |                       Message-Generator-ID                    |

     +---------------------------------------------------------------+

     |                       Message ID                              |

     +---------------------------------------------------------------+

     ~                       Options                                 ~

     +---------------------------------------------------------------+

   o  Message-Generator-ID is a 32-bit identifier of the process which

      created the notification message.  This allows disambiguation of

      an information source, such as the identification of different

      line cards sending the notification messages.  The source IP

      address of the UDP datagrams SHOULD NOT be interpreted as the

      identifier for the host that originated the UDP-Notif message.

      Indeed, the streamer sending the UDP-Notif message could be a

      relay for the actual source of data carried within UDP-Notif

      messages.

As for updating draft-unyte-netconf-udp-notif. I suggest that we update section 2 with the term "Generator" or I would prefer we re-use " Observation Domain" and explain its meaning. We insert a new section between 2 and 3, and describe reasons why the export process of the network processor on the line card needs to be exposed to the receiver.

Does that make sense to you Andy and Mahesh? Thoughts about the term "Generator" or " Observation Domain"?

Regarding augmenting ietf-hardware.yang. You are referring to RFC 8348 section 7 and 7.2 Correct?

https://tools.ietf.org/html/rfc8348#section-7<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8348%23section-7&data=02%7C01%7CThomas.Graf%40swisscom.com%7C50d6123d5c9f43799de908d862c0205f%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637367924602806953&sdata=OiX42eHe%2BhPZTvWTTnd%2Fsu6gIB2ZzAI4gQa9sVRK2%2FA%3D&reserved=0>
https://tools.ietf.org/html/rfc8348#section-7.2<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8348%23section-7.2&data=02%7C01%7CThomas.Graf%40swisscom.com%7C50d6123d5c9f43799de908d862c0205f%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637367924602806953&sdata=kuD7ST7i%2Bf5T7qNCSDjY9QRaQFiN5D8wNRUO1F%2FksDg%3D&reserved=0>

In section 7.1. and 7.2 I miss "network processor" and "line card", but "fabric" (to represent distributed forwarding systems) seems to present. Sine Andy is one of the authors of RFC8348, could you give guidance how "network processor" and "line card" would be augmented, if this should be part of draft-unyte-netconf-distributed-notif or a new draft, and what the reason for such an augmentation would be in context to above description.

>From my perspective, and please correct me if mistaken, one of the benefit is that the loss could not only be matched to the network processor on a line card, but also additional operational metrics could be retrieved from this network processor since the exact xpath would be known. IPFIX did not have such a modeling. Here we would have this benefit and could go one step further.

Best Wishes
Thomas

From: netconf <[email-masked]> On Behalf Of Mahesh Jethanandani
Sent: Wednesday, September 23, 2020 4:44 PM
To: Tianran Zhou <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif

Hi Tianran,

[As a contributor]

Hi Tianran,

See inline with [mj].

Thanks Andy for your opinion. And thank Kent for your expansion and further question.
The goal is to allow the client to know if it has received all the data pieces. Furthermore, the client know which publisher failed to send data. Then it depend on the client to do the action, e.g., ignore, require the data one more, ...
We just use the generator-id to indicate the publisher, as we find it in ietf-netconf-notification-messages, and it's very convenient for this usage.

One use case is exactly as Kent mentioned "Answering myself here, perhaps it enables two servers on the same IP address to send to the same receiver, as then the receiver doesn't solely rely on source-IP address (assuming unauthenticated push) to designate the publisher".
It's also OK for us to use another indicator if the generator-id is not feasible.

Thanks.

"what seems to be missing is an ability for the client to determine which generator-id is used by which publisher (e.g., line card). "
If necessary, maybe we can extend this mapping in some initial exchanges. To be clear, how do you want to name the publisher?

Thanks,
Tianran

Good point. If I understand you correctly, what seems to be missing is an ability for the client to determine which generator-id is used by which publisher (e.g., line card).  The solution enables the client to partition notifications coming from different publishers, but that is it.  What value does this have to the client, I don't know.

Answering myself here, perhaps it enables two servers on the same IP address to send to the same receiver, as then the receiver doesn't solely rely on source-IP address (assuming unauthenticated push) to designate the publisher?

K.

_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=02%7C01%7CThomas.Graf%40swisscom.com%7C513b3a44b70b42b82daa08d85fcf3821%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637364690889708534&sdata=V1Ma7xzZnEkCqaesjvmbgZXiXOOfCfplzIEnm5t43oU%3D&reserved=0>

Mahesh Jethanandani

Mahesh Jethanandani