Having now read the draft in its entirety... As per the discussion in the WG meeting today...
I agree that MT and its relationship to address-families can be confusing. I also agree that when deploying multiple address-family support the decision to use/not-use MT can be confusing. I also agree that now that IPv6 only deployments are becoming a reality whether to use MTID #0 or MTID #2 can be confusing. Etc. The discussion in the WG seemed to focus on the benefits of writing a deployment guide to both recommend desirable deployments configurations and alert folks to the problems they are likely to see if they are not careful in ensuring their topology usage matches their actual address-family support. It is often the case that vendors write configuration/deployment guides to provide guidance to their customers as to how to configure a feature. In doing so, a vendor is free to express their biases as to what they consider a preferred strategy. If the IETF were to do the same thing, there is a higher bar - since any IETF document represents a consensus of the WG in which it was written. There is more than one way to configure address-family support and each of us may have our biases as to which of the multiple strategies is preferred. Consensus on this is not required nor is it necessarily easy to achieve. I am therefore NOT eager to have the IETF become the home of "feature deployment guides". If we were to proceed with this draft at all, I therefore think we should limit the scope to merely explaining what the requirements for correct operation are using the various modes. I emphasize again that RFC 1195 speaks quite directly to the limitations of using a single topology to support multiple "address-families". (The discussion there is CLNS/IP oriented - but the issues are the same as IPv4/IPv6.) I am not fully convinced we need an additional draft on this topic. But I am convinced that IETF should NOT be writing deployments guides. Les _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
