Subject: [pim] PORT and Datagram PIM

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sun, 6 Feb 2011 23:33:37 +0530

Hi,

I am new to PIM list and apologies in advance if this has already been discussed on the list before. 

I don't think I understand the reason why an operator would want to transition to the datagram mode when two routers are advertising the PORT capability in their PIM Hellos. If they want to revert to the datagram mode then it should be configured though the CLI and routers should stop advertising this capability in their Hellos.

I would also like to understand the reason why we don't think we should add a PIM Keepalive message for PORT. I don't think depending upon TCP Keepalive is a great idea. Most protocols over TCP (BGP, LDP, etc) done use it - why should we?

Cheers, Manav

---

From: Stig Venaas <[email-masked]>
Date: Mon, 07 Feb 2011 10:30:51 -0800

> I don't think I understand the reason why an operator would want to transition to the datagram mode when two routers are advertising the PORT capability in their PIM Hellos. If they want to revert…

Yes, I agree with you on this point. This is also what the
draft says.

> I would also like to understand the reason why we don't think we should add a PIM Keepalive message for PORT. I don't think depending upon TCP Keepalive is a great idea. Most protocols over TCP (BG…

This may indeed be useful, although it is not entirely clear
to me that we need it. I would welcome more discussion on
this. Also if you have arguments for doing PORT keepalive
rather than TCP keepalive.

My thinking has so far been that it may be a good idea, but:

We can add this option later if it becomes clear that is is
needed.

Or, one can do something like a keepalive by sending say
an empty J/P message, if there are more than a certain time
since the last sent J/P. By empty J/P message I mean that the
included PIM J/P message has no groups in it.

Note that there are also some that think enforcing keepalive
is bad. So it should at most be an option. One nice thing is
that each router can independently support it, it's not like
both the peers need to.

Stig

> Cheers, Manav
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 8 Feb 2011 05:57:37 +0530

Hi Stig,
 
> > I don't think I understand the reason why an operator would 
> want to transition to the datagram mode when two routers are 
> advertising the PORT capability in their PIM Hellos. If they 
> want to revert to the datagram mode then it should be 
> configured though the CLI and routers should stop advertising 
> this capability in their Hellos.
> 

I am confused because of all this discussion about reverting to the datagram mode when TCP fails, etc. I think if the routers have been configured to use PORT then they MUST not try attempting sending native PIM Join/Prune messages ever.

> 
> > I would also like to understand the reason why we don't 
> think we should add a PIM Keepalive message for PORT. I don't 
> think depending upon TCP Keepalive is a great idea. Most 
> protocols over TCP (BGP, LDP, etc) done use it - why should we?
> 

Its well known that there can be false negatives with TCP keepalive which is why its use is discouraged. I am presuming that most TCP implementations provide support for Keepalives - could there be some that don't? I am quite sure that any router that wants to do PIM would have a TCP implementation that supports this, however just bringing it up as a point to keep in mind. 

PIM will always be turned on links which also have OSPF/IS-IS running. There is thus a very good chance that BFD [RFC5882] would be running there as well. Given this, all we need to do is to ensure that PIM also registers with BFD and gets notified when two nodes loose IP connectivity. This would also give you a failover time in O(ms), something that we can never achieve with TCP keepalives.

Now, the above can only be done if we have PORT keepalives, as the operator can turn off the PORT keepalives if there is BFD or some other liveliness protocol (EFM (IEEE 802.3ah) for example) running between the PIM neighbors. Only when no such protocol is running can the operator turn on PORT keepalives.

However, if the WG does decide to go ahead with PORT keepalives then there MUST be a provision to communicate this value to the other PORT neighbor, so that both sides send PORT keepalives well within this interval.

> included PIM J/P message has no groups in it.

Yup this should work. Additionally, receiving any valid PIM prune/join message from a peer is an implicit acknowledgement of that peer being alive.

> that each router can independently support it, it's not like

Generally you turn on keepalives on both sides. I cant envisage a scenario where only one side would be interested in knowing the liveliness of the other peer.

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 9 Feb 2011 05:02:06 +0530

Hi Stig,

> Yes, I agree with you on this point. This is also what the

In that case we must remove the following line from Sec 3.1:

When the router cannot setup a TCP connection, it will refrain from including this option.

I don't think implementations should automatically revert to the datagram mode. The above statement actually causes more problems than without being there. Since there is no guidance on when implementations should refrain from including this option we can easily get into interoperability problems where A and B are trying to establish a TCP connection but are unable to do so. A, based on the above text decides to send PIM Hellos with the PORT capability, while B still continues to send Hellos including this capability. B may never stop doing this since the RFC says that PORT capable routers MUST always send this capability.

This brings another aspect that I don't think is covered in the current text.

What should A do if it is PORT capable and it receives Hello messages without this capability. Should it downgrade and not include this capability in the subsequent Hellos? I think we should include some text discussing this as well.

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 9 Feb 2011 05:03:58 +0530

> option we can easily get into interoperability problems where 
> A and B are trying to establish a TCP connection but are 
> unable to do so. A, based on the above text decides to send 
> PIM Hellos with the PORT capability, while B still continues 

It's a typo here - I mean A sends PIM Hellos *without* the PORT capability.

Cheers, Manav

---

From: Stig Venaas <[email-masked]>
Date: Wed, 09 Feb 2011 10:05:58 -0800

> When the router cannot setup a TCP connection, it will refrain from including this option.

Agree.

> What should A do if it is PORT capable and it receives Hello messages without this capability. Should it downgrade and not include this capability in the subsequent Hellos? I think we should includ…

I think this is covered by the current text. It says:

    Once PORT is enabled on an interface and a PIM neighbor also
    announces that it is PORT enabled, only PORT Join/Prune messages will
    be used.  That is, only PORT Join/Prune messages are accepted from,
    and sent to, that particular neighbor.  Native Join/Prune messages
    may still be used for other neighbors.

Which means as soon as one neighbor stops being PORT enabled, you
revert to native. Perhaps it could be made clearer. Perhaps it
helps changing the last sentence to say that "Native Join/Prune
messages are still used for PIM neighbors that are not PORT
enabled".

In the introduction it says:

Two routers that are PIM neighbors on a link will always use Transport
mode if and only if both have Transport mode enabled.

Note that in the latest version I am changing the terms a bit as
Transport mode is not defined.

Stig

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 9 Feb 2011 23:38:39 +0530

> messages are still used for PIM neighbors that are not PORT

Yup, this sounds much better.

Manav