Subject: Re: [pim] wglc for draft-ietf-pim-port-03

From: Stig Venaas <[email-masked]>
Date: Fri, 25 Jun 2010 14:05:13 -0700

Thomas Morin wrote:
> Hi Stig, Dino, Ice, Maria,
> 
> The document is I think generally in a good shape.

Thanks for your detailed review and comments! I'm working on an update
where I believe I've addressed all of your comments.

I pretty much incorporated all your changes to the letter. I'll get
back with a new version or proposed changes shortly.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Fri, 25 Jun 2010 14:50:57 -0700

Papadimitriou, Dimitri (Dimitri) wrote:
> Hi Stig,
> 
> A couple of comments on this doc:

Thanks for reviewing this. I think we need to discuss some of your
points below and see we can agree on some text.

> - Introduction mentions "This specification enables greater scalability in multicast deployment since the
 > processing required for protocol state maintenance can be reduced". 
Can authors explain how leaving PIM state
> maintenance unmodified (see Intro) but adding TCP state reduces protocol state ?

It says "processing required for protocol state maintenance", the
processing needed to maintain PIM state is mainly sending/processing
of PIM messages. Maintaining this state is a lot more costly than
maintaining TCP state, including explicit tracking.

Don't you agree that the total amount of processing will go down?

> - Introduction mentions "This document will specify how periodic JP message transmission can
> be eliminated by using TCP [RFC0761] or SCTP [RFC4960] as the reliable transport mechanism for JP messages."
 > where is the periodic message elimination described in this document 
(beside the two sentences in the middle of
 > Section 2).

Section 2 says:

    PIM Over Reliable Transport (PORT) is a simple extension to PIMv2 for
    refresh reduction of PIM JP messages.  It involves sending
    incremental rather than periodic JPs over a TCP/SCTP connection
    between PIM neighbors.

    When PORT is used, only incremental JPs are sent from downstream
    routers to upstream routers.  As such, downstream routers do not
    generate periodic JPs for routes which RPF to a PORT-capable
    neighbor.

isn't this sufficient? Do you think it is necessary to describe in
greater detail how we don't send periodic messages?

> 
> Note also that the document states "The explicit non-goals of this specification are: Changes to the PIM protocol machinery as defined in [RFC4601]." 
> 
> - Section 4: why switching to PORT mode occurs upon Hello reception ? and not upon TCP connection establishment ?

The main problem here is that you want to allow the usual native
Join/Prune messages when not doing PORT. It is possible that one
neighbor believes the TCP connection is up and not the other. When
it goes down or up, one router will realize it is down or up before
the other. This combined with the potential for the native messages
and PORT messages arriving out of order can cause problems.

I guess I can try to come up with a concrete example. The way it is
done now is simpler and more determinstic.

> - Section 5: introduces the Type 0 "instance ID" field what the size of this field ? What happens in case of
 > Instance mismatch ? To what "instance" refers to ?

The size is 64 bits as can be seen from the diagrams. With mismatch, you
mean if one router sends an instance ID value and the other doesn't know
what it is? We are trying not to define how to use "instance" here and
only use type 0, which means it is not used. The "instance ID" is then
ignored by the receiver, so mismatch is not an issue.

We should maybe say that unknown instance types must be ignored?

We're really trying to not specify in any way how it can be used though.
It's all left for possible future work.
> 
> - Section 6: there is no description of explicit tracking on non point-to-point interfaces. Can authors describe
> tracking for the other types of interfaces ?

That is exactly what we are describing here. For point-to-point you
don't really need to do explicit tracking, or rather, you know which
neighbor anyway, so tracking is implicit.

> 
> - Is there any use of TCP-based, keep-alive mechanism to determine if PIM neighbors are reachable ?

No, so there is a problem if you receive PIM Hello's but TCP is not
working. It is kind of an open question whether keep-alive really is
needed. That could be defined separately if we see a need. Or do you
have some good example/reason for doing it now? I'm not against adding
keep-alives as optional if it is clear that it is needed.

> Editorials:
> 
> - The term "Reliable JP" is confusing so goes sentences like "Reliable JP messages are sent using a
> TCP/SCTP connection" afaik it is the communication mode that enables reliability. This term is only
 > used in the introduction and thus be removed to uniquely refer to 
PORT-mode (transport) vs Datagram-mode (native).

I agree with your logic. I'm changing to use the term "PORT Join/Prune 
message" instead of
"Reliable Join/Prune message".

> - Ref: why do you refer to RFC 761 and not RFC 793 "[RFC793]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. the latter replaces the former.

Fixed

> - PIM-SSM is mentioned in Section 8 not in the introduction.

Fixed

> - The use of acronyms JP, JPs, etc. decreases readability. Recommended to use "Join-Prune", "Join-Prune messages", etc.

Fixed (using Join/Prune and Join/Prune Message as in 4601).

Stig

> Thanks,
> -dimitri.
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Stig Venaas
>> Sent: Monday, May 10, 2010 4:08 AM
>> To: Mike McBride (mmcbride)
>> Cc: [email-masked]
>> Subject: Re: [pim] wglc for draft-ietf-pim-port-03
>>
>> Mike McBride (mmcbride) wrote:
>>> Today begins a two week wglc for draft-ietf-pim-port-03. 
>> Please let your
>>> yeahs and nays be heard on this list.
>>>
>>> http://www.ietf.org/id/draft-ietf-pim-port-03.txt
>> The wglc is ending in 2 days and there has been complete 
>> silence on the
>> list. Please post to the list whether you think the document 
>> is ready to
>> be submitted to the IESG. And if you have any issues, please speak up.
>>
>> Just to repeat, if you have read the document and believe it is ready,
>> then we also want to hear from you.
>>
>> Not that as discussed in the wg meeting I will add a sentence or two
>> saying that SCTP is preferred over TCP if both are announced in the
>> hello messages by a pair of neighbors.
>>
>> Stig
>>
>>> thanks,
>>> mike
>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] 
>> On Behalf Of
>>>> Mike McBride (mmcbride)
>>>> Sent: Friday, April 16, 2010 3:02 PM
>>>> To: [email-masked]
>>>> Subject: [pim] wglc for draft-ietf-pim-port-03?
>>>>
>>>> At the Anaheim meeting there were 5 YES votes and 1 NO 
>> vote for moving
>>>> to wglc for draft-ietf-pim-port-03. Please let us know 
>> what the rest
>>> of
>>>> you think before a week from today. If we maintain rough 
>> consensus, we
>>>> will initiate a wglc on April 23rd, so speak up.
>>>>
>>>> http://www.ietf.org/id/draft-ietf-pim-port-03.txt
>>>>
>>>> thanks,
>>>> mike
>>>> _______________________________________________
>>>> pim mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/pim
>>> _______________________________________________
>>> pim mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/pim
>> _______________________________________________
>> pim mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pim