I apologize for the email below - replied to the wrong one, please, disregard.
Igor From: netmod [mailto:[email protected]] On Behalf Of Igor Bryskin Sent: Wednesday, June 14, 2017 9:13 AM To: [email protected]; [email protected] Cc: [email protected] Subject: Re: [netmod] Question on intefaces-state model Hi Franchesco, To your point 1: I was describing a very common use case when a client owns/ controls OTN TTPs, while the multi domain network provides connectivity betweeb access links across the network. In this cae network only deals with transit segments (neither head nor tail) To your point 2 There is only one thing aboutb OTN transit segments that is OTN specific - bandwidth. Because the configuration of a transit OTN segment needs to include the exact ODUk container (to match the container on the opposite side of the incoming access/interdomain link) - said ODUk container is expected to be encoded as a generic label subobject that follows the network side access/interdomain link subobject - this alone tells the network controller everything it needs to know about the required bandwidth. In short, for this use case you dont need OTN augmentation to support client -network interface - base /generic TE tunnel model works just fine, I do agree that every use case that requires provisioning by network OTN TTPs does require the OTN augmentation. Igor From:Ladislav Lhotka To:Alex Campbell, Cc:[email protected], Date:2017-06-14 04:28:51 Subject:Re: [netmod] Question on intefaces-state model > On 14 Jun 2017, at 00:35, Alex Campbell <[email protected]> wrote: > > > Presumably a device is free to not implement an optional config=false node if > that node would never be returned in a response anyway - as this will make no > externally visible difference. That's my view, too. However, this reasoning works if the parent container is being retrieved but it is not very clear what is supposed to happen if the client asks explicly for that optional parameter. This looks like a gap in the architecture - most of the time, YANG pretends to be something like a schema language in that it describes constraints on a valid data tree but conformance issues like what parameters a server needs to implement are something different. > > However, if the model states or implies that the node is present under > certain conditions (for example, the node is always present for Ethernet > ports), and the device can meet those conditions (i.e. it has an Ethernet > port), then the device must implement the node or it does not conform to the > model. Right, this could be written in a description, but I've been assuming it is not the case. Lada > > > > Alex > > From: netmod <[email protected]> on behalf of Andy Bierman > <[email protected]> > Sent: Wednesday, 14 June 2017 7:30 a.m. > To: Ladislav Lhotka > Cc: [email protected] > Subject: Re: [netmod] Question on intefaces-state model > > > On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka <[email protected]> wrote: > Andy Bierman <[email protected]> writes: > > > On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder < > > [email protected]> wrote: > > > >> On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (Nokia - > >> BE/Antwerp) wrote: > >> > > >> > We have a question regarding the statistics container as defined in the > >> > interfaces-state model. This container defines one mandatory leaf > >> > (discontinuity-time) while all other leafs are optional. What is the > >> > rationale behind this leaf being mandatory and not an optional field? > >> > > >> > It does not make a lot of sense to return a discontinuity-time value and > >> no > >> > counters if none of the counters are relevant for a specific interface. > >> > > >> > Another alternative could be to add, via a deviation, a when clause to > >> the > >> > container indicating for which ifType(s) the container is (or is not) > >> > present. But that would lead to not supporting the IETF interfaces model > >> to > >> > the full extent. > >> > > >> > >> The discontinuity-time is relevant for _any_ counter associated with > >> an interface, regardless whether the counter is defined in the > >> interfaces model or elsewhere. I have a hard time to imagine an > >> interface that has zero counters. > >> > >> > > The mandatory-stmt is very confusing for config=false nodes. Mandatory=true > > means > > an <rpc-reply> must contain an instance of the mandatory leaf. > > I don't think it is that confusing. RFC 7950 defines what a valid data > tree means and "mandatory" are among the constraints. > > I agree though that in terms of a management protocol it means different > things for config true and false data, but this is true also for default > values and maybe other YANG concepts as well. > > > > > Mandatory=false does not mean optional-to-implement although it sure > > looks that way for config=false nodes. Only if-feature can make a node > > optional to implement. > > I don't think this interpretation is supported by any text in the YANG > spec. State data nodes that are optional needn't be implemented. > > > RFC 7950, sec 5.6 (Conformance) does not support your interpretation. > It defines basic behavior, optional (via features), and deviations as the > only mechanisms affecting conformance. > > > Lada > > > > > > Andy > > > > > > > /js > > > > > > Andy > > > > -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > >> > >> _______________________________________________ > >> netmod mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
