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.
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
