Marshall, thank you very much for the review. Some of my comments are inline. On 6/30/11 7:22 AM, "Marshall Eubanks" <marshall.eubanks@xxxxxxxxx> wrote: > I've reviewed this document as part of the transport area directorate's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the document's > authors for their information and to allow them to address any issues raised. > The authors should consider this review together with any other last-call > comments they receive. Please always CC tsv-dir@xxxxxxxx if you reply to or > forward this review. > > Note : I also reviewed the WG mailing list discussions for this document. > > This draft is basically ready for publication, but has some issues that in my > opinion should be fixed before publication. > > There are, however, some issues that I think that should be addressed, either > in a follow-on document, or a revision of this document. > > draft-ietf-pim-mtid introduces a new type of PIM Join Attribute [RFC5384], > the MT-ID Join Attribute, that extends > PIM signaling to cover multiple topologies and to enable the identification of > which topology should be used when > constructing a particular multicast distribution tree. > > Multiple topologies have been used for some time in unicast (they are > supported by IS-IS and OSPF), and also in multicast. The most common multicast > requirement for multiple topologies is for video transport, where important or > expensive video streams (say, of sporting events) are protected from > disruption by multiple transport on completely different network paths. In > that use, if a network link goes down or becomes congested or otherwise > suboptimal, another source of the video data is already present and the > display can be seamlessly switched to the other copy of the stream. This use > case is alluded to in the document. > > Another use case for multiple-topologies is to separate out different types of > traffic (say, latency sensitive traffic from larger, bulk, flows). This is not > alluded to in this document, and it is not clear to what extent this was > intended. These multiple topologies may or may not result > in the replication of data, and so may not be intended by the author. However, > I would say that this could be used to support this, and so it will be. If > there is some reason NOT to use this mechanism for this purpose, some > description of the reasons why would be in order. > > This document sets up a numerical variable, the MT-ID Join Attribute, to > assign to multicast topologies, to be used to separate different topologies > for different paths. This number for a given multicast topology need not be > the same as any unicast multiple topology identifiers, and similarly the > multicast topologies and the underlying unicast topologies may be different. You are right that there are indeed more use cases that can make use of the functions described by this draft. And some do exist in the field. However, we (as co-authors) were very reluctant to list them. We felt this would be more appropriate to be described and published as whitepapers by vendors, and we indeed have discussed them in public on behalf of our employer. It was our intention to try to keep this draft focused on the changes required from a PIM protocol point of view. I hope you will understand and appreciate our viewpoints. > > This document is sort, straight-forward, and relatively well-written. I had a > few non-fatal issues. (I would be glad to suggest some text for any of these > issues to the authors if they interested.) > > Minor Issues : > > Section 3.2 > > "- As shown earlier, this value is not required to be the same as the MT-ID > used by the unicast routing protocols that contribute routes to the topology. > In practice, when only one unicast routing protocol (such as OSPF or IS-IS) is > used, the PIM MT-ID is RECOMMENDED to be assigned using the same value as the > IGP topology identifier. Using the same example presented earlier, if > every route in PIM 500 is contributed by OSPF 1000, it is RECOMMENDED to name > this RPF topology as PIM 1000 instead of PIM 500. This is for the purpose of > reducing management overhead and simplifying troubleshooting." > > In the actual example, PIM 500 is not the same network topology as OSPF 1000 > (it has an extra link, to the source, obtained by MBGP). This is specifically > mentioned previously in the text. So, this is NOT the same example as > presented earlier and it is NOT clear that this recommendation applies here. What we tried to say here is that, 1. If a PIM topology has routes contributed by different protocols, say OSPF and MBGP, it is better to use a different MT-ID for PIM. For example, use 500 for PIM and 1000 for OSPF. 2. But if a PIM topology has all its routes contributed by a single protocol, then it is better to use the same MT-ID as the underlying unicast protocol and in this case, 1000 is used for both PIM and OSPF. Please let us know if the explanation helps and we will definitely appreciate if you suggest some text here. > > If this is left as is, it will certainly confuse some people. I would suggest > adding text to clarify this, or creating another example where the > unicast and multicast topologies are the same. > > Section 4.2.3 > > "- There is at most 1 PIM MT-ID attribute encoded. If there are multiple PIM > MT-ID Join Attributes included, only the last one is accepted for this > particular source. Processing of the rest of the Join message continues." > > Is this a typo ? > > s/at most/at least/ > > would seem to be appropriate. (It says, "at most" 1, and then describes what > do to if there is more than 1.) Otherwise, please explain what is meant. We did mean there can be "at most" 1 MT-ID attribute. But if there are more than 1 included, most likely due to an implementation error, the rest of the paragraph suggests what an implementation should do. Would it be better if we add "due to an implementation error"? > > Section 6. > > The Labels for Section 6.1 and 6.2 are the same. I suspect this is just a > typo, and they should be > > 6.1. PIM-Hello Options > > 6.2. PIM Join Attribute Types > Good catch. Will fix. > More Substantive Issues : > > I had two substantive issues with this document. > > 1.) The range for the topologies. It is highly likely that the users of this > capability would want to use multiple topologies differently for different > multicast address ranges. For example, use of two topologies is likely to be > an expensive customer option, that not all customers would pay for, and so > would not apply to all multicast addresses. Or, the backup typologies may > (probably will be) tailored differently for different customers in different > locations. Or, topologies might be tailored for different data types > (different backups for real time video conferencing versus TV broadcast > transmissions, say). This is very briefly alluded to in Section 3.1, but no > consideration is given to issues arising from this. > > For example, suppose I have two customers, and I wish to have one basic > topology (say, PIM 100) for 239.10/16, and I wish to have two backup > topologies for the two customers (say, PIM 1001 for 239.10.1/24 and PIM 1002 > for 239.10.2/24.) Can I have PIM 100 cover both the PIM 1001 and PIM 1002 > range ? Are there issues with this ? Would it be better to split PIM 100 into > pieces to match 1001 and 1002 ? Nothing like this is discussed The draft allows the above to happen. Because as I indicated earlier, the draft tries to focus on the protocol changes required to support the functionality but not the deployment cases that can make use of it. > > I can easily see interoperability issues arising from this (i.e., vendor A > might allow PIM 100 to overlap PIM 1001 and PIM 1002, and vendor B might not). > I think that some text to discuss the entire issue of ranging (presumably, > that they can be allowed and overlaps SHOULD be supported) is needed. > > Again, this could be out of scope here, but, then, where will it appear ? I agree it is out of scope for the reasons I explained earlier but I don't have a good answer what is the best practice to document all these cases. > > 2.) There is very little discussion as to how to use this capability. Now, > this might be considered out of scope for this document, but there will be > issues, and I do not see a follow-on in the pipeline. > > Issues include sharing of links and the general connections between > topologies. It is likely that in real uses, a portion of the multiple > topologies may be either physically shared or directly linked. It may not be > possible to engineer out all single points of failure, for example an undersea > cable. This is possible with the first use case (independent topologies for > video) and likely with the second (different topologies for different types of > content). > Yes, same as above. > Issues I see here include > > - the actual multicast data will not include any PIM attributes. How, then, > is a midpoint router receiving two copies of every packet know that it > shouldn't just drop one, and only populate one of the downstreams ? Or, should > it replicate one input into both downstream topologies ? I can easily see > interop issues here, and possibly even more basic transport issues from > replicated data. > To use the functionality, the two streams of multicast must differ somehow at the network layer. For example, one uses (S1,G1) and the other uses (S2,G2). Because the addresses are different, the forwarding trees will be built using routes in the (multiple) topologies. And once the forwarding trees are built, the actual action of "forwarding" doesn't need to be concerned with topologies. > - if at any point the two multicast topologies go through a shared LAN or > switch or any sort of multiple access network, how are the topological flows > going to be kept distinct. (This is similar to the above, but the actual > routers might be kept separate.) > > - what happens with failovers ? If a link fails, SHOULD the backup links not > collapse the topologies ? Again, I think some thought and text would be > useful. > > If there is a solution to this, it may be simple (you MUST use tunnels) or it > may be complicated. In either case, some text here would be good. > Marshall, it would be good if you can suggest some text for us to use. Thanks. > Regards > Marshall > _______________________________________________ > pim mailing list > pim@xxxxxxxx > https://www.ietf.org/mailman/listinfo/pim -- Yiqun _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf