Rob, Thanks! Please see inline. Cheers, William.
> On 11 Nov 2015, at 10:49, Robert Wilton <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).
> 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.
> 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? I think we'd want to be
able to do that. Perhaps the choice approach might be used only in the state
tree?
> 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 <mailto:netmod@ietf.org>
>> https://www.ietf.org/mailman/listinfo/netmod
>> <https://www.ietf.org/mailman/listinfo/netmod>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
