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

From: Stig Venaas <[email-masked]>
Date: Tue, 01 Mar 2011 15:25:13 -0800

Hi, thanks for the detailed review. See inline.

On 2/27/2011 9:16 PM, Bharat Joshi wrote:
> Hi Stig,
>
>      I finally managed to squeeze some time to look at the updated draft. I have got some more questions on this below:
>
> Regards,
> Bharat
>
> • You may want to add 'mechanism' in the following sentence: "if and only if both have reliable transport enabled." ->  "if and only if both have reliable transport mechanism enabled.

Done

> • Can we just use the full-form when an acronyms used first time? I am sure it will be asked when IESG review happens. For example: RPF neighbor. Another useful thing would be to add such acronyms in terminology or a reference to other RFC.

Done I think. Referring to 4601 for RPF neighbor and GenID. Also
expanded the latter on first occurrence.

> • In section 3.1, section number is missing in:
>
> 'All Hello messages containing the PIM-over-TCP Capable hello option,   MUST also contain the Interface ID hello option, see section ."

Fixed

> • In section 3.1, should we use 'It is RECOMMENDED that' instead of "We RECOMMEND that".
>
> • The above two issues in section 3.2 as well.

Fixed both everywhere.

> • In section 4, the paragraph starting with "It is possible that a router starts" interchangeably uses ID or IDs. We start describing things in ID but later start using IDs. Can we keep this consistent?

The difference is whether I'm talking about a single ID, or multiple
IDs. There is no difference in terminology and they are not
interchangeable. I did change the text to talk about how a connection
is identifed by a pair of IDs (the local and remote connection ID), and
tried to talk about the connection ID pair changing etc.

Here is the new text. Let me know if OK.

It is possible that a router starts sending Hello messages
with a new Connection ID, e.g. due to configuration changes.
One MUST always use the last announced and last seen Connection
IDs. A connection is identified by the local Connection ID (the
one we are announcing on a particular interface), and the remote
Connection ID (the one we are receiving from a neighbor on the
same interface). When either the local or remote ID changes, the
Connection ID pair we need a connection for changes. There may
be an existing connection with the same pair, in which case we
will share that connection. Or a new connection may need to be
established. Note that for link-local addresses, the interface
should be regarded as part of the ID, so that connection sharing
is not attempted when the same link-local addresses are seen on
different interfaces.

When a Connection ID changes, if the previously used connection
is not needed (there are no other PIM neighborships using the
same Connection ID pair), both peers MUST attempt a graceful
shutdown of the connection. Next (even if the old connection is
still needed), they MUST, unless a connection already exists with
the new Connection ID pair, immediately or on-demand attempt to
establish a new connection with the new Connection ID pair.

> • In section 4, it is described that a full-table update happens when connection is established and any state received during datagram is left to expire. Can we be explicit on what to do with timer of each group for which the update has been received? I think we need to stop that timer when we move from datagram to PORT mode and for which the update has been received. Right?

Yes, except you may need to leave the timer running if there also
are non-PORT neighbors. The main thing is that the state should not
go away. E.g. you may leave the timer running, but when it expires,
check if you got PORT state, and in that case not remove it. I think
this is covered by the following text in section 4:

When moving from Datagram mode, or when the connection has gone down,
the router cannot be sure that all the previous Join/Prune state was
received by the neighbor.  Any state received while in Datagram mode
that is not refreshed, will be left to expire.

> • In section 4, also, do we start the timer for each state if the PORT connection goes down? What do we do with this timer when the connection is reestablished and an update is received. So in affect, the same functionality as asked in the previous question

You may start a timer for each state, but you may also get away with a
single timer. You just need to ensure the following behavior described
near the end of 4.3:

The neighbors MUST also start expiry timers so that
all oif-list state for the neighbor using the connection, gets
expired after JP_HOLDTIME, unless it later gets refreshed by
receiving new Join/Prunes.

Here you can maybe have a single timer associated with the
connection, provided you somehow now which ones got refreshed
when that timer triggers. The easiest might be to have a timer
for each state.

> • Small typo "One can quicker detect that" ->  "One can quickly detect that"

Fixed

> • Small typo in "since the the previous"

Fixed

> • In section 4.2, most of the test in para 2 and 3 are repetitive. Can we cut down to keep it more straight forward?

I trimmed down the second a bit. First one is mostly unchanged, talking
about how sending PORT messages can be used to detect when a connection
is not working, and how keep-alives can be used for that.

The other paragraph talks about how the use of holdtime can allow even
quicker detection by checking whether messages are received often enough.

The two are separate because you can choose to only do the former.

> • In para 2 of section 4.2,  draft says 'We RECOMMEND	this to be optional" and in para 4, it says 'Implementations SHOULD support Keep-Alive messages'.

I now say that it should be a configuration option. Point is that it
SHOULD be supported, but it is RECOMMENDED that there is a configuration
option. The administrator should be able to choose.

> • In following text:
>
> It is possible that a router receives Join/Prune messages for an interface/link that is down. As long as the neighbor has not expired, we RECOMMEND processing those messages as usual.

It is possible that a link stops working for a while and later
recovers without the neighbor expiring. Since connections can use
e.g. loopback addresses, the connection may be working, allowing
J/Ps to be sent while the link is down.

> I am not sure how the hello timer is still running if the interface is down. Also how this message has come in, if the link itself is down? (I am assuming that the link here means the port).
>
> • In last para of section 4.2, in following text:
>
> However, if  the connection is shared by multiple interfaces and the GenID changes only for one of them, then there was not a full restart, and one may simply send a full update similar to other cases when a GenID changes for an upstream neighbor.
>
> Can we change this to:
>
> However, if  the connection is shared by multiple interfaces and the GenID changes only for one of them, PORT neighbor SHOULD simply send a full update similar to other cases when a GenID changes for an upstream neighbor.

I don't want to say PORT neighbor, since we are talking about the
neighbor sending with a new GENID, and it is we that must take
action, not the neighbor. Just before this I'm talking about the
"local side" taking action. I changed this to use "local side" as
well.

> • "no more PIM neighborships using it" ->  "no more PIM neighbors using it"

I want to use the term neighborship here. We are not talking about a
neighbors using a connection. It is rather a neighborship. Adjacency if
you like. On an interface where we send Hello's, we form a neighborship
with some PIM neighbor. It's the two of us together that uses a
particular connection. Re Connection ID pair earlier.

> • Small typo in "rules for connestion"

Fixed

> • J/P_HoldTime ->  JP_HoldTime

Fixed

> • Typo "message message format"

Fixed

> • "Each PORT message will have the below Type/Length/Value format" ->  "Each PORT message will have the Type/Length/Value format"

Fixed

> • In section 5, can we change the following text:
>
>   If any parsing errors occur in a Join/Prune message, it is skipped, and we proceed processing any following PORT messages.
>
> to
>
>   If any parsing errors occur in a PORT message, it is skipped, and we proceed to any following PORT messages.

Fixed

> • In section 5.1, in following text:
>
> As can be seen from the packet format diagram, multiple Join/Prune messages can go into one TCP/SCTP stream from the same or different Interface IDs.
>
> How is it possible to use different interface-id in the same message? Interface-id is not repeating in the message after each Option buffer.

Removed this, added a sentence to where we talk about the Interface-ID
field. Point is that different PORT Join/Prune messages on the same
connection can have different Interface IDs.

> • The message length calculation is using '4*n', is this for interface-id? If so then the figure needs to be updated to show interface-id before next PORT option type.

No, it's just that each option has 2 bytes type, 2 bytes length, and
then the value of the given length. So if the option length is L, we
need 4 + L bytes. Isn't this obvious? I write:

If n PORT Options with Option Value lengths L1, L2, ..., Ln are
included, the message length will be
12 + 4*n + L1 + L2 + ... + Ln.

So you see that per option, there is a fixed overhead of 4.

> • Small typo in "are not sent of the desired frequency".

What is wrong?

> • I was thinking that keep-alive message will just have a hold-time value but it seems to bee have PORT Option type as well. The reason of generating keep-alive message was that we do not have any PORT messages to send so what will we fill in PORT Option type in keep-alive message.

I'm thinking that all PORT messages should allow options to be
included to allow for future extensions. Currently we don't have
any options for keep-alives though.

> • In keep-alive message, can we correct the calculation of message length? It uses 4*n in the calculation which I think is not correct. Also why it uses 6 as the starting length, should not this be 8.

See above regarding the 4*n.

> • Should we define mux/demux term somewhere? Can it be interpreted in the right context?

I think it is fine.

> • Should not we register the new hello option 'TCP-Capable' with IANA?

Yes. The draft has some text on this, but I'm now adding the following
new section:

10.1 PORT Hello Options

In the Protocol Independent Multicast (PIM) Hello Options
registry, the following options are needed for PORT.

  Value    Length      Name                    Reference
-------  ----------  -----------------------  ---------------
  27       Variable    PIM-over-TCP Capable     this document
  28       Variable    PIM-over-SCTP Capable    this document

What do you think?

Stig

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

---

From: Bharat Joshi <[email-masked]>
Date: Wed, 2 Mar 2011 13:51:55 +0530

Hi Stig,

    My replies in line. I have removed those where we have reached a consensus.

Thanks,
Bharat

> > * Can we just use the full-form when an acronyms used first time? I
> am sure it will be asked when IESG review happens. For example: RPF
> neighbor. Another useful thing would be to add such acronyms in
> terminology or a reference to other RFC.
> 

Yes. That should be good enough.
 
> > * In section 4, the paragraph starting with "It is possible that a
> router starts" interchangeably uses ID or IDs. We start describing
> things in ID but later start using IDs. Can we keep this consistent?
> 

Looks better.

> > * In section 4, it is described that a full-table update happens when
> connection is established and any state received during datagram is
> left to expire. Can we be explicit on what to do with timer of each
> group for which the update has been received? I think we need to stop
> that timer when we move from datagram to PORT mode and for which the
> update has been received. Right?
> 

Yes. This takes care of moving from datagram mode to PORT mode. But what I was trying to point out is that when PORT connection goes down, we start a expiry timer for each group but what to do when the PORT connection comes back. Should not we stop these timers?

As you mentioned above, I think we need some text indicating that when a timer fires and if the group was learned using PORT connection, we do not do anything and just keep the group as it is.

> > * In section 4, also, do we start the timer for each state if the
> PORT connection goes down? What do we do with this timer when the
> connection is reestablished and an update is received. So in affect,
> the same functionality as asked in the previous question
> 

Ok.

> > * In section 4.2, most of the test in para 2 and 3 are repetitive.
> Can we cut down to keep it more straight forward?
> 

Ok. Will look at it once you update the draft.
 
> > * In para 2 of section 4.2,  draft says 'We RECOMMEND	this to be
> optional" and in para 4, it says 'Implementations SHOULD support Keep-
> Alive messages'.
> 

Ok. I agree that it is better to provide a configuration option. May be we can add some text pointing the same.

> > * In following text:
> >
> > It is possible that a router receives Join/Prune messages for an
> interface/link that is down. As long as the neighbor has not expired,
> we RECOMMEND processing those messages as usual.
> 

Ok.

> > I am not sure how the hello timer is still running if the interface
> is down. Also how this message has come in, if the link itself is down?
> (I am assuming that the link here means the port).
> >
> > * In last para of section 4.2, in following text:
> >
> > However, if  the connection is shared by multiple interfaces and the
> GenID changes only for one of them, then there was not a full restart,
> and one may simply send a full update similar to other cases when a
> GenID changes for an upstream neighbor.
> >
> > Can we change this to:
> >
> > However, if  the connection is shared by multiple interfaces and the
> GenID changes only for one of them, PORT neighbor SHOULD simply send a
> full update similar to other cases when a GenID changes for an upstream
> neighbor.
> 

Actually in the same Para, we have used PORT neighbor and so I suggested this change.

> > * "no more PIM neighborships using it" ->  "no more PIM neighbors
> using it"
> 

May be term adjacency is better.
 
> > * In section 5.1, in following text:
> >
> > As can be seen from the packet format diagram, multiple Join/Prune
> messages can go into one TCP/SCTP stream from the same or different
> Interface IDs.
> >
> > How is it possible to use different interface-id in the same message?
> Interface-id is not repeating in the message after each Option buffer.
> 

Ok. Yes. I agree that different J/P message can have different interface Id.

> > * The message length calculation is using '4*n', is this for
> interface-id? If so then the figure needs to be updated to show
> interface-id before next PORT option type.
> 

Actually I was confused because of the statement because of the above comment regarding interface-id. I assumed that we want to repeat interface-id for each Port Option and so assumed that the 4 bytes are for that.
 
> So you see that per option, there is a fixed overhead of 4.

