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-...@ietf.org 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. 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. 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. 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 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 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 ? 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). 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. - 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. Regards Marshall _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
