Re: [OPSAWG] AD review of draft-ietf-opsawg-sap-09

mohamed.boucadair@orange.com Mon, 12 December 2022 12:52 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAF8C14CE47; Mon, 12 Dec 2022 04:52:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJS75hgsfvYN; Mon, 12 Dec 2022 04:52:49 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B256BC14F740; Mon, 12 Dec 2022 04:52:45 -0800 (PST)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr22.francetelecom.fr (ESMTP service) with ESMTPS id 4NW1kM66LQzycn; Mon, 12 Dec 2022 13:52:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1670849563; bh=DkTBkNObOJdTJCZ4TPBvNY1/JSR2OqPV32PMJjuKgr8=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=GbfJy0U7Qo8bxy2D444R5+qWYKzO46lvWzIYd86EMWLBSPYHHtV9AHcW8xeG7LOOV CQIwv94NyZrnQjdG2CPkDw+z3sdKsJCYHknjOn3b6x1zskhvRykWIivXE1hQ8hR16b +VnXpBdx38aB8snKLnScC4onRgY+OeozVeUhoCuMDaxC8PutEvOvNHj1kCtMedj9Hw aVpg4bjijiHCYeB/slXs2Ez0Re90gGlxSKOJS48XWbLdBFuvZKelxoyB2cKWriERIE rvLB17HQC9kyQKvs+xNeJnA/vJB6iGyxrtqJCTa9p+zQLKjp96nOzYAtASRob4mxtS KWkiw8QZDG5Og==
From: mohamed.boucadair@orange.com
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
CC: "draft-ietf-opsawg-sap.all@ietf.org" <draft-ietf-opsawg-sap.all@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: AD review of draft-ietf-opsawg-sap-09
Thread-Index: AdjPQx6o5IkGa/MiRbSgFOql4kxVLAAATHXwAS1rwBAABRW0gAAFIiHwB6xNwiAGQBFXsACUgjGw
Content-Class:
Date: Mon, 12 Dec 2022 12:52:43 +0000
Message-ID: <15240_1670849563_6397241B_15240_317_19_a0b764466e5141689ec95d8c53eedcdf@orange.com>
References: <BY5PR11MB41965219142B5D7477437604B5519@BY5PR11MB4196.namprd11.prod.outlook.com> <10618_1663938212_632DAEA4_10618_131_22_be9e97dad413420db9ac52ea0c8b38f0@orange.com> <BY5PR11MB4196EE66FFC3E63DE28AABA7B5579@BY5PR11MB4196.namprd11.prod.outlook.com> <11971_1664461105_6335A931_11971_276_1_ff1bd715600144a4831e519922785bbe@orange.com> <BY5PR11MB4196A321341B8076C67590BEB53D9@BY5PR11MB4196.namprd11.prod.outlook.com> <9635_1668006642_636BC2F2_9635_247_13_7e4598d105a54d1c90d7f96a01510be8@orange.com> <BY5PR11MB41966D73AF207BB2B5888349B51C9@BY5PR11MB4196.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB41966D73AF207BB2B5888349B51C9@BY5PR11MB4196.namprd11.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-12-12T12:36:49Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=b2151b8e-6e41-4974-9308-3b2ebd7dda53; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.115.27.53]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/OALbQz0IQ-eIb5PBuHkiQTMhFrM>
Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-sap-09
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2022 12:52:53 -0000

Hi Rob, 

Thanks for the follow-up. 

After rereading the initial proposed updated text, I think that you have a valid point about the need for more clarity when describing the relationship between the various status data nodes. I released -11 with an attempt to make that better. Both the data nodes description and the examples are updated to reflect the intent. The relationship (including what should be considered as anomalies) are also described. 

The new text also clarifies that the per-SAP service status should not be confused with the global service status (which may involved more than one SAP). Adrian's comment that a SAP failure does not imply a service failure is true for that global service status, not for the (per-SAP) service status included in the SAP.

The new text is available at: 

URL:            https://www.ietf.org/archive/id/draft-ietf-opsawg-sap-11.txt
Diff:           https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-sap-11

Hope this is better. Thanks. 

Cheers,
Med

> -----Message d'origine-----
> De : Rob Wilton (rwilton) <rwilton@cisco.com>
> Envoyé : vendredi 9 décembre 2022 15:22
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>;
> draft-ietf-opsawg-sap.all@ietf.org; opsawg@ietf.org
> Objet : RE: AD review of draft-ietf-opsawg-sap-09
> 
> Hi Med,
> 
> Sorry, still not clear (in my head) on the exact differentiation
> between sap-status and service-status.
> 
> Also, a few other nits that I spotted:
> s/is capable to host/is capable of hosting/ (two places) s/ that
> uniquely identifies SAP/ that uniquely identifies a SAP/ s/ are
> tagged as ready to host/ are tagged as being capable of hosting/
> 
> Please see inline ...
> 
> > -----Original Message-----
> > From: mohamed.boucadair@orange.com
> > <mohamed.boucadair@orange.com>
> > Sent: 09 November 2022 15:11
> > To: Rob Wilton (rwilton) <rwilton@cisco.com>; draft-ietf-opsawg-
> > sap.all@ietf.org; opsawg@ietf.org
> > Subject: RE: AD review of draft-ietf-opsawg-sap-09
> >
> > > > >
> > > > > But how do you distinguish between a SAP that hasn't been
> > > > > provisioned yet to a service vs a SAP that has been
> provisioned
> > > > > but the service is down?  E.g., trying to find a free SAP
> just
> > > > > by looking for a SAP with a service-status of op-down
> doesn't
> > > > > appear to be sufficient on its own.
> > > >
> > > > [Med] A SAP that is not provisioned yet will have a
> > > > sap-status=down,
> > > while
> > > > the one that is provision but the service is not activated
> will
> > > > have
> > > sap-
> > > > status=up and service-status=down. Isn't that sufficient?
> > >
> > > I would have assumed:
> > >  - If sap-status is down then the service-status must also be
> down,
> > > right?
> >
> > [Med] Actually, no. The service status indicates whether a
> service is
> > associated with the SAP. Added both the admin and op status of
> the
> > service status and added this NEW text:
> >
> > "This data node indicates whether a service is bound to this SAP
> and,
> > as such, it is not influenced by the value of the 'sap-status'."
> [Rob Wilton (rwilton)]
> 
> " 'service-status':  Reports the status of the service for a given
> SAP. ...".  This states that it is reporting the status of the
> service for a given SAP.
> 
> For the service-status/admin-status I can see how the service can
> be admin-up for a SAP that is down (e.g., perhaps there is a
> broken fiber such that the physical interface or sub-interface is
> down).  But I would still find it confusing to say that the
> service at the SAP is operationally up on a SAP that is down.
> 
> Specifically, if a customer was to ask whether there are able to
> get service at a particular SAP, is it sufficient for the operator
> to check service-status/oper-status on the SAP, or must they check
> both service-status/oper-status and service-status/sap-status to
> know whether or not they will be receiving service at a particular
> SAP?
> 
> If the draft description, and perhaps even more critically, the
> YANG model description, can be really clear on this, I think that
> will help implementors and users.
> 
> Regards,
> Rob


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.