Robert Wilton <[email protected]> writes:
> Hi William,
>
> I'm not that familiar with Broadband physical layer standards, but I
> have an interest in figuring out some of the physical layer and
> interface layer relationships in YANG.
>
> There are a couple of things that are not clear to me from your email,
> so I have two questions:
>
> 1) Am I right to presume that the "type" of the port is fixed, and can't
> be changed by the handshake mechanism?
> 2) I don't quite understand your last sentence regarding only one
> interface-level enable/disable leaf. I would have thought that this
> would be a benefit. Please can you elaborate.
>
>
> There is possibly a third way to model this, which is to have an
> augmentation of a choice statement, i.e.:
> 1. Your base model would define a choice statement representing the
> physical-layer 'color'.
> 2. Each physical layer 'color' would be a separate augmentation of the
> choice statement.
Another option might be to come up with a hierarchy of interface types and
then make conditional augments based on the type.
For example, a simple hierarchy could be like this:
multi-color
red
green
Now that YANG 1.1 supports multiple inheritance of identities, this
would be just another interface property axis.
This design is extensible and also allows for fine control of how
individual properties are shared among the "colors".
Lada
>
> Using this design ensures that the model can only ever have a single
> physical-layer at a given time, and yet still makes it clear which
> physical-layer is in use and also allows for different configuration
> nodes for each color.
>
> I've used this structure for modelling layer 2 encapsulation in the IDs
> that I've put forward:
> E.g. see "choice encaps-type" in draft-wilton-netmod-intf-ext-yang-01
> for the base model, and two instances of
>
> 'augment
> "/if:interfaces/if:interface/if-cmn:encapsulation/if-cmn:encaps-type"'
>
> in draft-wilton-netmod-intf-vlan-yang-01 for two example augmentation
> cover a basic VLAN layer 2 encapsulation, and a more flexible layer 2
> encapsulation. Other layer 2 encapsulations could also be defined for
> PPP, cHDLC, FR, ATM, etc in separate drafts.
>
> Perhaps this choice + augmentation design would also work well in your case?
>
> Thanks,
> Rob
>
>
> On 11/11/2015 09:28, William Lupton wrote:
>> All,
>>
>> We would much appreciate comments and suggestions on the question
>> posed below.
>>
>> Thanks,
>> William Lupton
>> (Software Architect, Broadband Forum)
>>
>> ----------------
>>
>> In the Broadband Forum we need to model a port that can support
>> several physical layer standards, but only one at a time. An initial
>> handshake mechanism determines which of these standards will actually
>> be used. We have been trying to decide how best to model this
>> according to the letter and spirit of RFCs 6020, 6087, 7223 etc.
>>
>> Consider a port, a handshake mechanism "color-selector" and two
>> physical layer standards "green" and "red". Each of these is modelled
>> via a YANG module of the same name ("port" probably uses the
>> ietf-entity module). Here are the approaches that we have considered:
>>
>> ***** Option 1 "direct augment" *****
>>
>> color-selector, green and red all directly augment
>> /if:interfaces/if:interface. An instance of each of them is associated
>> with the port. See part of the tree here (YANG on request).
>>
>> module: ietf-interfaces
>> +--rw interfaces
>> | +--rw interface* [name]
>> | +--rw name string
>> | +--rw description? string
>> | +--rw type identityref
>> | +--rw enabled? boolean
>> | +--rw link-up-down-trap-enable? enumeration {if-mib}?
>> | +--rw color-sel:line
>> | +--rw green:line
>> | +--rw red:line
>>
>> Note that this means that each port needs three separate interface
>> objects. For each additional possible supported physical layer
>> standard, an additional interface object would be needed.
>>
>> ***** Option 2 "indirect augment" *****
>>
>> An additional if-multicolor module directly augments
>> /if:interfaces/if:interface. An instance of if-multicolor is
>> associated with the port. if-multicolor has a supported-type leaf-list
>> that indicates the physical layer standards that are supported by the
>> port (green and red in this case). color-selector, green and red are
>> similar to before but this time they augment
>> /if:interfaces/if:interface/multi:line, and the green and red "when"
>> (existence) criteria are tied to if-multicolor's supported-type
>> leaf-list rather than to their own type leaf. See part of the tree
>> here (YANG on request).
>>
>> module: ietf-interfaces
>> +--rw interfaces
>> | +--rw interface* [name]
>> | +--rw name string
>> | +--rw description? string
>> | +--rw type identityref
>> | +--rw enabled? boolean
>> | +--rw link-up-down-trap-enable? enumeration {if-mib}?
>> | +--rw multi:line
>> | +--rw multi:supported-type* identityref
>> | +--rw color-sel:line
>> | +--rw green:line
>> | +--rw red:line
>>
>> The nice thing about this approach is that it models the port in a way
>> that is close to how it actually _is_. Each port needs only a single
>> interface that's directly associated with the handshake mechanism and
>> the supported physical layer standards.
>>
>> A possible disadvantage of this approach is that it is a bit less well
>> aligned with RFC 7223, e.g there is only one interface-level
>> enable/disable that has to be "shared" by color-selector, green and red.
>>
>>
>> _______________________________________________
>> 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: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
