Hi William,
Please see inline ...
On 11/11/2015 12:21, William Lupton wrote:
Rob, Thanks! Please see inline. Cheers, William.
On 11 Nov 2015, at 10:49, Robert Wilton <rwil...@cisco.com
<mailto:rwil...@cisco.com>> wrote:
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?
I'd say "no" in the sense that the port is initially a color-selector
port, and then (after the colour selection) will be either a green
port or a red port. These are all types (interface types).
OK. I'm not sure whether changing the type of an existing interface is
a good idea. E.g. shouldn't the interface type of the base interface
represent the physical interface that you are operating over.
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.
In the second case (indirect augment), a single multi:line interface
is associated with the port, so the standard "enabled" leaf node
(administrative enable/disable) will apply to the the multi:line
interface. This means that there is no way (should you wish it) to
individually disable green or red. This would require addition of such
controls at the green and red level.
OK. But if I understand it correctly a particular port could only ever
be running as either green or red, never both at the same time. Is that
right? Is so, then I would have thought that a single interface
enable/disable is sufficient.
Presumably disabling green or red colours could be accomplished by
removing the associated configuration.
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! I'll take a look at those drafts. Would this approach allow
green and red config to exist simultaneously on an interface?
No. The choice statement means that there can be only one colour of
config at a given time.
Is your requirement effectively a templating one? I.e. the need to
define possible configuration for both red and green and then allow the
protocol to negotiate which colour and hence configuration is used?
I think we'd want to be able to do that. Perhaps the choice approach
might be used only in the state tree?
Yes possibly, although equally if the leaves in the state tree are not
mandatory then the information for the unavailable colour could just not
be returned.
Thanks,
Rob
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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
