mboned: draft-ietf-mboned-deprecate-interdomain-asm-01/02

I have just posted updates to subject draft. -01 was great text overhaul
and cutting out unnecessary meat by Lenny. -02 is text proposed by me on
top, alas we ran out of time for review by the other authors, i am
sure there is lot to improve on the new text (or undo), so please
don't beat up the poor co-authors, just me on those changes ;-)

Beside hopefully some usefull formatting improvements, the mayor
part of the next text goes back to the discussions made at last IETF
and on & off the list with James Stevens, primarily circling around
Bidir-PIM and the fact that unlike PIM-SM we (well i) really don't think
its obsolete, but then too is it not interdomain, but also like PIM-SM
providing ASM, so just not mentioning it (hey it's not interdomain, no
need to mention it) didn't seem good to me - it definitely raised
concerns by those using it (like James).

So, the mayor additions to hopefuly resolve these discussions:

2.2.3 Bidir-PIM - explaining it

3.2.2, 3.2.3

overhauled explanation of the SSM benefits of address
management and intrinsic source-control. I felt these where
important to give equal treatment to 3.2.1 (network operations
complexity), because these are independent of PIM-SM and equally
apply e.g.: to Bidir-PIM - or for that matter any current/future
ASM protocol.

4.4 development of applicatoion guidance

In section 4.3 we recommend application to support SSM. This of
course only works for apps that can use SSM. And we know there
are good application that will only work well with ASM/Bidir-PIM
for scale and other reasons. Alas, there are also a lot of
bad applications making the claim they need ASM (most service
discovery natively using IP multicast without anything better).
So we really need better guidance how to vet applications
use of multicast to decide if they should use SSM vs. ASM (really
only when you'd need to use Bidir-PIM ot make them fly) or
service-discov ery.

4.8 (not precluding intradomain ASM)

Added notion that this doc is not precluding Bidir-PIM deployments
and hopefully made a clearer distinction between intradomain
PIM-SM with single PIM-SM domain, and those multi-PIM-SM-domains
where Embedded-RP etc. wold be used. Using term "inside organiations
like federations"..

4.9 Added: Evolving PIM deployments for SSM

This may be duplicate from some other mboned RFC i can't find
by explaining how easy it is to add SSM to existing PIM-SM
deployments in more detail. Through the discussions had it
also seemed important to write this to highlight that we
probably do not want to encourage crazy transition soltions like
using SSM on ASM address space (i had a lot of such deployments,
and it always had one or the other issue). And specifically
the issue that this is all undefined with ASM when using Bidir-PIM.

5. Future interdomain ASM work

As a closing section, i thought it would be useful to make
a more generic statement over the future of ASM and SSM,
of course this may be contentuous, but this is how i see it.

This is explicitly not part of the recommendations of course.

Cheers
    Toerless

_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned