Dear Rodney, Thank a lot for the clarification. It is not clear to me how clock-identity is modeled indeed (I changed the message title to reflect it). Currently, clock-identity is a member attribute in quite a few containers, such as default-ds, parent-ds. parent-port-identity, port-ds-list[]. port-identity, transparent-clock-default-ds, and transparent-clock-port-ds-list[].port-identity, but instance-list[] does not have clock-identity as its member. Are you suggesting to move clock-identity from default-ds into instance-list[]? How do we model clock-identity in the transparent-clock-port-ds-list[], remove it too?
Regards, Yuanlong -----Original Message----- From: Rodney Cummings [mailto:[email protected]] Sent: Monday, October 09, 2017 11:39 PM To: Jiangyuanlong; Opher Ronen; [email protected] Cc: Zongning; Liushucheng (Will Liu); Zhuhengjun Subject: RE: Re: [TICTOC] [netmod] draft-ietf-tictoc-1588v2-yang-05: port-number Hi Yuanlong, To be clear my proposal is: - Model port-number directly in port-list as the key. - Do not model clock-identity in port-list. - Do not model port-identity in port-list. - In the description of port-number, mention that port-identity is not explicitly modeled in YANG, but implicitly through the use of port-list[]/port-number and instance-list[]/clock-identity. See my previous email for proposed text. Rodney > -----Original Message----- > From: Jiangyuanlong [mailto:[email protected]] > Sent: Monday, October 9, 2017 6:47 AM > To: Opher Ronen ; Rodney Cummings ; [email protected] > Cc: Zongning ; Liushucheng (Will Liu) ; Zhuhengjun > Subject: RE: Re: [TICTOC] [netmod] draft-ietf-tictoc-1588v2-yang-05: > port- number > > Hi Opher and all, > > Thanks much for all the comments. So the consensus seems to me is - we > agreed to model both port-number and clock-identity in the port-ds-list. > This will reflected in our next revision of draft-ietf-tictoc-1588v2-yang. > Definitely, later versions can take another approach with version > control capability of YANG. > > Cheers, > Yuanlong > > -----Original Message----- > From: TICTOC [mailto:[email protected]] On Behalf Of Opher Ronen > Sent: Wednesday, October 04, 2017 2:40 AM > To: Rodney Cummings; [email protected] > Subject: Re: [TICTOC] [netmod] draft-ietf-tictoc-1588v2-yang-05: port- > number > > Thanks Rodney, > > If I understand your latest suggestion correctly it appears a good > choice for this initial yang model, taking a "less-is-more" approach. > > Someone interested in knowing e.g. all portId's currently configured > can append the port-number values from the port-ds-list to the clockID > from the instance level. > > I assume if more structured to "get" portID is deemed an important > feature it can be added in a later version of the data-model. > > Opher > > -----Original Message----- > From: Rodney Cummings [mailto:[email protected]] > Sent: Tuesday, October 3, 2017 9:28 PM > To: Opher Ronen <[email protected]>; [email protected] > Subject: RE: Re: [TICTOC] [netmod] draft-ietf-tictoc-1588v2-yang-05: > port- number > > As the kids say... "lol". > > Our emails crossed paths. > > The proposal I just sent reflects Opher's view (I hope), as well as > others. > > Opher: My latest proposal removes the duplicate clockIdentity entirely. > > From: TICTOC [mailto:[email protected]] On Behalf Of Opher Ronen > Sent: Tuesday, October 3, 2017 12:57 PM > To: [email protected] > Subject: Re: [TICTOC] [netmod] draft-ietf-tictoc-1588v2-yang-05: port- > number > > Hi Rodney & all, > I am somewhat belatedly posting a post to this thread following an > offline correspondence with Rodney in context of this subject. I hope > my feedback is not too late to be constructive, and will be posted > correctly as this is my first post to this thread. > I will also apologize in advance that I will be mostly offline till > mid-October, so will likely be able to reply to responses only then. > Rodney shared with me the consideration on this aspect, and I > believe his recent post attempt to integrate my offline on this topic. > I hope some more detailed feedback will hopefully assist this draft > advance in a manner aligned with my perception on this aspect from my > involvement in the P1588 WG in general and it's Management SC in specific. > I will first comment that following my correspondence with Rodney > that I believe (with reservation given my low involvement in direct > implementation of management interfaces) that an interface that would > enable performing a get to obtain an overall structure including the > information comprimsing a PTP portIdentity appears nice to have. I > would assume that this information will not be the most frequent > aspect a management system would query, but easing obtaining it if > overhead is reasonable may be worthwhile. > A possibly more significant comment is to stress that the > clockIdentity portion of the portIdentity attribute is equal in all > port within a PTP Instance, and equal to the clockIdentity attribute > with the clock data set. This is explicitly stressed by a new sentence > added to the next revision draft, intended to clarify this to the > reader: "The clockIdentity portion of a portIdentity is equal to the > clockIdentity of the PTP Instance that the PTP Port is included in, > and is therefore equal among all PTP Ports inside the PTP Instance." > In my view regardless of the option followed for the data model for > portIdentity, the ability to directly configure the clockIdentity > portion of it should be prevented to avoid generating a configuration > violating the above status (possible hampering the operation of the > PTP protocol if later used as data for portIdentity on the wire). > If I understood correct yang data model enable to provide a leafref > pointer to the clockIdentity from the instance data set level, > possibly best reflecting the actual limitations regarding the > portIdentity structure. > > Best Regards, > Opher Ronen > > Rodney Cummings <mailto:[email protected]> wrote: > > Hi folks, > > > > One of the last topics that we need to resolve for WG Last Call of > > draft-ietf-tictoc-1588v2-yang-05 is the representation of > > port-number, which serves as the key to the list of 1588 port data sets > > (i.e. > > port-list). I've had some offline discussion with IEEE 1588 WG > > members, and I'm copying NETMOD members for YANG expertise. > > > > I think we can narrow the possible options to two, so I'm starting a > > new thread to focus on those. > > > > IEEE Std 1588-2008 is the time sync standard that specifies the > >information model on which draft-ietf-tictoc-1588v2-yang-05 is based. > >In IEEE Std 1588-2008, subclause 5.3.5 specifies the following data > >type to identify each logical port in the 1588 product: > > struct PortIdentity { > > ClockIdentity clockIdentity; > > Uinteger16 portNumber; > > }; > > IEEE Std 1588-2008 uses this data type as the "portIdentity" of the > >port in its on-the-wire protocol, state machines, and so on. In other > >words, in the 1588 standard itself, portIdentity is a "real thing" > > with real implementation. > > > > IEEE Std 1588-2008 also specifies a list of logical ports in each > > "clock", and portIdentity.portNumber is used as the key to that list > > of ports. > > > > In the YANG of draft-ietf-tictoc-1588v2-yang-05, we use YANG-style > > names (e.g. port-list, port-number), but otherwise we've tried to > > keep consistent to the IEEE Std 1588-2008 information model. > > > > We have a challenge with port-number. If YANG represents > > port-identity as a container within port-list, YANG does not allow a > > key to be a leaf within a container, so we cannot use > > port-identity/port-number as the key to port-list. > > > > It seems that we have two options: > > > > Option 1: Use a leafref > > --- > > > > YANG summary: > > > > list port-ds-list { > > key "port-number"; > > leaf port-number { > > type uint16; > > } > > container port-identity { > > leaf clock-identity { > > type clock-identity-type; > > config false; > > } > > leaf port-number { > > type leafref{ > > path "../../port-number"; > > } > > config false; > > } > > } > > } > > > > This has disadvantages from the YANG perspective, in that > > port-number is duplicated. The "config false" is intended to > > mitigate YANG implementation challenges, such that only one value of > > port-number is provided for configuration. > > > > Option 2: Use a grouping > > --- > > > > YANG summary: > > > > grouping port-identity-grouping { > > leaf clock-identity { > > type clock-identity-type; > > } > > leaf port-number { > > type uint16; > > } > > } > > list port-ds-list { > > key "port-number"; > > uses port-identity-grouping; > > } > > > > This has disadvantages from the 1588 perspective, in that it is not > > possible for a 1588-aware management client to "get" portIdentity. > > We are removing a 1588 "real thing" from the data model in order to > > accommodate a syntax limitation of YANG. > > I think that in general when you go from an information model to a > concrete data model, you need to adapt to the data modelling language > you are using, and this will in most cases mean that there will be > some differences; in some cases the data model structure is different, > and in some cases the data model will result in a more detailed model. > How keys are specified is one such example. If you were to use SMIv2, > you'd have to change the names (so that they are unique), and you'd > have to map the structures to conceptual tables. > > Clients need to understand the data model in use (not just the > information model behid it). > > > Question for NETMOD experts > > --- > > > > My personal preference is Option 1 (leafref). Nevertheless, if the > > "config false" does not provide sufficient mitigation for today's > > YANG implementations, we can go with Option 2. > > I don't think any implementation would have any problem supporting > option 1, but it does look a bit odd. Also, it only "helps" if the > client is getting the data using <get>, but it will not help if it is > using <get- > config>. > > > I think that the cleanest solution is to not try to completely mimic > the structure from the information model, but make sure that the text > in the description statements make it clear that the data model looks > different compared to the information model, in order to help the readers. > > > > /martin > > > > > > > Feedback is very much appreciated. > > > > Thanks folks, > > Rodney Cummings > > Co-author draft-ietf-tictoc-1588v2-yang-05 > > > > _______________________________________________ > > netmod mailing list > > mailto:[email protected] > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma > > il > > man_listinfo_netmod&d=DwMFAg&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPel > > cS > > jixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=Tvq4PvUNekeS1IF > > 42 > > ycx_7KyiF9Ag9bUucZE51SFvCw&s=BahOyOIDKpAWICQOgrlu0aga7dBde8X07-oq2il > > ON > > kw&e= > > > > References: > . https://urldefense.proofpoint.com/v2/url?u=https- > 3A__mailarchive.ietf.org_arch_msg_tictoc_lm1xq37jffkSMms2XJll3N- > 2DydC0&d=DwMFAg&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf > 2o7D > w7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=Tvq4PvUNekeS1IF42ycx_7KyiF9Ag9bUuc > ZE51 SFvCw&s=8SBqP6TRNUiieCBN4IZ6qzNQ5ZEW8pCBAm1kAULa-Mg&e= > Rodney Cummings <mailto:[email protected]> > > _______________________________________________ > TICTOC mailing list > [email protected] > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mailman_listinfo_tictoc&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO > 6YCi > E2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m= > 3vIq > KhIleK3ifzu2gqWugIUX62HPLM5VReDafflfyVY&s=jy6sTQ1a- > mKqq1ymmNMj7g1kzyAcFvPE9emfALot4FE&e= _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
