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

From: Rodney Cummings <[email-masked]>
Date: Wed, 15 Mar 2017 22:15:57 +0000

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

---

From: Jiangyuanlong <[email-masked]>
Date: Fri, 17 Mar 2017 12:08:36 +0000

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:[email-masked]] On Behalf Of Rodney Cummings
Sent: Thursday, March 16, 2017 6:16 AM
To: [email-masked]
Subject: [TICTOC] draft-ietf-tictoc-1588v2-yang and RFC7223

Hello all,

I recommend option 2.

Thanks everyone,
Rodney Cummings

_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: Rodney Cummings <[email-masked]>
Date: Fri, 17 Mar 2017 12:28:20 +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

> From: Jiangyuanlong [mailto:[email-masked]]
> Sent: Friday, March 17, 2017 7:09 AM
> To: Rodney Cummings ; [email-masked]
> Cc: liuxian (C)
> Subject: RE: draft-ietf-tictoc-1588v2-yang and RFC7223
> 
> Hi Rodney,
> 
> 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).
> 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.
> 
> 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:
> 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.
> 
> 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.
> 
> 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 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.
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
>