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

Thomas.Graf@swisscom.com Sun, 27 September 2020 16:56 UTC

Return-Path: <Thomas.Graf@swisscom.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 8A7BE3A1031 for <netconf@ietfa.amsl.com>; Sun, 27 Sep 2020 09:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.274, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 RjIz2AEXubcW for <netconf@ietfa.amsl.com>; Sun, 27 Sep 2020 09:56:36 -0700 (PDT)
Received: from mail.swisscom.com (mailout120.swisscom.com [138.188.166.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CB4D3A0A73 for <netconf@ietf.org>; Sun, 27 Sep 2020 09:56:35 -0700 (PDT)
Received: by mail.swisscom.com; Sun, 27 Sep 2020 18:56:11 +0200
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_351930_1972777100.1601225770818"
X-Mailer: Totemo_TrustMail_(Notification)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gUH14nmS2iRA1wVYnbSkgoSHUFhLYotD1/nle9YxT+/ODBBmynGZ1elk+FnCDpbP6ETWk5xb/4BnG5VtHAnWwTTDfnunsJYybbURzeKt6U0HfuG2tq1z2ncgLrDyzepVIdAt2LYx3S37vW2NVFi8zRwzsotIlzpDHiZA8nBCKSEPUXvMCGFXP8t57TFIPyWe1ZOk6+ObSg9WSmPlKc5aMK66b4eIjjpDHdu4s6jM3qa7Nz/QztaKBpKte1iNcZtuMYpABWRSn81OLsQEW1u3FjIOVes/KQPEhI8csBbjYNMBqShCTxbxDr4DxFM2gGO/SEdKgIJbdZdmDKyfHrIEWw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7+KyBCPa+3dCTtgm5JHm9gslU35WQCINrTpy4L4XsN0=; b=WNf0yBfB2C1xNCgjVlDJfShQ/hlJeSEbIc+XC6soFKQr7jAEXKQFq2W+lOnAJrd91k2WivhwoEE1znQdE3PkVurJ0g3A3mE/eCFeNXBolYqoJY2M/RXRf4flv5WJYskUk7QmPWrqCSPayk3cNhq2k6KR8KYkiSFA+AbvIB7VD3W73j91CbzHt4X7X9SirS019u8OdVCulowRhMX+ZK/Bu4nRNQuNrDUyolVfA3X4zHEy/d1vIH7gC95S7loBl6Jd1e1MN9gZOAae6QX6uBPfEKgKaRZb1IdFMVUbjDncaapGwAI+8KOY66p5yDO42MWvjk/8/z3fKz11LT60dWEO9w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=swisscom.com; dmarc=pass action=none header.from=swisscom.com; dkim=pass header.d=swisscom.com; arc=none
From: <Thomas.Graf@swisscom.com>
To: <mjethanandani@gmail.com>, <andy@yumaworks.com>
CC: <netconf@ietf.org>, <zhoutianran@huawei.com>
Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif
Thread-Index: AQHWkGRu/yp90Vv9H0i3R7lOe+hPQ6lzrQCAgAAGrgCAADT1AIAA25YAgAEGzICAAIQ+AIAGbQRA
Date: Sun, 27 Sep 2020 16:55:24 +0000
Message-ID: <ZRAP278MB0125BBFC1798596A285C24B689340@ZRAP278MB0125.CHEP278.PROD.OUTLOOK.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> <52CC888C-2AA1-4ED2-9DD5-9C3994BC9D3E@gmail.com>
In-Reply-To: <52CC888C-2AA1-4ED2-9DD5-9C3994BC9D3E@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=True; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Owner=Thomas.Graf@swisscom.com; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2020-09-27T16:55:23.5481657Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 General; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Application=Microsoft Azure Information Protection; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=bee5ee9e-1353-4c34-92c6-5e130a17cc71; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Extended_MSFT_Method=Automatic
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=swisscom.com;
x-originating-ip: [138.188.166.41]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 05c2de96-7408-400b-cbd0-08d86306211d
x-ms-traffictypediagnostic: ZR0P278MB0074:
x-microsoft-antispam-prvs: <ZR0P278MB0074B0F5B9AE5F68B624C69589340@ZR0P278MB0074.CHEP278.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: So81Ar1AUzxQx7FrdVvRFjrAwIJnMT9Gl3Q2iL3onXcpZlekStKdzm9NycFywYQXYcX/sOYj6C7cA03AIj86cb3L6TSv7C8Nd3hU+YpA5YwWGc7VnZc0hvi7alp46B2vkVvJDEWYZbK+ITBpeBDX/Hn+dNibIqd7MbHtn39WzXRatptXwb4UZqASOPB9RoiLDj9HVJnvPsedt/u8xJBwZHbwzFM44RuWOuTKzoyupSXXcY12cHHcqgrSPsSJCfIrshYdPlW7BTHIjPNgwrBLX2I8J8ATFyASLTAfNEng7wUA6xuz2gw7+iQRz3yAHM0zrSPYDGJgPQuMJ84F2FgNyJJK9g0Ma0GXgZJyqxvACdN/qxzdNlmHggimFAmomSOvtXc+PWVTKxv3reBzjyk2KiTbfE5vPSKBIj9hL2aGxgSjlKrMPHUJalF/Ob1SHg4W
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(366004)(39850400004)(396003)(346002)(52536014)(10290500003)(478600001)(110136005)(7696005)(6506007)(166002)(66574015)(83380400001)(33656002)(4326008)(53546011)(8936002)(54906003)(966005)(9686003)(86362001)(316002)(26005)(186003)(55016002)(10300500001)(66446008)(64756008)(66556008)(66476007)(66946007)(76116006)(30864003)(8676002)(2906002)(5660300002)(71200400001)(559001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: wWEbocv5FDr+3oOQXL0K3f+9SvKnnWbXKLtriIID9ilNgLPy8HhLOZ714uTsM3Z08WMNuHrLwIfpJ/rU2oPwAJIp+ESKGv/fDjz8sdaeo48qE7LHIKe+5b6FGCB/dXawbWacbuPkeQnw627voUl/arDc+Jr/r74jeZgfKfUfrOTMtAwsKypf4xZ/UyrBfd9Ia99D1zlpv8YZI/3J4gLpiBE300gj5Amu9v3/+XSLuxwGNPUi/if4HB2cK5ZeW133gAWgOMaUX2WPTq+niSrtXswDIMWBnp8E/nz7yeKGeMf/MGmkdrU8GJz/Ul/jvU4HjxcCm6dkp4C1aJ79sgoRGTMBBZykQy0iQ2vZS0b9KF1ol58RUDXXIykHg0xmx318vsiwRa6YDrAeRs7FQGOX/O0TiBUzXgJXHC3qQzLu1+iQXg4MNYX6XI1Z9e/xkgTzuEC5SE0vm28bz23XYsaWT23F4VkX3ka5GXCUqGTjfloVFtt0Jf2IO0PsjVyqf15lCdnTQurwgH5a+Epsw8gT5lA0pE2EpvVlNa7dKmm9PAsN0tsf5NVnmHmItSet2j3OJsFT94RXZ3id5cPG/aZ9jeYaTHx1tdTS0NsAOwcZJHf4I0KHGB9TJPHaAi+ACFL60V94XqGv9XI8N90jl/CEAg==
x-ms-exchange-transport-forked: True
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 05c2de96-7408-400b-cbd0-08d86306211d
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2020 16:55:24.8932 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 364e5b87-c1c7-420d-9bee-c35d19b557a1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: NEAVk/VmRH4RuH31lLiHPvFSjTbGGJqgd0+oirKbZLHdQsqNmKJCoTsF3Zk8ecky7hFRngsDED/iPLg1+VbUjjSEI7adu1mqw11mIEIGScI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZR0P278MB0074
X-OriginatorOrg: swisscom.com
X-CFilter-Loop: Reflected
X-Trustmail: processed
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/MrzYp8GSTtyevmzycTSDKnvr0fg>
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: Sun, 27 Sep 2020 16:56:41 -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>]mp;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 <netconf-bounces@ietf.org> On Behalf Of Mahesh Jethanandani
Sent: Wednesday, September 23, 2020 4:44 PM
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: netconf@ietf.org
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif

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<mailto: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] 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://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
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>





Mahesh Jethanandani
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>