Yes. I understand this now.

> > * Small typo in "are not sent of the desired frequency".
> 
> What is wrong?

When I read this statement again, I think we should change it as follows:

   The PORT Keep-alive Message is used to regularly send PORT messages
   to verify that a connection is alive.  They are used when other PORT
   messages are not sent of the desired frequency.

To

   The PORT Keep-alive Message is used to regularly send PORT messages
   to verify that a connection is alive.  They are used when other PORT
   messages are not sent at the desired frequency.

> > * I was thinking that keep-alive message will just have a hold-time
> value but it seems to bee have PORT Option type as well. The reason of
> generating keep-alive message was that we do not have any PORT messages
> to send so what will we fill in PORT Option type in keep-alive message.
> 

Though I may agree from the extensible purposes but typically keep-alive messages are simple keep-alive message. They normally do not carry any other protocol information so I think we should think a little more before adding this.

Also, I think, if it is really required, we can add this in future as well.

> > * In keep-alive message, can we correct the calculation of message
> length? It uses 4*n in the calculation which I think is not correct.
> Also why it uses 6 as the starting length, should not this be 8.
> 

What about value of 6 in calculation. Should not that be 8?

> > * Should not we register the new hello option 'TCP-Capable' with
> IANA?
> 

Yes. I think this is better.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 02 Mar 2011 10:44:01 -0800

>      My replies in line. I have removed those where we have reached a consensus.

Great, I'm removing some stuff as well, and see inline for the rest.

> As you mentioned above, I think we need some text indicating that when a timer fires and if the group was learned using PORT connection, we do not do anything and just keep the group as it is.

How about changing that paragraph to:

    When moving from Datagram mode, or when the connection has gone down,
    the router cannot be sure that all the previous Join/Prune state was
    received by the neighbor.  Any state created before the connection
    was established (or reestablished) that is not refreshed, MUST be
    left to expire.  When the non-refreshed state has expired, the two
    neighbors will be in sync.

It is not important how exactly this is achieved. As I said, it could
be by stopping timers for each state that has been refreshed, or leave
the timer running, but somehow have a flag marking it as refreshed. Or
there could be other ways.

> Ok. I agree that it is better to provide a configuration option. May be we can add some text pointing the same.

The new text is:

    Implementations SHOULD support the use of PORT Keep-Alive
    messages. It is RECOMMENDED that it is a configuration option,
    allowing network administrators to enable it as needed.

> May be term adjacency is better.

OK, with the additional text I have, maybe I can say "PIM neighbor using
it". I think in a way it is less precise, but maybe also less confusing?
The new text is then:

    A connection may go down for a variety of reasons. It may
    be due to an error condition, or a configuration change.
    A connection SHOULD be shut down as soon as there are
    no more PIM neighbors using it. That is, for the connection
    we have associated local and remote Connection IDs. When there
    is no PIM neighbor with that particular remote connection ID on
    any interface where we announce the local connection ID, the
    connection SHOULD be shut down. This may happen when a new
    connection ID is configured, PORT is disabled, or a PIM neighbor
    expires.

>     messages are not sent at the desired frequency.

Oh right, "at" does seem more correct.

> Also, I think, if it is really required, we can add this in future as well.

Currently there are no options defined for use with keep-alive.
This means current implementations can safely ignore all this
stuff and only check the holdtime. I'm adding that unknown options
MUST be ignored. This means that unless options are defined later,
the messages look like you want, and the processing/implementation
is also like you want. If options for some reasons are defined later,
then current implementations will still do the right thing. You would
only need to update the implementation and check options if you want
to support them.

So I think we have the extensibility we want, and keeping the
parsing simple.

> What about value of 6 in calculation. Should not that be 8?

If you look at the diagram you see that the fixed part before the
options have length 6. 4 bytes for "Reserved and Exp" and 2 bytes
for "Holdtime". I'm intentionally leaving the "Reserved and Exp"
the same for the two messages, so that one more easily can define
flags common to all PORT messages if wanted later.

Stig

---

From: Bharat Joshi <[email-masked]>
Date: Thu, 3 Mar 2011 22:24:57 +0530

Hi Stig,

     My replies in line.

Thanks,
Bharat

> there could be other ways.

Yes. I agree that we need not say exactly how implementation will take care of it.

