Re: [MSDP] Reminder -- MSDP WG last call ends at 1700 PST Today

Pekka,

> On Mon, 2 Dec 2002, David Meyer wrote:
> > 	So please get comments to the list if you have them.
>
> Ok, thanks fot the reminder -- forgot already.
>
> As a novice in both MSDP and PIM-SM draft reading there were a few things
> that struct as quite confusing.
>
>  1) (a bit besides the point here, but..) pim-sm-new draft introduction
> text is as if every sender/receiver was in the same PIM domain.  Should
> MSDP spec somehow clearly point out the differences in the model described
> in the introduction, or even rewrite relevant parts of the introduction in
> the MSDP spec?

It was decided to make the least amount of changes to the text as possible
to avoid the rathole of rewriting the entire spec. We will be sure to make
everything crystal clear in the MSDP BCP with hopefully more of your
feedback.

>  2) The bit:
>
> --8<--
> 9. Intermediate MSDP Peers
>
>    Intermediate MSDP speakers do not originate periodic SA messages on
>    behalf of sources in other domains. In general, an RP MUST only
>    originate an SA for a source which would register to it, and ONLY RPs
>    may originate SA messages.
> --8<--
>
> I have hard time parsing this one, having little background in the failure
> modes or wrong behaviour that's being referred to here.  If this means
> what I think it means, one might add something like:
>
>    Obviously, intermediate MSDP speakers still forward SA messages
>    received from other domains.
>
> Or otherwise clarify what those "SA messages behalf of sources in other
> domains" actually are, I'm having difficulties figuring that out..

The section 9 text has remained unchanged since -09. We saw no controversy
or otherwise so left it alone. Further clarification can be done in the
BCP.

> 3) what the heck is this:
>
> --8<--
> 15. Packet Formats
>
>    MSDP messages will be encoded in TLV format. If an implementation
>    receives a TLV that has length that is longer than expected, the TLV
>    SHOULD be accepted. Any additional data SHOULD be ignored and the
> 	MSDP session should not be reset.
> --8<--
>
> This can be interpreted two ways:
>
>  * at first read, I thought it was like "(final) TLV has more data than
> Length specifies", apparently that's not the case, and for that the below
> applies:
>
> I fail to see any reason (except coping with some possibly broken
> implementations) why wrong length should not be used -- if they have
> additional data to send, why don't they just increase the damn _Length_ of
> TLV's ??
>
>  * at second read, I noticed that it probably means that length values
> longer than 9192 should also be accepted (but the rest of the packet after
> 9192 bytes ignored).  This is a bit dubious too, but acceptable to ensure
> interoperation, I guess.  If this is the case, perhaps:
>
>  If an implementation
>    receives a TLV that has length that is longer than expected, the TLV
>    SHOULD be accepted.  Any additional data SHOULD be ignored and the
>    MSDP session should not be reset.
>
> should be reworded like:
>
>  If an implementation
>    receives a TLV whose Length exceeds the maximum TLV length,
>    specified below, the TLV SHOULD be accepted.  Any additional data,
>    including possible next TLV's in the same message, SHOULD be ignored
>    and the MSDP session should not be reset.

These three sentences in section 15 have remained unchanged since -02
and we are not inclined to make any changes to them in this final draft.
We did, however, add "and the MSDP session should not be reset." Again, we
could reword this entire draft but that is not our objective. Our
objective was to document the minimum amount of functionality someone
would need to implement in order to interoperate with currently deployed
implementations.

> 4) I believe you should add some notion of MSDP SA rate-limiting features,
> mentioned earlier in the draft, in the security considerations section;
> it's just so easy denial-of-service attack, and people should be aware of
> that.

Included in the MSDP BCP which will be sent to the list for review soon.

thanks,
mike