My apologies Yuanlong, I meant to use instance-list[]/default-ds/clock-identity. According to the 1588 standards, the value there is the same as the value in 1588's "portDS.portIdentity.clockIdentity".
The value of clock-identity in other locations is different. Rodney > -----Original Message----- > From: Jiangyuanlong [mailto:[email protected]] > Sent: Monday, October 9, 2017 8:55 PM > To: Rodney Cummings ; Opher Ronen ; [email protected] > Cc: Zongning ; Liushucheng (Will Liu) ; Zhuhengjun > Subject: draft-ietf-tictoc-1588v2-yang-05: clock-identity > > 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
