Les,
Thanks for your comments.
> 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.
Agree and this aspect is baked-in along with some common pitfalls. It also
clears the terminology and nuances here w.r.t "Topology" and "Address
Family".
> 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.
I would like to listen to other opinions too. But at least when operator
commented otherwise in the LSR meeting on the mike and I got 2 emails with
few suggestions and interest.
Let me clarify a bit here. This is precisely laying out various options
w.r.t IPv6 only and why this topic has been confusing for lot of folks
(other than few experts, like you!).
Would be glad to get your comments on the text where it is sounding
objectionable to you or in general if you are seeking any improvements. Thx
in advance for that.
--
Uma C.
On Tue, Nov 6, 2018 at 3:35 PM Les Ginsberg (ginsberg) <ginsb...@cisco.com>
wrote:
> 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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
