Thanks for reviewing the document. Your comments are very useful. I have
some comments also.
Cathy Zhou wrote:
>
> Chapter 2 administering a single interface
>
> 1. the introduction section
>
> "however, use of the ifconfig command remains a valid method to
> configure links"
>
> What does this mean?
>
The intention is to affirm that the changes introduced by project
Clearview in general are backward compatible. I will rephrase to make it
clearer.
> 2. Table 2-1
>
> "Task Display devices"
>
> I think it is better to change to "task display physical links", as we
> explicitly obsoleted the "dladm show-dev" subcommand.
>
> Words like this ("display devices, displaying information about devices)
> are all around other sections too.
>
Ok.
> 3. Section "how to configure a physical link after system installation"
>
> 3a. We usually do not include the IP interface configuration as a part
> of the *link configuration*. If you think mix these two makes the
> configuration tasks complete, please make sure to use several sentences
> to explain why we use the term "IP interface" and "link" exchangeably:
> it is because we plumb the IP interfaces using link names, therefore,
> the link name will be propagated up to the IP administrative and
> programmatic interfaces".
>
Understood. The documentation on Clearview is essentially built on
existing (pre-Clearview) book and all the tasks already previously
documented, including the configuration of the IP interface. I will
expand the explanations as you suggested.
> 3b. "step 3. if you intend to rename a data-link, then close that link"
>
> It should be rephrased to something like "if you intend to rename a
> data-link, then make sure that link is not opened by any applications.
> For example, if this interface is plumbed, unplumb it:"
>
Understood.
> 3c. Example 2-1
>
> ibd0 does not look like of MEDIA ether. It should be infiniband. This
> error exist in other sections too.
>
Ok.
> 4. Section "how to replace a network card while using l
> ink names"
>
> 4a. Step 4,5,6 are not clear to me. Do you mean to use DR to remove and
> insert network card? How to perform step 5?
>
This task is also building on existing doc which has a section on
replacing a network card. It wasn't clear in that doc either whether DR
is being used here or not. See more comments on 6a.
> 4b. Please emphasize that if one issue "dladm rename-link <link1>
> <link2>" which link2 is a removed link, to have link1 inherit all link
> configuration of link2, then one cannot have any link configuration on
> link1, for example, one cannot create VLANs or aggregations over link1.
>
Good point. I will add that detail.
> 5. Section "how to display information about devices"
>
> 5.a See comment 2.
>
> 5.b Note that as a recent changes, we are able to display the /devices
> path of specific physical links. For example:
>
> # dladm show-phys
> LINK MEDIA STATE SPEED DUPLEX DEVICE
> net0 ether up 100Mb full bge0
> net2 ether unknown 0Mb unknown bge2
> net1 ether unknown 0Mb unknown bge1
> bge3 ether unknown 0Mb unknown bge3
>
> # dladm show-phys -v
> LINK PATH
> net0 /pci at 1f,700000/network at 2
> net2 /pci at 1d,700000/network at 2
> net1 /pci at 1f,700000/network at 2,1
> bge3 /pci at 1d,700000/network at 2,1
>
Ok.
>
> 6. Section "Using link names in other applications"
>
> 6a. "Dynamic Reconfiguration (DR) can only be performed on system that
> support this feature, and all of these systems are servers."
>
> This is not true. Some wireless card can support DR. We've verified on
> some laptops.
>
The information was provided to me by a writer who manages hardware
documentation. It's for this reason that I also maintained that separate
section about replacing network cards separately (Section 4) from this
section because I thought that DR is a different operation altogether.
My understanding about DR is that, if it is supported, one can make
hardware swaps without any downtime for the machine. So there are
laptops that can do this as well? I'll look into DR more and then revise
the doc.
> 7. Section "Link names and the autopush module"
>
> I think the title better to be "Configure the autopush modules based on
> link names"? Also, it is better to mention its relationship with the old
> autopush support. See details in section 3.1.4 of the UV design doc.
>
Ok.
> Chapter 5 Administering VLANs
>
> 8. Section "VLAN names, VLAN tags and physical pointers of attachment"
>
> Page 9. Before you talk about the vanity VLAN name, you might want to
> consider the current VLAN name rules (pre-Clearview-project). Also,
> please mention while the old VLAN PPA hack "formula" will be supported,
> but it is not recommended
>
> 9. Section "Planning for VLANs on a network".
>
> I don't quite understand step 3.c.
>
This section is directly inherited verbatim from current (S10)
documentation. I'll review it further.
> 10. Section "Configuring VLANs"
>
> 10a. After the Clearview project, *all* interface types should support
> VLAN, except some of them might have the restriction described in
> section 6.1.4 of the UV design document.
>
Ok. The list is also from current S10 docs. I had sent out an inquiry to
the team previously about what to do with lists such as what supports
VLAN, or link aggregations, or IPMP. Based on responses to that inquiry,
it seems safe to remove such lists when clearview is integrated.
> 10b. Note that "ifconfig <vlan ppa name> plumb" should still work to
> configure a VLAN. I think it is still worth mentioning. But remember to
> mention it is not recommended.
>
The use of ifconfig is mentioned but in passing. I will revise to
highlight it bit more.
> 11. Section "How to configure VLANs on legacy devices"
>
> 11a. I think the title should be changed. As it only describes some
> issues with the legacy VLAN configuration. But the VLAN configuration
> tasks over a legacy device or a non-legacy device should mostly the same.
>
Understood.
> 11b. "consequently, creating VLANs over these types of links is not
> allowed"
>
> This is not true. As you mentioned afterwards, you could create VLANs
> over such links using the "-f" option.
>
Got it.
Thanks again!
Raoul
> Thanks
> - Cathy
>
>
> _________________________________
> clearview-discuss mailing list
> clearview-discuss at opensolaris.org