I just wanted to see some text which clearly says what happens to the timer started or the state for which the timer was started, when the connection is re-established. I think the suggested text also does not clearly says it. I am not sure if this is correct but how about:

     When moving from Datagram mode, or when the connection has gone down,
     the router cannot be sure that all the previous Join/Prune state was
     received by the neighbor.  Any state created before the connection
     was established (or reestablished) that is not refreshed, MUST be
     left to expire.  A J/P state that has expired is removed if it was learned
     in datagram mode. A J/P state that has expired is kept as it is if it was
     learned in PORT mode. When all the non-refreshed states have expired, the 
     two neighbors will be in sync.

>     allowing network administrators to enable it as needed.

Looks good to me. Just a little reword:

     Implementations SHOULD support the use of PORT Keep-Alive
     messages. It is RECOMMENDED that a configuration option is
     available to network administrators to enable it when needed.
 
> > Actually in the same Para, we have used PORT neighbor and so I suggested this change.

You missed the above one.

>     connection ID is configured, PORT is disabled, or a PIM neighbor

Looks good to me.

> So I think we have the extensibility we want, and keeping the

Actually what I was thinking is that a keep-alive message is generated when Port messages are not sent for a specific period. Now if a client has Port option to add in keep-alive message, why it needs to send keep-alive at all. Why not send Port message itself?

> flags common to all PORT messages if wanted later.

Ok. My mistake. I had been assuming that it is total length of this header rather than just the payload.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 03 Mar 2011 14:19:13 -0800

>       two neighbors will be in sync.

No. How about just adding a couple of words after expire:

    When moving from Datagram mode, or when the connection has gone down,
    the router cannot be sure that all the previous Join/Prune state was
    received by the neighbor.  Any state created before the connection
    was established (or reestablished) that is not refreshed, MUST be
    left to expire and be deleted.  When the non-refreshed state has
    expired and been deleted, the two neighbors will be in sync.

All state from before the connection came up should be deleted if not
refreshed. Independent of whether it was datagram or PORT state.

>       available to network administrators to enable it when needed.

OK, using your text.

> You missed the above one.

Not sure what I missed here.

> Actually what I was thinking is that a keep-alive message is generated when Port messages are not sent for a specific period. Now if a client has Port option to add in keep-alive message, why it ne…

Right, so if we were to define options for use in a keep-alive, it would
be something specific to keep-alive. It wouldn't make sense to put say a
PIM J/P in a keep-alive.

I'm not sure if I have any good examples now, but "holdtime" could have
been an option, except I chose to make it fixed. Possible use for
options in holdtime would perhaps be to say what action should be taken
when holdtime expires. I'm just speculating here. Main thing is that
allowing options causes no extra work unless we define options. If it is
not needed, then we never define options. If we actually find a need for
an option in the future, then we are lucky we designed it this way.

I think I'm pretty close to submitting yet another version now. I'll
probably submit one on Friday. If you have further comments on the above
by then I will try to accommodate them. If not, I can always do yet
another version.

My hope now is to do another wglc soon after Prague. Hopefully the last
one...

Thanks,

Stig

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 4 Mar 2011 21:56:27 +0530

Hi Stig,

> refreshed. Independent of whether it was datagram or PORT state.

Looks ok.

> Not sure what I missed here.

What I was trying to suggest here is to replace J/P neighbor with PORT neighbor.
 
> My hope now is to do another wglc soon after Prague. Hopefully the last

Does it mean that we will use a different PIM Port Keep-alive options which will be added when required? If so then it might be fine.

But if we are thinking of reusing Port Options here then I would suggest, we should not do this.

Regards,
Bharat

---

From: Stig Venaas <[email-masked]>
Date: Fri, 04 Mar 2011 10:29:46 -0800

On 3/4/2011 8:26 AM, Bharat Joshi wrote:
[...]
> Does it mean that we will use a different PIM Port Keep-alive options which will be added when required? If so then it might be fine.

Yes

> But if we are thinking of reusing Port Options here then I would suggest, we should not do this.

I suggest we use a single option space for all PORT messages, but when
defining options, we should also say which PORT messages they can be
used with. E.g. now we have the PIM J/P Option, and it is only defined
to be used in a PORT J/P message.

I'll submit a new version in a few hours then. Thanks for your input,
I'll try to address the one remainig point regarding JP neighbor.

Stig