Re: Some questions and suggestions on PIM-PORT draft

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

Re: Some questions and suggestions on PIM-PORT draft

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.
> 
> Done I think. Referring to 4601 for RPF neighbor and GenID. Also
> expanded the latter on first occurrence.

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

Re: Some questions and suggestions on PIM-PORT draft

On 3/2/2011 12:21 AM, Bharat Joshi wrote:
> Hi Stig,
>
>      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.

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

Re: Some questions and suggestions on PIM-PORT draft

Hi Stig,

     My replies in line.

Thanks,
Bharat

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

Re: Some questions and suggestions on PIM-PORT draft

On 3/3/2011 8:54 AM, Bharat Joshi wrote:
> Hi Stig,
>
>       My replies in line.
>
> Thanks,
> Bharat
>
>>>>> * 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.
>>>
>>> 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?
>>>

Re: Some questions and suggestions on PIM-PORT draft

Hi Stig,

> >>>>> * 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.
> >>>
> >>> 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.
> >>
> >> How about changing that paragraph to:
> >>
> >>      When moving from Datagram mode, or when the connection has gone down,

Re: Some questions and suggestions on PIM-PORT draft

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

> Regards,
> Bharat
> **************** 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

I-D Action:draft-ietf-pim-port-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Protocol Independent Multicast Working Group of the IETF.

	Title           : A Reliable Transport Mechanism for PIM
	Author(s)       : D. Farinacci, et al.
	Filename        : draft-ietf-pim-port-06.txt
	Pages           : 33
	Date            : 2011-03-04

This draft describes how a reliable transport mechanism can be used
by the PIM protocol to optimize CPU and bandwidth resource
utilization by eliminating periodic Join/Prune message transmission.
This draft proposes a modular extension to PIM to use either the TCP
or SCTP transport protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pim-port-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
pim mailing list
pim <at> ietf.org

Re-introducing MSNIP (Fwd: New Version Notification for draft-ietf-magma-msnip-06)

Hi, I have just submitted this draft which I think is a solution to
the first-hop multicast flooding problem we discussed last meeting.
See draft-dizhou-pim-umf-problem-statement-01 for problem statement.

MSNIP has been a wg draft for the magma wg which is gone by now.
It allows for hosts to register as sources and be notified when
there are receivers. MSNIP was designed for SSM.

The main problem with ASM is how the first-hop router can know if
there are receivers. This is a problem both for MSNIP and other
solutions trying to avoid first-hop multicast flooding. See
Appendix A for how this may be solved, allowing MSNIP to be extended
to ASM.

The one thing that distinguishes MSNIP from other proposals
regarding first-hop flooding, is that the host is involved.
This has some benefits in that the application can learn when
it should send. This is particularly useful if resources are
needed for encoding etc. Also, e.g. a camera need only be
turned on when there are receivers. It also helps us avoid
PIM data registers, we can have the RP join towards the first-hop
router and have the tree in place before the source tries to send.

Comments welcome,

Stig

-------- Original Message --------
Subject: New Version Notification for draft-ietf-magma-msnip-06
Date: Fri,  4 Mar 2011 13:01:26 -0800 (PST)

Call for Prague agenda items

If you would like a slot to present at the pim wg meeting in
Prague, please let Mike and I know.

We will be publishing a draft agenda shortly,

Stig