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

From: Stig Venaas <[email-masked]>
Date: Fri, 20 Aug 2010 13:33:55 -0700

Hi Dimitri

Can we try to follow up on this and try to come to some conclusions?

Stig Venaas wrote:
> 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?

I still believe the amount of processing is reduced. I think it is
clear that TCP state and explicit tracking increases the amount of
stored state though. Do you think that needs to be emphasized? I'm
not sure if that belongs in the introduction though.

>> - 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?

Do you think it is necessary to explain exactly how not to send
periodic messages? Could you suggest some text so I understand more what
you are looking for? As I see it you do use the Join Timer as now to
schedule joins etc (like triggered joins), you simply don't set the
Join Timer to t_periodic afterwards. What matters is the external
behavior though. E.g. an implementation could run the timer, but
determine in some other way that it does not need to send a J/P.

>>
>> 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.

I hope this has been sufficiently discussed and that the current text
is OK.

>> - 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?

I'll add text saying that unknown instant types must be ignored. Which
means for now, anything other than 0 is ignored. And 0 means not in use.

> 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.

Please read that section again and let me know what more it needs to
say. IMO it does describe it for other types of interfaces.
>>
>> - 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.

I've been thinking more about this. TCP keep-alives can actually be
enabled without any negotiation. So no protocol changes are needed. It
is perfectly fine for one peer to use it and not the other. At least
that is my understanding.

I suggest just adding text saying that TCP keep-alive may be useful to
detect when a connection is not working and that implementations may
make use of it. Any thoughts on MAY, SHOULD, whether default or not?

At least I would prefer not having it on by default.

Stig

>> 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
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Sat, 21 Aug 2010 00:14:09 +0200

Hi Stig, 

> From: Stig Venaas [mailto:[email-masked]] 
> Sent: Friday, August 20, 2010 10:34 PM
> To: Papadimitriou, Dimitri (Dimitri)
> Cc: [email-masked]

The part that is confusing resulting from the following sentence: 

"The explicit non-goals of this specification are:

   o  Changes to the PIM protocol machinery as defined in [RFC4601]."

I understand it as follows: no modification wrt to RFC 4601, but if nothing "changes" how improvement can be achieved ?

In brief, either nothing changes and then the addition TCP results in increasing the number of states. Or this document is an RFC 4601 "update" and then messaging can be reduced (triggered vs refresh) and the processing associated to these messages can thus be reduced. 

> >    incremental rather than periodic JPs over a TCP/SCTP connection

. The question is: where this explanation/specification is, this is a statement (in this Section 2) but no explanation.

. The text in the introduction is not clear from that respect, because it states 

"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."

but doesn't tell what replaces the "periodic JP message exchange" 

. Upfront the statement (as part of the introduction)

"The goals of this specification are:

   o  To create a simple incremental mechanism to provide reliable PIM
      message delivery in PIM version 2 for use with PIM Sparse-Mode
      [RFC4601] and Bidirectional PIM [RFC5015].

doesn't help either the term "simple incremental mechanism" does not refer to any exchange of J/P message.

Side remark, it is not the incremental J/P exchange that improves "reliability" (but the use of TCP/SCTP).

> >    generate periodic JPs for routes which RPF to a PORT-capable

Same as first point here above (the sentence turns the previous statement the other way around).

> periodic messages? 

Yes.

> Could you suggest some text so I understand more what

The reason is because timer operation, in soft-state is one of the most critical aspect. you have two timers to whose operations needs to be specified: t_periodic and Join Timer which depends on t_periodic (the last once results in many updated to the RFC 4601 specification).

> I hope this has been sufficiently discussed and that the current text

What is not clear is the following statement:

"  While a router interface is PORT enabled, a PIM-over-TCP or a PIM-
   over-SCTP option is included in the PIM Hello messages sent on that
   interface.  When a router on a PORT-enabled interface receives a
   Hello message containing a PIM-over-TCP/PIM-over-SCTP Option from a
   new neighbor, or an existing neighbor that did not previously include
   the option, it switches to PORT mode for that particular neighbor.

   When a router switches to PORT mode for a neighbor, it stops sending
   and accepting Native JP messages for that neighbor.  Any state from
   previous Native JP messages is left to expire as normal.  It will
   also attempt to establish a Transport connection (TCP or SCTP) with
   the neighbor."

it reads like you receive the "PIM Hello" and then set the TCP connection. So these two paragraph read like you switch to the PORT mode when the TCP connection is not setup with the neighbor ? is that what you intend to do ?

> means for now, anything other than 0 is ignored. And 0 means 

OK

> say. IMO it does describe it for other types of interfaces.

To clarify, I'm not referring to the p2p case, I refer to the description for other types of i/f, the following text in that Section 6 states "Exactly how this is implemented and for which link types, is left to the implementer." I wonder how we could achieve 

> At least I would prefer not having it on by default.

As the use of TCP is intended to improve reliability, and keep-alive is useful for checking for peer liveliness in before it goes down before notifying the other end - and with triggered updates the connection will be idle (since Hellos are maintained aside); thus, a should goes along the lines of such improvement.

Thanks,
-dimitri.

---

From: Yakov Rekhter <[email-masked]>
Date: Sat, 21 Aug 2010 18:33:07 -0700

Stig,

> Yakov Rekhter wrote:
> > Dimitri,
> >> - 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 ?
> > 
> > In fact, since PORT requires explicit tracking, it clearly adds
> > state overhead for routers connected to multi-access interfaces.
> 
> Note that it talks about "processing" and "state maintenance". It's
> not saying that there is less state, only that you need to do less
> processing to maintain the state. Which of course is because there
> are no periodic messages.

For the *same* amount of state eliminating periodic messages would
indeed reduce the processing overhead. But as I pointed out, on
multi-access interfaces PORT adds state overhead. Thus, even if the
processing overhead *per unit of state* is reduced, the overall
processing overhead may be higher relative to plain PIM.

So, the claim about "processing... reduced" may not be correct.

> > So, in reality for routers connected to multi-access interfaces
> > PORT provides a tradeoff between less control traffic
> > overhead at the cost of more control plane state overhead.
> 
> Right, it requires additional state, but I will still argue
> that maintaining the state costs less.

See the previous comment...

> > With this in mind I would suggest to replace
> > 
> >    This specification enables greater scalability in multicast
> >    deployment since the processing required for protocol state
> >    maintenance can be reduced.  
> > 
> > with the following:
> > 
> >   This specification enables greater scalability in terms
> >   of control traffic overhead. However, for routers connected
> >   to multi-access links that comes at the price of increased
> >   control plane state overhead.
> > 
> > Yakov.
> 
> So I think this is mostly covered, but I'm happy to point out
> that there is additional state required for multi-access links.

Note just there is not just additional state, but also there is
additional control plane overhead required to maintain/process this
state.

To reflect this I would slightly modify my original proposed text
as follows:

    This specification enables greater scalability in terms
    of control traffic overhead. However, for routers connected
    to multi-access links that comes at the price of increased
    control plane state overhead and the control plane overhead 
    required to maintain this state.

> Thanks for all the feedback. I will start working on an updated
> version and propose some changes based on your comments.

Looking forward for the updated version that reflects the above
comments.

Yakov.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 25 Aug 2010 10:57:28 -0700

Yakov Rekhter wrote:
[...]
> Looking forward for the updated version that reflects the above

OK, I agree this may be an issue, I'll use your text.

Thanks,

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 25 Aug 2010 11:21:08 -0700

>> not sure if that belongs in the introduction though.

I'll use the text Yakov suggested regarding state.

> I understand it as follows: no modification wrt to RFC 4601, but if nothing "changes" how improvement can be achieved ?

OK, this is a bit too strong. I can change it and say that a goal is to
minimize the changes to PIM.

> The reason is because timer operation, in soft-state is one of the most critical aspect. you have two timers to whose operations needs to be specified: t_periodic and Join Timer which depends on t_…

As I said, basically whenever you set the Join Timer to t_periodic in
4601, you would skip that for PORT. Basically when the Join Timer
expires you would trigger whatever action you do today (like sending
a triggered J/P), but not set the timer to t_periodic afterwards.

Another way to say it though, could be that t_periodic is infinite. In
fact you could implement a poor man's PORT just setting t_periodic very
large...

Or possibly you could have PIM attempt to send the J/P but somehow
figure out it is a periodic J/P and not actually send a PORT J/P.

The other thing is expiry of entries in the oiflists. As long as you
have PORT state for downstream neighbors you need to behave the same as
if you received periodic J/Ps. This can be done in a couple of ways.
You can let the interface Expiry Timer run, and simply restart it if
there is PORT state (as if you just got a new periodic J/P). Or you
might not run the timer at all.

I would argue though that it is fairly obvious what needs to be done,
and based on your implementation you might choose different ways of
achieving it.

Would some text in the style of the above (I would need to check in
4601 to be sure use the same term) be sufficient?

> it reads like you receive the "PIM Hello" and then set the TCP connection. So these two paragraph read like you switch to the PORT mode when the TCP connection is not setup with the neighbor ? is t…

Yes. Else there are some issues related to whether to use PORT or
not and the two neighbors not agreeing whether the connection is
up.

I'll submit a new version in a few days that you guys hopefully are more
happy with. The main outstanding issue seems to be in how much detail to
describe the J/P timer and expiry.

Stig