Re: [TICTOC] draft-ietf-tictoc-1588v2-yang and RFC7223

Rodney Cummings <rodney.cummings@ni.com> Fri, 17 March 2017 12:28 UTC

Return-Path: <rodney.cummings@ni.com>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5164B12932A for <tictoc@ietfa.amsl.com>; Fri, 17 Mar 2017 05:28:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level:
X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nio365.onmicrosoft.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 F2pQhpz2toZ3 for <tictoc@ietfa.amsl.com>; Fri, 17 Mar 2017 05:28:23 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0109.outbound.protection.outlook.com [104.47.33.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283371292AE for <tictoc@ietf.org>; Fri, 17 Mar 2017 05:28:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nio365.onmicrosoft.com; s=selector1-ni-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vRKHrgxAW9n2mc9McN8Ogmm/AqiqHWNHcjKg5m9+uR0=; b=LDSF17aPr1i60yJFmPCqHVAUYPOnzov4Lnqp8Ea2/z7QpphDHzlrHS0l92s5ISGcYKoZtCmatO4G2dclPgRXNsXBSVBQ3e3JdOQiU4SiqyW7+DfccgkCzSTkLJFbApyMd0hnNUyiagcUnQyio3PgSOdQubio05d/ahgNeXbLpMo=
Received: from MWHPR04MB0559.namprd04.prod.outlook.com (10.173.49.136) by MWHPR04MB0559.namprd04.prod.outlook.com (10.173.49.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Fri, 17 Mar 2017 12:28:21 +0000
Received: from MWHPR04MB0559.namprd04.prod.outlook.com ([10.173.49.136]) by MWHPR04MB0559.namprd04.prod.outlook.com ([10.173.49.136]) with mapi id 15.01.0947.020; Fri, 17 Mar 2017 12:28:21 +0000
From: Rodney Cummings <rodney.cummings@ni.com>
To: Jiangyuanlong <jiangyuanlong@huawei.com>, "tictoc@ietf.org" <tictoc@ietf.org>
Thread-Topic: draft-ietf-tictoc-1588v2-yang and RFC7223
Thread-Index: AdKc5s0kzPwIdBTIQ8as3pK1nwg9XQCLX4AQAAE6IeA=
Date: Fri, 17 Mar 2017 12:28:20 +0000
Message-ID: <MWHPR04MB0559C149978B87D3FCF5C17092390@MWHPR04MB0559.namprd04.prod.outlook.com>
References: <MWHPR04MB05594F190E0EB3E4083A886A92270@MWHPR04MB0559.namprd04.prod.outlook.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BBAB1D02D@szxema506-mbs.china.huawei.com>
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBAB1D02D@szxema506-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=ni.com;
x-originating-ip: [204.239.253.216]
x-ms-office365-filtering-correlation-id: f46e2c87-10c4-4dde-af98-08d46d311958
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR04MB0559;
x-microsoft-exchange-diagnostics: 1; MWHPR04MB0559; 7:xVZujn488qAG0230ECmQ/nNgTeGSGT3XWYYiPNtsO9RYrV00YixKp6aES/L6cFaV67kg7iNHEpEGZ9LmirnKjg85SN/yQDi9BjIac7afLI8AWorFq1//HJSKTcSud/9tYDECljUnneFg86sw39JeHSzbQ4DoC5TppUpjxjjaXKHSNErenIN+kwza2m3REquCeRjmzP/NwzXH7DWmPbe/HYM+luKtK40uI3qnTdbTmoTWPjOYjSXxWM0LzrUnHsJAT8qp8c/MYjZOFLC19yVGIQ+Ro+ha40MI+ixl3/x65rFD9BvWtAaSGEhOUUyIU7avz/3NrWHHIetmjfUXnw0SwA==
x-microsoft-antispam-prvs: <MWHPR04MB055937E056EC2C752E4BCC1A92390@MWHPR04MB0559.namprd04.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(50582790962513)(100405760836317)(1591387915157);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123558025)(20161123560025)(20161123555025)(6072148); SRVR:MWHPR04MB0559; BCL:0; PCL:0; RULEID:; SRVR:MWHPR04MB0559;
x-forefront-prvs: 0249EFCB0B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(377454003)(53754006)(13464003)(54094003)(45984002)(6436002)(230783001)(102836003)(229853002)(6246003)(7696004)(50986999)(8676002)(966004)(4326008)(53546008)(81166006)(53936002)(38730400002)(122556002)(189998001)(2906002)(8936002)(2900100001)(6116002)(33656002)(76176999)(54356999)(1720100001)(25786008)(55016002)(66066001)(6506006)(5660300001)(2950100002)(74316002)(7736002)(3280700002)(77096006)(2501003)(9686003)(3846002)(99286003)(86362001)(3660700001)(305945005)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR04MB0559; H:MWHPR04MB0559.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-7"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ni.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2017 12:28:20.8266 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 87ba1f9a-44cd-43a6-b008-6fdb45a5204e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR04MB0559
Archived-At: <https://mailarchive.ietf.org/arch/msg/tictoc/byFxQ3ale7yoy09tw8XxBElxoa0>
Subject: Re: [TICTOC] draft-ietf-tictoc-1588v2-yang and RFC7223
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Mar 2017 12:28:26 -0000

Thanks Yuanlong,

When we discussed it this week, people in 802.1 seemed to agree with Option 2 as well, but then again... they are PHY/switch vendors and not really YANG experts.

I think Marina assumed Option 1 because that is what the 802.1 "bridge-port" YANG does. But... I think Option 1 makes sense there, because the "bridge-port" represents the MAC layer of the physical port.

The IANA interface types do have PON and OTN:
	https://www.iana.org/assignments/iana-if-type-yang/iana-if-type-yang
but I think the point is that those are intended to be hardware. A 1588 port seems more like a logical software concept.

I wonder if maybe we should post a link to this TICTOC question to the NETMOD mailing list?

I assume the authors of RFC7223 participate in NETMOD but probably not TICTOC.

Rodney

> -----Original Message-----
> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]
> Sent: Friday, March 17, 2017 7:09 AM
> To: Rodney Cummings ; tictoc@ietf.org
> Cc: liuxian (C)
> Subject: RE: draft-ietf-tictoc-1588v2-yang and RFC7223
> 
> Hi Rodney,
> 
> Thank you very much for bringing up the head-up situation in the IEEE.
> I wonder whether RFC7223 interface solely specifies Ethernet interfaces
> (the examples in this RFC seems give a positive answer).
> People may also want to support OTN, PON and other physical ports (as I am
> aware, IEEE 1588 PTP is supported by these physical layers now).
> Therefore, I prefer to your Option 2 and would like to reference to an
> RFC7223 interface just as an example.
> In this way, other interfaces may also be introduced quite easily.
> 
> Cheers,
> Yuanlong
> 
> -----Original Message-----
> From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Rodney Cummings
> Sent: Thursday, March 16, 2017 6:16 AM
> To: tictoc@ietf.org
> Subject: [TICTOC] draft-ietf-tictoc-1588v2-yang and RFC7223
> 
> Hello all,
> 
> Some questions have come up in recent meetings of IEEE 1588 and IEEE 802.1
> working groups that are relevant to the TICTOC project draft-ietf-tictoc-
> 1588v2-yang. I would like to get some feedback from TICTOC to help
> determine if a change is needed for draft-ietf-tictoc-1588v2-yang.
> 
> 1588-2008 has the concept of a "port", and for a 1588 product with two or
> more ports, 1588 specifies the transfer of time between these ports. The
> 1588-2008 specifications for the port are "logical", in that they are
> independent of any specific transport or media. For example, the 1588 port
> can use a layer-2 802 mapping, or the port can use a UDP mapping.
> 
> When a 1588-2008 product is managed (such as with YANG), the management
> client is likely to ask:
> 	How do I find the "real" port that a 1588 "logical" port is using?
> For example, if the UDP mapping is used, I might want to find relevant IP
> addresses, and then go down in the data models to find relevant MAC
> addresses, 802.3 link speeds, and so on.
> 
> The current consensus in the 1588 working group is that although this
> question is important, since 1588 is transport-independent, the answer
> cannot be fully specified in the 1588 data sets (i.e. information model).
> The actual management data model (e.g. YANG, MIB, 1588 management
> protocol) potentially has better connections to the "real" port, and
> therefore 1588 defers this topic to each management data model. In other
> words, the 1588 standard itself will not fully answer this question, but
> the YANG (i.e. draft-ietf-tictoc-1588v2-yang) is expected to answer the
> question to the best of its ability.
> 
> This question came up in a recent discussion in IEEE 802.1, relative to
> their profile of 1588, 802.1AS. Refer to slide 5 of:
> 	http://www.ieee802.org/1/files/public/docs2017/as-gutierrez-yang-
> 0317-v01.pdf
> This presentation suggests that the 1588 port (called a "TAS port" in
> 802.1AS) should be done as an augment of the RFC7223 interface.
> 
> The current consensus in IEEE 802.1 is that their profile 802.1AS will
> defer to the 1588 YANG module (draft-ietf-tictoc-1588v2-yang) for this
> decision. The YANG module for 802.1AS will augment the 1588 YANG module as
> described at the end of section 1 of draft-ietf-tictoc-1588v2-yang.
> 
> So... I think we need to select from one of three options for draft-ietf-
> tictoc-1588v2-yang:
> 
> Option 1: 1588 port augments RFC7223 interface
> --
> 
> Although this is a reasonable suggestion, it works under the assumption
> that a 1588 port "is a type of" RFC7223 interface. That implies that the
> 1588 port has a place in the interface stack represented by higher-layer-
> if and lower-layer-if.
> 
> I would argue that a 1588 port "uses" an RFC7223 interface, and the 1588
> port does not belong in the interface stack. 1588 is a higher-layer
> protocol, and in that respect, it is more analogous to protocols like TCP
> and UDP, and not the protocols listed in iana-if-type.yang.
> 
> If we decide to implement this option, we need to do it in the first 1588
> YANG (draft-ietf-tictoc-1588v2-yang). I assume that we cannot change the
> 1588 port from non-augment to augment in a future revision of the 1588
> YANG.
> 
> Option 2: 1588 port contains a reference to an RFC7223 interface
> --
> 
> 1588 requires a configured interface for each 1588 port. By using
> interface-ref instead of an interface augment, this establishes the
> relationship as "uses".
> 
> This would be added to draft-ietf-tictoc-1588v2-yang as a new leaf in
> grouping port-ds-entry, such as:
> 	leaf interface-reference {
> 		type if:interface-ref;
> 		description
> 			"Reference to the configured interface that is used by
> 			this PTP Port (see RFC 7223).";
>        }
> This enables the management client to find the interface that the 1588
> (PTP) port is using. The management client can also traverse up/down the
> interface stack to find additional information.
> 
> Option 3: Do nothing in draft-ietf-tictoc-1588v2-yang
> --
> 
> This is what we have so far.
> 
> Presumably a future revision of the 1588 YANG could decide to implement
> option 2, but not option 1.
> 
> Question: Which option should we use for draft-ietf-tictoc-1588v2-yang?
> --
> 
> I recommend option 2.
> 
> Previously I was fine with option 3, but since this is an open question in
> the 1588 community, it is best to resolve it in the first 1588 YANG
> module.
> 
> At a minimum, we need to decide if we are doing option 1, because that
> decision cannot be changed in future 1588 YANG module revisions.
> 
> This decision is not related to the 1588 data set specifications (2008 or
> future), because current 1588 consensus is that it is entirely within the
> scope of the 1588 YANG module.
> 
> Thanks everyone,
> Rodney Cummings
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc