Subject: [pim] Some questions and suggestions on PIM-PORT draft

From: Bharat Joshi <[email-masked]>
Date: Mon, 13 Dec 2010 20:17:32 +0530

Hi Authors,

      I got some time to review this draft in detail. This is my first review of this draft and I did not get time to go through the archives so some of the questions might be repeated here. I hope it is still in time for the WG last call.

      Overall I support the work done in this draft. Below are the questions I have collected (they are written in the order in which they appear in the draft) for this draft. Most of them are minor in nature but it will be good it they are addressed before the draft is advanced to IESG.

Regards,
Bharat

• In Introduction, in 'explicit non-goals', draft refers to Transport mode and datagram mode of PIM. Can we use the actual definition rather than using these terms here?

• Should not datagram mode be actually called as packet mode?

• In last sentence of last para of introduction, "stream is critical to maintaining efficient use of bandwidth" to "stream is critical for maintaining the efficient use of bandwidth"

• In 'protocol overview', in following para:

   PORT Join/Prune messages are sent using a TCP/SCTP connection.  When
   two PIM neighbors are PORT enabled, both for TCP or both for SCTP,
   they will immediately, or on-demand, establish a connection.  If the
   connection goes down, they will again immediately, or on-demand, try
   to reestablish the connection.  No Join/Prune messages (neither
   Native nor PORT) are sent while there is no connection.

Should we also mention that if a native join/prune message is received from a PORT enabled neighbor, it should simply be discarded.

Also is not it too restrictive to not use native join/prune till a connection is established?

• In 'protocol overview', in following para:

   PORT Join/Prune messages are sent using a TCP/SCTP connection.  When
   two PIM neighbors are PORT enabled, both for TCP or both for SCTP,
   they will immediately, or on-demand, establish a connection.  If the
   connection goes down, they will again immediately, or on-demand, try
   to reestablish the connection.  No Join/Prune messages (neither
   Native nor PORT) are sent while there is no connection.

The last sentence suggest that even native join/prune messages are not sent when there is no connection. Why is that? Should not we continue with native till the connection is established?

• In 'protocol overview', can we add a para describing the well-known port which PIM will use for both TCP/SCTP? So a router will now use this port to identify the PIM protocol messages and IP protocol number for PIM will not be used.

• In section 3.1, for 'Length', can we add the value of 'X' if AFI is set to zero.

• There are couple of places where draft makes a recommendation. Should this text use RECOMMEND instance of 'recommend'?

• Is interface-id suppose to be the interface-id in the downstream router or it can be any four byte number which can be used by downstream router consistently for each join/prune message. Upstream router can use this to identify a specific interface that can be added/removed as OIF for a given (*,G) or (S,G) etc. Actually it could be GEN-ID as well. It should not matter as long as upstream router can find the attached interface for OIF operations and downstream router always use the same id.

• A small typo in 'Interface ID' "Interface ID is used convey the interface from" -> "Interface ID is used to convey the interface from"

• Same as above for 'SCTP' hello option as well.

• In section 4, a comma is missing in, "When the router is using TCP it will compare" -> "When the router is using TCP, it will compare"

• Even though SCTP can figure out call collision, would not it make sense to use TCP style connection establishment so that implementation can use one single method.

• In following para in section 4:

   If PORT is used both for IPv4 and IPv6, both IPv4 and IPv6 PIM Hello
   messages are sent, both containing PORT Hello options.  If two
   neighbors announce the same transport (TCP or SCTP) and the same
   Connection ID in the IPv4 and IPv6 Hello messages, then only one
   connection is established and is shared.  Otherwise, two connections
   are established and are used separately.

In above para, I did not get how IPv4 and IPv6 connection ID can be same? Because one will be IPv4 address and another will be IPv6 address? Am I missing something here?

• In section 4, typo in "cause routers on the link on the link"

• In section 4, It will be great if we can mention the state maintained by a upstream router when both native or PORT neighbors has joined a (*,G) or (S,G) channel. Though this information is available but this is scattered in the document.

• In section 4.1, 'TCP connection maintenance', last para does not seems to be related to TCP connection maintenance. It will be good to move it out to some other section.

• In last para of section 4.1, it suggests to cache messages which are ignored due to temporary conditions. Will a router be really able to differentiate a temporary conditions with a permanent situations? It looks like it is better to remove this text as the state will be brought up-to-date when GEN-ID is changed.

• In section 4.3, in "Especially in the case where there is no need for n^2 connections on a network interface.", what is 'n'?

• In section 4.5, can we reword:

To ensure there are not two connections between a pair of

to

To ensure that there are only one connection between a pair of

• In section 5, "when sending over a stream protocol like Transport" -> "when sending over a stream protocol like TCP/SCTP"

• What is the use of defining instance-id and instance-type when we are setting it to zero and do not add any values for instance-type? What kind of role we see for such a field?

• Can we add the size of instance-id in IPv6 header?

• Small type in section 6. 'non-ETP neighbor is interested' -> 'non-ET neighbor is interested'

• In section 7, we have described how instance-id can be used. But will it not be better to add this support using a TLV rather than adding a filed in the header itself. This way, people can generate the instance-id based on their own methods and it need not be restricted by just 64 bytes.

• Should instance-id type also falls under IANA?
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: Stig Venaas <[email-masked]>
Date: Wed, 15 Dec 2010 11:15:45 -0800

Thanks a lot Bharat.

I will revise the draft based on this. See comments inline.

> • Should not datagram mode be actually called as packet mode?

I'm trying to keep to the terms "transport mode" and "datagram mode"
throughout. Since the terms are not yet defined though, I suggest
changing the first sentence of the bullet to:

    o  Provide support for automatic switching between the reliable
       transport mechanism and the regular mechanism defined in
       [RFC4601].

I don't want to use packet mode. The regular way is sending IP
datagrams. One IP datagram might be fragmented into multiple
packets. This is in line with e.g. RFC 791.

"
> • In last sentence of last para of introduction, "stream is critical to maintaining efficient use of bandwidth" to "stream is critical for maintaining the efficient use of bandwidth"

Right

> Should we also mention that if a native join/prune message is received from a PORT enabled neighbor, it should simply be discarded.

Yes.

> Also is not it too restrictive to not use native join/prune till a connection is established?

There are some issues with doing that. In particular, there may be
cases where one neighbor believes the connection is up, while the other
believes it is down. Having one router send datagrams and the other
ignoring them causes problems. Not ignoring them when the connection is
up, also causes problems.

> The last sentence suggest that even native join/prune messages are not sent when there is no connection. Why is that? Should not we continue with native till the connection is established?

See above paragraph.

> • In 'protocol overview', can we add a para describing the well-known port which PIM will use for both TCP/SCTP? So a router will now use this port to identify the PIM protocol messages and IP prot…

Will do.

> • In section 3.1, for 'Length', can we add the value of 'X' if AFI is set to zero.

Right, will do.

> • There are couple of places where draft makes a recommendation. Should this text use RECOMMEND instance of 'recommend'?

The two occurences in section 3, and the first in 4.1 should be
RECOMMEND (or RECOMMENDED) I believe. I'm not so sure about the
rest. The other text is more informational kind of, also using
"should" etc. in lower case.

> • Is interface-id suppose to be the interface-id in the downstream router or it can be any four byte number which can be used by downstream router consistently for each join/prune message. Upstream…

Yes, the interface-id can be pretty much anything. The easiest is
simply to make sure that a router has a unique interface id per
PIM enabled interface. Strictly speaking it could be sufficient to
have unique interface IDs for all interfaces that use the same
Connection ID. The only thing that matters is that it can be used
by the upstream to tell which interface the J/P is for. Which is
in the draft.

> • A small typo in 'Interface ID' "Interface ID is used convey the interface from" ->  "Interface ID is used to convey the interface from"

Thanks

> • Same as above for 'SCTP' hello option as well.

Thanks

> • In section 4, a comma is missing in, "When the router is using TCP it will compare" ->  "When the router is using TCP, it will compare"

Right

> • Even though SCTP can figure out call collision, would not it make sense to use TCP style connection establishment so that implementation can use one single method.

I see this as a good benefit with SCTP, and it is not hard to implement
them differently. Maybe a couple of lines of code extra, but I think it
is worth it. Also for an SCTP only implementation it would make it a lot
simpler.

> In above para, I did not get how IPv4 and IPv6 connection ID can be same? Because one will be IPv4 address and another will be IPv6 address? Am I missing something here?

You can use an IPv4 connection ID in an IPv6 Hello, and vice versa.

> • In section 4, typo in "cause routers on the link on the link"

Oops

> • In section 4, It will be great if we can mention the state maintained by a upstream router when both native or PORT neighbors has joined a (*,G) or (S,G) channel. Though this information is avail…

OK, I guess I can do that. Basically you need to keep state for PORT
neighbors as described. At the same time the behavior for non-PORT
neighbors would need to be maintained as now. E.g. with expiry
timers running.

> • In section 4.1, 'TCP connection maintenance', last para does not seems to be related to TCP connection maintenance. It will be good to move it out to some other section.

I think I want to keep it there anyway, as it relates to the
paragraph above about changing GENID and resending all state.

> • In last para of section 4.1, it suggests to cache messages which are ignored due to temporary conditions. Will a router be really able to differentiate a temporary conditions with a permanent sit…

This is implementation details, but e.g. if BSR is used and an
RP mapping is just about to change. Then you may get a join that
should get ignored due to wrong RP info, but shortly after, it
might be the right RP. An implementation could just change the
GENID, but it might be better to cache it. I think it is good to
point this out, but how exactly to implement it, or whether to
simply change the GENID is an implementation choice.

A router may not know whether it is temporary at first. But you
can cache it initially, and then figure out later what to do.

> • In section 4.3, in "Especially in the case where there is no need for n^2 connections on a network interface.", what is 'n'?

OK, I can say no need for a full mesh of connections.

> To ensure that there are only one connection between a pair of

Yes, better.

> • In section 5, "when sending over a stream protocol like Transport" ->  "when sending over a stream protocol like TCP/SCTP"

Yes

> • What is the use of defining instance-id and instance-type when we are setting it to zero and do not add any values for instance-type? What kind of role we see for such a field?

It may allow for new uses/extensions in the future. But how to use it
will need to standardized.

> • Can we add the size of instance-id in IPv6 header?

Will do.

> • Small type in section 6. 'non-ETP neighbor is interested' ->  'non-ET neighbor is interested'

Oops

> • In section 7, we have described how instance-id can be used. But will it not be better to add this support using a TLV rather than adding a filed in the header itself. This way, people can genera…

Maybe, but it would make the parsing more complex. Whatever the instance 
might identify, I
think 64 bits is likely to suffice.

> • Should instance-id type also falls under IANA?

Yes. So I guess it makes sense to point that out here, and that the type
requires and RFC.

Many thanks. Let me know if you have further concerns,

Stig

---

From: Bharat Joshi <[email-masked]>
Date: Thu, 16 Dec 2010 14:47:18 +0530

Hi Stig,

      Thanks for your reply. Please see my response in line. I have removed those comments where we both are in sync.

Regards,
Bharat

>        transport mechanism and the regular mechanism defined in

Yes. This is better.
 
> packets. This is in line with e.g. RFC 791.

I just checked RFC 791 again. This is fine.

> > Should we also mention that if a native join/prune message is received from a PORT enabled neighbor, it should simply be discarded.

Ok. So please add this text.

> up, also causes problems.

I am not sure if I follow this. In what conditions can a neighbor think that the connection is UP while the other still think that is not UP.

If a client immediately sends a join/prune message as soon as its local connection is declared UP, TCP on the other hand will get this message only after the ACK which would have brought the connection up in that neighbor as well. I am not sure if I am missing something here.
 
> "should" etc. in lower case.

Ok.
 
> by the upstream to tell which interface the J/P is for. Which is

So should we say any number rather than saying interface-id specifically? But provide a recommendation that 'interface-id' could be the most easily available number for such use.

> is worth it. Also for an SCTP only implementation it would make it a lot

I think SCTP able to figure out call collision is a good feature in our scenario. What I am trying to point out is that we will not have to even do this if we use TCP style connection establishment procedure. In any case, this will be available in any implementation so no extra check is required.
 
> neighbors would need to be maintained as now. E.g. with expiry

I think this will be good.
 
> paragraph above about changing GENID and resending all state.

But my point is that it is no where related to 'TCP connection maintenance'. May be we can create a new section for 'Changing GEN-ID' and move it there.

> simply change the GENID is an implementation choice.

I am still not convinced how a router can differentiate the two states (temporary or permanent). If it cache this information, next question is till what time it should be cached. Should the cache be updated by future messages? In what conditions this cache should be deleted?

> can cache it initially, and then figure out later what to do.

If you look at it from implementation perspective, it requires far more states to manage. So in one way, we are making it difficult for implementers.

> OK, I can say no need for a full mesh of connections.

Yeah. That is fine.

> will need to standardized.

In that case, why not allow someone to add more TLVs to a message rather than adding it in message.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 16 Dec 2010 10:42:51 -0800

> If a client immediately sends a join/prune message as soon as its local connection is declared UP, TCP on the other hand will get this message only after the ACK which would have brought the connec…

One example is if for some reason TCP is broken so that no TCP
packets pass. Then if say one router tries to send packets, it will
see the connection going down after reaching the retry limit. If the
other router does not try to send, it will not realize the connection
is broken. If you do some kind of keep-alives (or other sending), it
will still happen at different times.

But also when initiating a connection. What if the final ack of the
handshake is lost?

> So should we say any number rather than saying interface-id specifically? But provide a recommendation that 'interface-id' could be the most easily available number for such use.

OK, I can explain that it can be any value as long as it can be used
by the upstream to tell which interface a J/P is sent to. I think it
is fairly obvious though... I don't think it needs to be said, but
possible ways to implement this might be to use a random number,
some serial number, timestamp, or whatever the implementor prefers.
It might also be that an implementation has some kind of interface
ID that can be reused.

> I think SCTP able to figure out call collision is a good feature in our scenario. What I am trying to point out is that we will not have to even do this if we use TCP style connection establishment…

I guess you could try to do the same for SCTP as for TCP in an
implementation. The thing though is that there is no call collision in
SCTP, so it is fine for both to attempt it.

> But my point is that it is no where related to 'TCP connection maintenance'. May be we can create a new section for 'Changing GEN-ID' and move it there.

I agree it's not related. But I think it is OK. It is a bit
related to the paragraph above which is related to connection
maintenance. Creating a separate section just for this won't
necessarily increase the readability I think. I could maybe
change the section title a bit, not sure what.

> I am still not convinced how a router can differentiate the two states (temporary or permanent). If it cache this information, next question is till what time it should be cached. Should the cache…

You cannot. However, you can tell if an error is just there for a
short time or long time.

> If you look at it from implementation perspective, it requires far more states to manage. So in one way, we are making it difficult for implementers.

You don't need to implement this though. You can change the GENID
instead. The only thing I'm trying to do here, is to suggest that
this could be done as an optimization. Do you think it is better
to not mention this at all? Or do you have other suggestions for
how it could be achieved? I'm OK removing it too.

> In that case, why not allow someone to add more TLVs to a message rather than adding it in message.

We could do that. I'm fairly sure it is useful, but it is not clear
for now. The only cost now is a few extra bytes. If we use TLVs
to provide full flexibility, the cost is more complexity and more code.

I think it is worth considering though. Does anyone else have thoughts
on this?

Stig

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 17 Dec 2010 14:21:24 +0530

Few replies in line.

Thanks,
Bharat

> But also when initiating a connection. What if the final ack of the

We are discussing on why there could be an issue with the TCP connection. But my question was why not allow native join/prune till the connection is completely established?

This will be helpful in the cases you mentioned above where TCP session could not be established for some unknown reasons.

> It might also be that an implementation has some kind of interface

Yes. That's what I was looking at. It is better to left this to implementations.

> implementation. 

So we are not restricting it (TCP style connection establishment for SCTP) in the draft. Right?

> The thing though is that there is no call collision in

Did you mean 'TCP' in the above sentence?

I think that it is better to keep this same for both TCP/SCTP.

> change the section title a bit, not sure what.

See below.
 
> You cannot. However, you can tell if an error is just there for a

But to tell whether an error is there for short or long time, it will have to maintain some states. Now it will be difficult to manage this state for just what we are suggesting here. Please see below.
 
> how it could be achieved? I'm OK removing it too.

I think it is better not to mention this. Let the implementation take care of figuring it out. I would suggest to remove this completely.

> I think it is worth considering though. Does anyone else have thoughts

The only issue I see with this approach is that there is no guarantee whether 64 bits will be enough for all cases. Also whether the 4 bits reserved for identifying instance-id type is enough or not.

So if we do not know for sure, I would suggest to remove this for now and let someone who has more clarity and know the exact use case, create exactly what he wants.

---

From: Stig Venaas <[email-masked]>
Date: Fri, 17 Dec 2010 15:42:31 -0800

> We are discussing on why there could be an issue with the TCP connection. But my question was why not allow native join/prune till the connection is completely established?

One router may e.g. send datagrams J/Ps while the other is ignoring
them because it believes the connection is up. You could try to accept
but, but that can be dangerous. I'm trying to remember some example I
had.

If you configure PORT you should make sure that TCP works. Operationally
I think it's best to configure what you want and make sure that works.
And not trying to do it dynamically. Predictability is good. An
implementation could perhaps stop announcing PORT if TCP fails
repeatedly.

> So we are not restricting it (TCP style connection establishment for SCTP) in the draft. Right?

For SCTP I don't want to restrict who connects to whom, there is no
need.
> Did you mean 'TCP' in the above sentence?

No. My understanding is that with SCTP there is no call collision.
If both try to open connections simultaneously, it will end up
being the same connection.

> I think that it is better to keep this same for both TCP/SCTP.

Implementations should IMO take benefit of the improvements of
SCTP. We shouldn't require them to behave as badly or complicated
as with TCP.

I suppose in your implementation, it will still work if you choose
to do it the TCP way for SCTP. But there is no need.

> But to tell whether an error is there for short or long time, it will have to maintain some states. Now it will be difficult to manage this state for just what we are suggesting here. Please see be…

It could be for instance how long some "ignored" J/P has been cached.

> I think it is better not to mention this. Let the implementation take care of figuring it out. I would suggest to remove this completely.

OK, I'm fine with that.

> The only issue I see with this approach is that there is no guarantee whether 64 bits will be enough for all cases. Also whether the 4 bits reserved for identifying instance-id type is enough or no…

Yes. TLV would certainly allow for more flexibility.

My proposal would then be to change the PORT message as follows:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Type = 1             |        Length = X + 16        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        Reserved               |      Exp      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                         Interface ID                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    PORT Option Type           |           Length              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             Value                             |
        |                               .                               |
        |                               .                               |
        |                               .                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        \                               .                               \
        /                               .                               /
        \                               .                               \
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    PORT Option Type           |           Length              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             Value                             |
        |                               .                               |
        |                               .                               |
        |                               .                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where Type 0 is for the PIMv2 Join/Prune Message.

I think we should say MUST exactly 1 of type 0. In addition there
may in the future be new options. We probably don't need to enforce
any alignment.

Does that seem better? We could not use TLVs for the PIMv2 J/P itself,
but then we would need an additional length field.

Stig

---

From: Bharat Joshi <[email-masked]>
Date: Sat, 18 Dec 2010 18:47:20 +0530

Please see in line.

Thanks,
Bharat

> but, but that can be dangerous. I'm trying to remember some example I

I would like to know those examples where you think it can create issues.

Also it depends when a router start discarding J/P messages from downstream router. It is done as soon as the connection is declared UP or it start receiving J/P messages on that connection. [Similar to how traffic is moved from *,G to S,G]. I do not see any issue if the router start discarding native/datagram J/P messages, only when it start receiving J/P messages on the TCP connection. Also it should keep discarding till this TCP connection is UP.
 
> implementation could perhaps stop announcing PORT if TCP fails

What I am trying to suggest is a fail-over mechanism for TCP here. If there is a problem in TCP, keep using native J/P. If TCP works, stop using native J/P. If TCP connection goes down, may be start using native J/P.

We will need to also look at how the downstream router will behave. When connection is being established, we will have to allow him to use native J/P.

> to do it the TCP way for SCTP. But there is no need.

Ok. I think then implementation may decide how and what they want to do with SCTP?

> My proposal would then be to change the PORT message as follows:

I think this will allow someone in future to create another type and use that here in TLV format specific for a given J/P. Right?

So we won't be defining a type for instance-id now. Right?

Do we need to put PORT option type also in IANA?

> may in the future be new options. We probably don't need to enforce

Yes. I agree that PORT option type with value 0 MUST appear in a message and MUST appear only once.

> but then we would need an additional length field.

I did not get what you mean by above?