Re: [TICTOC] 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