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

Mahesh Jethanandani <mjethanandani@gmail.com> Wed, 23 September 2020 14:44 UTC

Return-Path: <mjethanandani@gmail.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CA23A1039 for <netconf@ietfa.amsl.com>; Wed, 23 Sep 2020 07:44:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJwCsoDMKgSM for <netconf@ietfa.amsl.com>; Wed, 23 Sep 2020 07:44:25 -0700 (PDT)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261B93A0E22 for <netconf@ietf.org>; Wed, 23 Sep 2020 07:44:25 -0700 (PDT)
Received: by mail-pl1-x631.google.com with SMTP id y17so1266885plb.6 for <netconf@ietf.org>; Wed, 23 Sep 2020 07:44:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=if/nOdk29S2isdIblEhEflzqMn+4IV6GJnuzwe8qB7k=; b=plXBlYF2RPj+Fds3HoCqz4UkEboBmExlTRLz/xR5HTunvc1OuPODGj9F78zUSqX6un sPzz59EsIfUejVRcN6+AADlUGVIc9oEdyQfQP9QbtFBEC8TWV4tWPDOYNgaaEiXjhikV zqjZOUfDUbh7SGFe4SsLYnmRONPEj4eZOF62CzA6QlMkpZ8SgRvh/d2t9VMxbMu+cDoe uj6Z8otPhPgQSZLZzbyQH8W01etS4wAZBpnt2vgQaJelz+8879Hn1BVooEP+EboQJgao rTgRCbLKILLKmSc3a/X5cOqVirvDFtRx1AxmeUWnLYN8bed8v7kMcYlVV+vkU9bkSv4G bs7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=if/nOdk29S2isdIblEhEflzqMn+4IV6GJnuzwe8qB7k=; b=GnHBPD0ROQt2WbT8yTctu4pKtDu8CyWH5qZ68MEocprpbcBOm3YBVPa3fEZU0M/jSm su1l91xra/PfUukm06Am25K5RTo3/3JJUtLpWA2j3xZLO8o6MKG3SImutpxFrz4fFVb5 6KlfAsXp57NoHfoRv/8M04ToWbEakrOxXNlHpQcp3zlcxsf9H/P1hk8Ako3gBbVWs0oJ b6Sr8w7+xL0bKDodMx/f8Nrz99+NTwVfpLsiLo2na8w24MUM/rYEkKuXBgQ3sQxsVru0 4ZuIfg3L+xdlKnKui2uX1tUNx5oq74rE1oIKCN8JTKM5btwTqb6+1wfdx6e7pTumP2fR z0rA==
X-Gm-Message-State: AOAM533tAaRBiV8BPJswsEMMS2qlhZ3iS/J6Jaod2QQ9LZCe4W4LQcLB Fi38/Z+o+ey7AUTuXpCnkpQjNp5h6LN6ZQ==
X-Google-Smtp-Source: ABdhPJwSaRWKg+ZEvbRVRP0opbxI4yGQzu8ujJB3VY7dRLSWSRzjocyWYEDnY22vklem+O5Ddz0bHw==
X-Received: by 2002:a17:90b:360a:: with SMTP id ml10mr8375197pjb.198.1600872264422; Wed, 23 Sep 2020 07:44:24 -0700 (PDT)
Received: from [172.17.101.162] (66-76-170-6.com.sta.suddenlink.net. [66.76.170.6]) by smtp.gmail.com with ESMTPSA id m12sm5154411pjs.34.2020.09.23.07.44.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Sep 2020 07:44:23 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <52CC888C-2AA1-4ED2-9DD5-9C3994BC9D3E@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8A2AD6BE-D006-4429-B636-32BB58CD7B5C"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Wed, 23 Sep 2020 07:44:22 -0700
In-Reply-To: <444c48abc18e4539acd4229075b5fb77@huawei.com>
Cc: Kent Watsen <kent+ietf@watsen.net>, Andy Bierman <andy@yumaworks.com>, "netconf@ietf.org" <netconf@ietf.org>
To: Tianran Zhou <zhoutianran@huawei.com>
References: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> <CABCOCHTP5boMJpCvhjd=Ur9sTr-+Ea0gSzOJnY_YToHGdurhsA@mail.gmail.com> <e7ccc6495dd34c4fae15a1697ccd1af5@huawei.com> <01000174b2ba9c57-cbc0d353-8d30-4885-8769-1ea869b4d0be-000000@email.amazonses.com> <CABCOCHR9hBn+vYg-Y8qfWd-Vj5qEqcAuGNrq_Xg+fRiiVALkVA@mail.gmail.com> <01000174b2e0a349-52337b7b-81c3-4c56-a58b-36c95d68340f-000000@email.amazonses.com> <5c058aa40cbf4141b32b19bd53514415@huawei.com> <DE9F4ED9-D745-4501-813D-6BB4822C1BD4@gmail.com> <444c48abc18e4539acd4229075b5fb77@huawei.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/8NFNgXeiorayTC9SlUd1sSmvnCg>
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2020 14:44:31 -0000

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 <zhoutianran@huawei.com> wrote:
> 
>  
> [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 <zhoutianran@huawei.com <mailto:zhoutianran@huawei.com>> wrote:
>  
> 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.
>  
> [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?
>  
> 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.
>  
> [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.
>  
> 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.
>  
> 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?
>  
> 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.
> 
> 
> “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:netconf-bounces@ietf.org <mailto:netconf-bounces@ietf.org>] On Behalf Of Kent Watsen
> Sent: Tuesday, September 22, 2020 6:55 AM
> To: Andy Bierman <andy@yumaworks.com <mailto:andy@yumaworks.com>>
> Cc: netconf@ietf.org <mailto:netconf@ietf.org>
> Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif
>  
> [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,
> a client cannot expect any sort of consistent implementation of this field.
>  
> 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.
>  
>  
> _______________________________________________
> netconf mailing list
> netconf@ietf.org <mailto:netconf@ietf.org>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>  
> Mahesh Jethanandani
> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>  
>  
>  
> 
>  

Mahesh Jethanandani
mjethanandani@gmail.com