From pusateri@juniper.net Mon Dec 6 23:47:41 2004 Received: from colo-dns-ext2.juniper.net (colo-dns-ext2.juniper.net [207.17.137.64]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id iB74lf2P013105 for ; Mon, 6 Dec 2004 23:47:41 -0500 (EST) (envelope-from pusateri@juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id iB74laBm081634 for ; Mon, 6 Dec 2004 20:47:36 -0800 (PST) (envelope-from pusateri@juniper.net) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id iB74lZe66662 for ; Mon, 6 Dec 2004 20:47:36 -0800 (PST) (envelope-from pusateri@juniper.net) Message-Id: <200412070447.iB74lZe66662@merlot.juniper.net> To: pim-state@mountain2sea.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <33978.1102394855.1@juniper.net> Date: Mon, 06 Dec 2004 20:47:35 -0800 From: Tom Pusateri Cc: Subject: [Pim-state] PIM State Refresh Reduction X-BeenThere: pim-state@www.mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 07 Dec 2004 04:47:42 -0000 You have been subscribed to this new mailing list because you specifically ask me or Mike to be involved in this work. To send mail to the mailing list, use pim-state@mountain2sea.com. You must send it from the email address that you are subscribed with. You can see the archives or see the other members by loggin in at: http://www.mountain2sea.com/mailman/listinfo/pim-state The first order of business to clearly state the problem we're trying to solve. Several of you have done work in this area already and have text to contribute. However, before we start putting a draft together, I want to make sure we have outlined the problem, and agree on the more general goals of the solution. I'll be sending in the requirements I know of shortly but feel free to describe the problem as you see it to the list and we'll sum it up into a problem statement. Thanks, Tom From suresh.boddapati@alcatel.com Wed Dec 8 16:52:14 2004 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id iB8LqDaM023044 for ; Wed, 8 Dec 2004 16:52:13 -0500 (EST) (envelope-from suresh.boddapati@alcatel.com) Received: from alcatelxp ([172.22.187.74] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Dec 2004 13:52:04 -0800 From: "Suresh Boddapati" To: Date: Wed, 8 Dec 2004 13:50:12 -0800 Organization: Alcatel USA Message-ID: <026a01c4dd6f$e6296f40$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_026B_01C4DD2C.D8062F40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 08 Dec 2004 21:52:04.0265 (UTC) FILETIME=[278A0990:01C4DD70] Subject: [Pim-state] (no subject) X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: suresh.boddapati@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 08 Dec 2004 21:52:14 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_026B_01C4DD2C.D8062F40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, To get the ball rolling, I have taken a stab at defining the problem. I have expanded the scope a bit to include reliability in the protocol. I would be interested to know what you guys think about this. After the discussion started on the PIM mailing list, it went cold for a while before we got Tom's mail about this new list. In the meantime, I put together some text that provides a solution to the problem, after an internal discussion. But since the goal is to first get the requirements in order, I will refrain from putting it forward. Also, I have limited the scope to refresh reduction of Join/Prune Messages only. IMO, Hellos and Asserts need not be addressed. But would be interested to know what the group thinks. Problem statement: ============== In PIM-SM, a router builds its multicast forwarding state based on the Join/Prune messages received from its downstream routers (in addition to IGMP/MLD Joins received from local receivers. For the purposes of this document, the local receivers are not considered). In order for this forwarding state to be kept alive, PIM-SM requires the downstream routers to periodically send Join/Prune messages to their corresponding upstream neighbors. As the amount of forwarding state increases, so does the amount of information that needs to be refreshed, and the processing overhead associated with that refresh. This makes it difficult to scale PIM-SM to support millions of forwarding entries. Providing IP multicast as a service in Layer 3 and Layer 2 VPNs requires PIM to scale to such numbers. IP Multicast in Layer 3 and Layer 2 VPNs are applications where the benefits of Refresh Reduction can be immediately visible. Consider an example of a router that has 1000 Layer 3 VPNs. If each VPN has 1000 forwarding entries and 10 downstream interfaces for each forwarding entry, the number of downstream states ((*,G), (S,G) Joins and/or (S,G,Rpt) Prunes) will be equivalent to 1000 * 1000 * 10, i.e. 10 million. If a default Upstream Join Timer (JT Timer) value of 1 minute is considered, that means 10 million state refreshes every minute. For each such state, at least one timer needs to be run. That means 10 million active timers. PIM-SM Join/Prune Message encoding allows for encoding multiple downstream states in a single message, although an implementation would be fully compliant if it did not. Considering the best case of the above example, where all downstream routers did optimum packing of all the Join/Prune Messages, assuming an MTU of 1500 bytes on an Ethernet interface, after accounting for IP and Ethernet headers, each Join/Prune message can carry anywhere between 72 to 180 Join/Prune states (assuming one source per group in one case and one group and multiple sources per group in the other), it would still be approximately between 50,000 and 140,000 Join/Prune messages per minute, still a significant number of messages just to convey to the upstream router that the state it has is still valid. A related issue is that of reliability. If a Join/Prune Message is lost/dropped, the forwarding state at the upstream router will never be established for all the new states in the message (that an upstream router has not yet seen), until the downstream router refreshes the state again, which is by default, after a minute. As the number of refreshes increases, the chances of a Join/Prune Message getting lost/dropped also increases. The consequences of a Join/Prune message not getting to an upstream router are more severe in case of a unicast route change. If a unicast route that effects a lot of streams changes, the downstream router has to send the Joins for all the streams to the new upstream nbr. If one of these is dropped, the disruption of traffic is very pronounced. The two issues are related. Making the refresh interval smaller (by reducing the value of the Upstream JP Timer) will ensure that traffic disruption is minimal, but increases the number of refreshes and the associated processing with it. Making the refresh interval larger (by using a higher value for the Upstream JP Timer) will reduce the number of refreshes and associated processing, but can cause traffic disruption to go undetected by the protocol for a longer time. Thus, tweaking the interval at which Join/Prunes are sent is not sufficient. Clearly, a solution that addresses refresh reduction should also ensure that some sort of reliability is built into the protocol, primarily because the decision whether to refresh or not can be made only after we are sure that the original update did get through to the upstream router. Otherwise, the side effects of refresh reduction can outweigh the benefits. Comments? Regards, Suresh ------=_NextPart_000_026B_01C4DD2C.D8062F40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

To get the ball rolling, I have taken a stab at = defining the problem. I have expanded the scope a bit to include reliability in the = protocol. I would be interested to know what you guys think about this.  = After the discussion started on the PIM mailing list, it went cold for a while = before we got Tom’s mail about this new list. In the meantime, I put = together some text that provides a solution to the problem, after an internal = discussion. But since the goal is to first get the requirements in order, I will refrain = from putting it forward.  Also, I have limited the scope to refresh = reduction of Join/Prune Messages only. IMO, Hellos and Asserts need not be = addressed. But would be interested to know what the group thinks.

 

Problem statement:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

In PIM-SM, a router builds its multicast forwarding = state based on the Join/Prune messages received from its downstream routers = (in addition to IGMP/MLD Joins received from local receivers. For the = purposes of this document, the local receivers are not considered). In order for = this forwarding state to be kept alive, PIM-SM requires the downstream = routers to periodically send Join/Prune messages to their corresponding upstream neighbors. As the amount of forwarding state increases, so does the = amount of information that needs to be refreshed, and the processing overhead = associated with that refresh. This makes it difficult to scale PIM-SM to support = millions of forwarding entries. Providing IP multicast as a service in Layer 3 = and Layer 2 VPNs requires PIM to scale to such  numbers. IP Multicast in = Layer 3 and Layer 2 VPNs are applications where the benefits of Refresh Reduction = can be immediately visible.

 

Consider an example of a router that has 1000 Layer 3 = VPNs. If each VPN has 1000 forwarding entries and 10 downstream interfaces for =  each forwarding entry, the number of downstream states ((*,G), (S,G) Joins = and/or (S,G,Rpt) Prunes) will be equivalent to 1000 * 1000 * 10, i.e. 10 million. If a = default Upstream Join Timer (JT Timer) value of 1 minute is considered, that = means 10 million state refreshes every minute. For each such state, at least one = timer needs to be run. That means 10 million active timers.

 

PIM-SM Join/Prune Message encoding allows for = encoding multiple downstream states in a single message, although an = implementation would be fully compliant if it did not. Considering the best case of the above example, where all downstream routers did optimum packing of all the = Join/Prune Messages, assuming an MTU of 1500 bytes on an Ethernet interface, after accounting for IP and Ethernet headers, each Join/Prune message can = carry anywhere between 72 to 180 Join/Prune states (assuming one source per = group in one case and one group and multiple sources per group in the other), it = would still be approximately between 50,000 and 140,000 Join/Prune messages = per minute, still a significant number of messages just to convey to the = upstream router that the state it has is still valid.

 

A related issue is that of reliability. If a = Join/Prune Message is lost/dropped, the forwarding state at the upstream router = will never be established for all the new states in the message (that an upstream = router has not yet seen), until the downstream router refreshes the state = again,  which is by default, after a minute. As the number of refreshes increases, the chances of a Join/Prune Message getting lost/dropped also increases. The consequences of a Join/Prune message not getting to an upstream router = are more severe in case of a unicast route change. If a unicast route that = effects a lot of streams changes, the downstream router has to send the Joins for all = the streams to the new upstream nbr. If one of these is dropped, the = disruption of traffic is very pronounced.

 

The two issues are related. Making the refresh = interval smaller (by reducing the value of the Upstream JP Timer) will ensure = that traffic disruption is minimal, but increases the number of refreshes and = the associated processing with it. Making the refresh interval larger (by using a = higher value for the Upstream JP Timer) will reduce the number of refreshes  and associated processing, but can cause traffic disruption to go undetected = by the protocol for a longer time. Thus, tweaking the interval at which = Join/Prunes are sent is not sufficient.  Clearly, a solution that addresses = refresh reduction should also ensure that some sort of reliability is built into = the protocol, primarily because the decision whether to refresh or not can = be made only after we are sure that the original update did get through to the = upstream router. Otherwise, the side effects of refresh reduction can outweigh = the benefits.

 

Comments?

 

Regards,

 

Suresh

------=_NextPart_000_026B_01C4DD2C.D8062F40-- From marshall.eubanks@gmail.com Thu Dec 9 10:06:51 2004 Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id iB9F6ooI025062 for ; Thu, 9 Dec 2004 10:06:51 -0500 (EST) (envelope-from marshall.eubanks@gmail.com) Received: by rproxy.gmail.com with SMTP id y7so941352rne for ; Thu, 09 Dec 2004 07:06:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Wa84bomiuOqjKp5l5Na/VQUtK/TfZW5mWQHQ6XRJJZshRBKLegDYfWMHIo93OA6Y1rKb4QDoD8gWisPricTgKvnJaKdiLXXSLPGTpRU6HMDOpNHViF6qEJKGmEwn2YGw8f3fJqZ4+58CkXHako0nrUu0hEeXk/PnHN8ZmKhKQnc= Received: by 10.38.14.54 with SMTP id 54mr56674rnn; Thu, 09 Dec 2004 07:06:50 -0800 (PST) Received: by 10.38.208.48 with HTTP; Thu, 9 Dec 2004 07:06:50 -0800 (PST) Message-ID: Date: Thu, 9 Dec 2004 10:06:50 -0500 From: Marshall Eubanks To: suresh.boddapati@alcatel.com Subject: Re: [Pim-state] (no subject) In-Reply-To: <026a01c4dd6f$e6296f40$4abb16ac@alcatelxp> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <026a01c4dd6f$e6296f40$4abb16ac@alcatelxp> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: Marshall Eubanks List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 09 Dec 2004 15:06:51 -0000 Hello; Thanks for this summary. I notice no mention of protection against attacks. Is this out of scope ? Here is a way of thinking of the core problem which might be useful. If you have a 10 million state elements, and the maximally packed J/P messages described below, you get a control rate of 166,000 state refreshes per second, requiring a bit rate of 12 Mbp or more. The amount of aggregation that can be done clearly depends a lot on the amount of state churn. It seems to me that if you have 10^7 state entries, and they have an average half life of 30 seconds, you have a mess and will not be able to aggregate much. This implies that any sort of aggregation has to make implict or explicit assumptions about the longevity of state. Suppose you have 10^7 entries and each has a half life of 10^4 seconds, you might be able to get the state control traffic down to 10^3 refreshes per second, down by over 2 orders of magnitude. (Sources may last forever, but I suspect that in most cases receivers come and go on time scales comparible to human work shifts; i.e., hours, so you might not be able to do much better than this.) So, one idea would be to allow for a "state bucket". You divide your state into one or more classes, and report on each class as a unit. One simple way to do this would require at least two new messages, sent one hop at a time using multicast to the all PIM routers group : PIM STATE message : A summary of the amount of state on an interface. This could be sent a some fraction of the soft-state time out interval (say, every 10 seconds). This should also contain the (multicast) address range it applies to. (For example, separate treatment for SSM and ASM might be a very good idea.) Address ranges not covered by STATE messages are processed as usual in standard PIM. PIM QUERY : A request for an update of state covered by a specific PIM STATE message. This could be either a dump of all state (i.e., JOINS for all active groups, etc.) or the query could include a delta time and produce joins / leaves for the time interval since the last scheduled STATE message. The result in either case would be a set of join / leave messages, which could be processed as normal in PIM. I would also allow for a query that would just yield a repeat of the PIM STATE message. So, initial joins and final leaves are processed as always. If the next hop receives them, then its internal state will match the summary in the PIM STATE message, and nothing extra need be done. If not, it requests an update. If the PIM STATE does not arrive, then a QUERY is sent to request it (so, obviously a timer is involved here). The PIM STATE mechanism is (if in use) assumed to be always present (i.e., is sent even if there is no state to report), so it is not subject to soft state, which I think will remove the need for an ACK for the PIM STATE message. In Suresh's example, this PIM STATE would presumably be done on a per VPN per interface basis, and so could cut down on the control traffic by a factor of about 1000. What about soft state ? It seems to me that there are two cases here - The source or receiver just goes away (the box is unplugged, say). This should be caught by the first hop router, and propagated upstream. A link goes down, or the packets are sent to the wrong interface, or for some other reason transmission is interrupted _inside the network_. In that case, that should be caught by the PIM STATE message being absent on the affected link, and eventually all of the state aggregated into that STATE message should be dropped. That can then be propagated upstream in the usual fashion. So, I see no need to keep 10^7 timers inside the network, just one per STATE range. First hop routers have to proceed as usual. Obviously, there needs to be some glue to handle ASSERT winners changing etc., if this is the direction people want to go in. Regards Marshall On Wed, 8 Dec 2004 13:50:12 -0800, Suresh Boddapati wrote: > > > > All, > > > > To get the ball rolling, I have taken a stab at defining the problem. I have > expanded the scope a bit to include reliability in the protocol. I would be > interested to know what you guys think about this. After the discussion > started on the PIM mailing list, it went cold for a while before we got > Tom's mail about this new list. In the meantime, I put together some text > that provides a solution to the problem, after an internal discussion. But > since the goal is to first get the requirements in order, I will refrain > from putting it forward. Also, I have limited the scope to refresh > reduction of Join/Prune Messages only. IMO, Hellos and Asserts need not be > addressed. But would be interested to know what the group thinks. > > > > Problem statement: > > ============== > > In PIM-SM, a router builds its multicast forwarding state based on the > Join/Prune messages received from its downstream routers (in addition to > IGMP/MLD Joins received from local receivers. For the purposes of this > document, the local receivers are not considered). In order for this > forwarding state to be kept alive, PIM-SM requires the downstream routers to > periodically send Join/Prune messages to their corresponding upstream > neighbors. As the amount of forwarding state increases, so does the amount > of information that needs to be refreshed, and the processing overhead > associated with that refresh. This makes it difficult to scale PIM-SM to > support millions of forwarding entries. Providing IP multicast as a service > in Layer 3 and Layer 2 VPNs requires PIM to scale to such numbers. IP > Multicast in Layer 3 and Layer 2 VPNs are applications where the benefits of > Refresh Reduction can be immediately visible. > > > > Consider an example of a router that has 1000 Layer 3 VPNs. If each VPN has > 1000 forwarding entries and 10 downstream interfaces for each forwarding > entry, the number of downstream states ((*,G), (S,G) Joins and/or (S,G,Rpt) > Prunes) will be equivalent to 1000 * 1000 * 10, i.e. 10 million. If a > default Upstream Join Timer (JT Timer) value of 1 minute is considered, that > means 10 million state refreshes every minute. For each such state, at least > one timer needs to be run. That means 10 million active timers. > > > > PIM-SM Join/Prune Message encoding allows for encoding multiple downstream > states in a single message, although an implementation would be fully > compliant if it did not. Considering the best case of the above example, > where all downstream routers did optimum packing of all the Join/Prune > Messages, assuming an MTU of 1500 bytes on an Ethernet interface, after > accounting for IP and Ethernet headers, each Join/Prune message can carry > anywhere between 72 to 180 Join/Prune states (assuming one source per group > in one case and one group and multiple sources per group in the other), it > would still be approximately between 50,000 and 140,000 Join/Prune messages > per minute, still a significant number of messages just to convey to the > upstream router that the state it has is still valid. > > > > A related issue is that of reliability. If a Join/Prune Message is > lost/dropped, the forwarding state at the upstream router will never be > established for all the new states in the message (that an upstream router > has not yet seen), until the downstream router refreshes the state again, > which is by default, after a minute. As the number of refreshes increases, > the chances of a Join/Prune Message getting lost/dropped also increases. The > consequences of a Join/Prune message not getting to an upstream router are > more severe in case of a unicast route change. If a unicast route that > effects a lot of streams changes, the downstream router has to send the > Joins for all the streams to the new upstream nbr. If one of these is > dropped, the disruption of traffic is very pronounced. > > > > The two issues are related. Making the refresh interval smaller (by reducing > the value of the Upstream JP Timer) will ensure that traffic disruption is > minimal, but increases the number of refreshes and the associated processing > with it. Making the refresh interval larger (by using a higher value for the > Upstream JP Timer) will reduce the number of refreshes and associated > processing, but can cause traffic disruption to go undetected by the > protocol for a longer time. Thus, tweaking the interval at which Join/Prunes > are sent is not sufficient. Clearly, a solution that addresses refresh > reduction should also ensure that some sort of reliability is built into the > protocol, primarily because the decision whether to refresh or not can be > made only after we are sure that the original update did get through to the > upstream router. Otherwise, the side effects of refresh reduction can > outweigh the benefits. > > > > Comments? > > > > Regards, > > > > Suresh > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state > > > From suresh.boddapati@alcatel.com Thu Dec 9 10:22:46 2004 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id iB9FMg1L025095 for ; Thu, 9 Dec 2004 10:22:45 -0500 (EST) (envelope-from suresh.boddapati@alcatel.com) Received: from alcatelxp ([172.22.187.74] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Dec 2004 07:22:36 -0800 From: "Suresh Boddapati" To: "'Marshall Eubanks'" Subject: RE: [Pim-state] (no subject) Date: Thu, 9 Dec 2004 07:20:53 -0800 Organization: Alcatel USA Message-ID: <02b201c4de02$ad7fa0e0$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 09 Dec 2004 15:22:36.0353 (UTC) FILETIME=[E9976310:01C4DE02] Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: suresh.boddapati@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 09 Dec 2004 15:22:46 -0000 Hi Marshall, Protection against attacks is definitely out of scope of this document IMO. As for solutions, I would rather we discuss them once we all agree what the problem is. Suresh -----Original Message----- From: Marshall Eubanks [mailto:marshall.eubanks@gmail.com] Sent: Thursday, December 09, 2004 7:07 AM To: suresh.boddapati@alcatel.com Cc: pim-state@mountain2sea.com Subject: Re: [Pim-state] (no subject) Hello; Thanks for this summary. I notice no mention of protection against attacks. Is this out of scope ? Here is a way of thinking of the core problem which might be useful. If you have a 10 million state elements, and the maximally packed J/P messages described below, you get a control rate of 166,000 state refreshes per second, requiring a bit rate of 12 Mbp or more. The amount of aggregation that can be done clearly depends a lot on the amount of state churn. It seems to me that if you have 10^7 state entries, and they have an average half life of 30 seconds, you have a mess and will not be able to aggregate much. This implies that any sort of aggregation has to make implict or explicit assumptions about the longevity of state. Suppose you have 10^7 entries and each has a half life of 10^4 seconds, you might be able to get the state control traffic down to 10^3 refreshes per second, down by over 2 orders of magnitude. (Sources may last forever, but I suspect that in most cases receivers come and go on time scales comparible to human work shifts; i.e., hours, so you might not be able to do much better than this.) So, one idea would be to allow for a "state bucket". You divide your state into one or more classes, and report on each class as a unit. One simple way to do this would require at least two new messages, sent one hop at a time using multicast to the all PIM routers group : PIM STATE message : A summary of the amount of state on an interface. This could be sent a some fraction of the soft-state time out interval (say, every 10 seconds). This should also contain the (multicast) address range it applies to. (For example, separate treatment for SSM and ASM might be a very good idea.) Address ranges not covered by STATE messages are processed as usual in standard PIM. PIM QUERY : A request for an update of state covered by a specific PIM STATE message. This could be either a dump of all state (i.e., JOINS for all active groups, etc.) or the query could include a delta time and produce joins / leaves for the time interval since the last scheduled STATE message. The result in either case would be a set of join / leave messages, which could be processed as normal in PIM. I would also allow for a query that would just yield a repeat of the PIM STATE message. So, initial joins and final leaves are processed as always. If the next hop receives them, then its internal state will match the summary in the PIM STATE message, and nothing extra need be done. If not, it requests an update. If the PIM STATE does not arrive, then a QUERY is sent to request it (so, obviously a timer is involved here). The PIM STATE mechanism is (if in use) assumed to be always present (i.e., is sent even if there is no state to report), so it is not subject to soft state, which I think will remove the need for an ACK for the PIM STATE message. In Suresh's example, this PIM STATE would presumably be done on a per VPN per interface basis, and so could cut down on the control traffic by a factor of about 1000. What about soft state ? It seems to me that there are two cases here - The source or receiver just goes away (the box is unplugged, say). This should be caught by the first hop router, and propagated upstream. A link goes down, or the packets are sent to the wrong interface, or for some other reason transmission is interrupted _inside the network_. In that case, that should be caught by the PIM STATE message being absent on the affected link, and eventually all of the state aggregated into that STATE message should be dropped. That can then be propagated upstream in the usual fashion. So, I see no need to keep 10^7 timers inside the network, just one per STATE range. First hop routers have to proceed as usual. Obviously, there needs to be some glue to handle ASSERT winners changing etc., if this is the direction people want to go in. Regards Marshall On Wed, 8 Dec 2004 13:50:12 -0800, Suresh Boddapati wrote: > > > > All, > > > > To get the ball rolling, I have taken a stab at defining the problem. I have > expanded the scope a bit to include reliability in the protocol. I would be > interested to know what you guys think about this. After the discussion > started on the PIM mailing list, it went cold for a while before we got > Tom's mail about this new list. In the meantime, I put together some text > that provides a solution to the problem, after an internal discussion. But > since the goal is to first get the requirements in order, I will refrain > from putting it forward. Also, I have limited the scope to refresh > reduction of Join/Prune Messages only. IMO, Hellos and Asserts need not be > addressed. But would be interested to know what the group thinks. > > > > Problem statement: > > ============== > > In PIM-SM, a router builds its multicast forwarding state based on the > Join/Prune messages received from its downstream routers (in addition to > IGMP/MLD Joins received from local receivers. For the purposes of this > document, the local receivers are not considered). In order for this > forwarding state to be kept alive, PIM-SM requires the downstream routers to > periodically send Join/Prune messages to their corresponding upstream > neighbors. As the amount of forwarding state increases, so does the amount > of information that needs to be refreshed, and the processing overhead > associated with that refresh. This makes it difficult to scale PIM-SM to > support millions of forwarding entries. Providing IP multicast as a service > in Layer 3 and Layer 2 VPNs requires PIM to scale to such numbers. IP > Multicast in Layer 3 and Layer 2 VPNs are applications where the benefits of > Refresh Reduction can be immediately visible. > > > > Consider an example of a router that has 1000 Layer 3 VPNs. If each VPN has > 1000 forwarding entries and 10 downstream interfaces for each forwarding > entry, the number of downstream states ((*,G), (S,G) Joins and/or (S,G,Rpt) > Prunes) will be equivalent to 1000 * 1000 * 10, i.e. 10 million. If a > default Upstream Join Timer (JT Timer) value of 1 minute is considered, that > means 10 million state refreshes every minute. For each such state, at least > one timer needs to be run. That means 10 million active timers. > > > > PIM-SM Join/Prune Message encoding allows for encoding multiple downstream > states in a single message, although an implementation would be fully > compliant if it did not. Considering the best case of the above example, > where all downstream routers did optimum packing of all the Join/Prune > Messages, assuming an MTU of 1500 bytes on an Ethernet interface, after > accounting for IP and Ethernet headers, each Join/Prune message can carry > anywhere between 72 to 180 Join/Prune states (assuming one source per group > in one case and one group and multiple sources per group in the other), it > would still be approximately between 50,000 and 140,000 Join/Prune messages > per minute, still a significant number of messages just to convey to the > upstream router that the state it has is still valid. > > > > A related issue is that of reliability. If a Join/Prune Message is > lost/dropped, the forwarding state at the upstream router will never be > established for all the new states in the message (that an upstream router > has not yet seen), until the downstream router refreshes the state again, > which is by default, after a minute. As the number of refreshes increases, > the chances of a Join/Prune Message getting lost/dropped also increases. The > consequences of a Join/Prune message not getting to an upstream router are > more severe in case of a unicast route change. If a unicast route that > effects a lot of streams changes, the downstream router has to send the > Joins for all the streams to the new upstream nbr. If one of these is > dropped, the disruption of traffic is very pronounced. > > > > The two issues are related. Making the refresh interval smaller (by reducing > the value of the Upstream JP Timer) will ensure that traffic disruption is > minimal, but increases the number of refreshes and the associated processing > with it. Making the refresh interval larger (by using a higher value for the > Upstream JP Timer) will reduce the number of refreshes and associated > processing, but can cause traffic disruption to go undetected by the > protocol for a longer time. Thus, tweaking the interval at which Join/Prunes > are sent is not sufficient. Clearly, a solution that addresses refresh > reduction should also ensure that some sort of reliability is built into the > protocol, primarily because the decision whether to refresh or not can be > made only after we are sure that the original update did get through to the > upstream router. Otherwise, the side effects of refresh reduction can > outweigh the benefits. > > > > Comments? > > > > Regards, > > > > Suresh > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state > > > From dino@cisco.com Tue Dec 14 22:03:27 2004 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id iBF33Qgn044339 for ; Tue, 14 Dec 2004 22:03:27 -0500 (EST) (envelope-from dino@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 14 Dec 2004 20:09:57 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from dino-lnx.cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBF33Jsv016798; Tue, 14 Dec 2004 19:03:19 -0800 (PST) Received: (from dino@localhost) by dino-lnx.cisco.com (8.11.6/8.11.6) id iBF33IJ17435; Tue, 14 Dec 2004 19:03:18 -0800 Date: Tue, 14 Dec 2004 19:03:18 -0800 Message-Id: <200412150303.iBF33IJ17435@dino-lnx.cisco.com> From: Dino Farinacci To: suresh.boddapati@alcatel.com In-reply-to: <026a01c4dd6f$e6296f40$4abb16ac@alcatelxp> (suresh.boddapati@alcatel.com) Subject: Re: [Pim-state] (no subject) References: <026a01c4dd6f$e6296f40$4abb16ac@alcatelxp> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 15 Dec 2004 03:03:27 -0000 >> Comments? A few of us have been looking at and spec'ing solutions. They tend to fall into these solution spaces: [1] Use a new JP-Ack message to provide incremental updates for join and prune state changes where reliability and retransmision are done on a per multicast route entry. [2] Use a full-mesh of TCP connections ala LDP (and BGP). [3] Use a checksum and/or version number to suppress the volume of periodic messaging but not the periodic messages themselves. We would like to state a requirement of making the fewest number of changes to the PIM protocol so we can still call it PIM version 2. We would like for the changes to not obsolete the latest PIM RFC. So we would like to write an adjunct draft for these changes where backward compatibility is maintained. Status update: o We have two proposals for [1] that have converged into a single proposal. o We have a draft for [2] but the authors would rather go with a JP-Ack scheme than a TCP connection mesh scheme. o [3] has been discussed but nothing has been written up. I'm putting some finishing touches on a design note for [1] (not in Internet Draft form yet). Would like the people on this list to help co-author the proposal. So while I'm getting the material together, let's discuss pros/cons for each of [1] through [3]. And if you think there are other solutions (like Marshall's). Cheers, Dino From suresh.boddapati@alcatel.com Wed Dec 15 02:40:18 2004 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id iBF7eHna044808 for ; Wed, 15 Dec 2004 02:40:18 -0500 (EST) (envelope-from suresh.boddapati@alcatel.com) Received: from alcatelxp ([172.22.187.74] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Dec 2004 23:40:11 -0800 From: "Suresh Boddapati" To: Subject: [Pim-state] Proposal Date: Tue, 14 Dec 2004 23:41:44 -0800 Organization: Alcatel USA Message-ID: <039001c4e279$876bb6c0$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0391_01C4E236.794876C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 15 Dec 2004 07:40:11.0742 (UTC) FILETIME=[4EFE37E0:01C4E279] X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: suresh.boddapati@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 15 Dec 2004 07:40:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0391_01C4E236.794876C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dino, As we are already off to discussing solutions, I might as well discuss mine, I guess. Like I said earlier, I have most of it written, almost in draft form. If it's ok with everyone, then we could use this as a starting point. I have enclosed a copy of my draft. It is still a rough draft, but covers mostly all issues that I could think of. Would be interested in comments from everyone. I have tried to keep the changes to the core protocol minimal and the solution is completely backwards compatible. That said, I have a few comments on the proposals you have listed (without knowing the details): [1]: Requiring reliability and retransmission per multicast route entry will make the control traffic even worse IMO. Why can't a message be acked instead of each entry? [2]: It does not have the advantage of using a Multicast address and will also increase the processing on the upstream router. Imagine if there are 10 downstream routers on an interface, the upstream router could now get 10 times the Joins at once if all of them want traffic for a (S,G), because there is no Join suppression (one does not see the other's Join). IMO, the goal should also be to reduce the protocol processing at both the downstream and upstream routers (in terms of timers etc). My preference also would be not to use TCP. [3]: Can you elaborate on this? Is this something similar to what I am suggesting or something else? I volunteer to co-author any proposal this group accepts. Thanks. Suresh -----Original Message----- From: Dino Farinacci [mailto:dino@cisco.com] Sent: Tue 12/14/2004 7:03 PM To: suresh.boddapati@alcatel.com Cc: pim-state@mountain2sea.com Subject: Re: [Pim-state] (no subject) >> Comments? A few of us have been looking at and spec'ing solutions. They tend to fall into these solution spaces: [1] Use a new JP-Ack message to provide incremental updates for join and prune state changes where reliability and retransmision are done on a per multicast route entry. [2] Use a full-mesh of TCP connections ala LDP (and BGP). [3] Use a checksum and/or version number to suppress the volume of periodic messaging but not the periodic messages themselves. We would like to state a requirement of making the fewest number of changes to the PIM protocol so we can still call it PIM version 2. We would like for the changes to not obsolete the latest PIM RFC. So we would like to write an adjunct draft for these changes where backward compatibility is maintained. Status update: o We have two proposals for [1] that have converged into a single proposal. o We have a draft for [2] but the authors would rather go with a JP-Ack scheme than a TCP connection mesh scheme. o [3] has been discussed but nothing has been written up. I'm putting some finishing touches on a design note for [1] (not in Internet Draft form yet). Would like the people on this list to help co-author the proposal. So while I'm getting the material together, let's discuss pros/cons for each of [1] through [3]. And if you think there are other solutions (like Marshall's). Cheers, Dino ------=_NextPart_000_0391_01C4E236.794876C0 Content-Type: text/plain; name="PimRefresh.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="PimRefresh.txt" Abstract: In PIM-SM, a router builds its multicast forwarding state based on the Join/Prune messages received from its downstream routers. In order for this forwarding state to be kept alive, PIM-SM requires the downstream routers to periodically send Join/Prune messages to their corresponding upstream neighbors. In steady state, the overhead associated with=20 processing of Join/Prune messages received on every downstream=20 interface can be significant at the upstream router. In addition,=20 there is no reliability built into the protocol to ensure that a=20 Join/Prune message sent by the downstream router is indeed processed=20 at the upstream router. In bursty scenarios, if a Join/Prune message is lost or dropped at the upstream router, it can take upto a minute for the state to be reacquired.=20 This document describes a mechanism to reduce the processing overhead associated with periodic Join/Prune messages. It also specifies a mechanism to provide reliable transfer of Join/Prune messages. The mechanisms specified in this document are fully backward compatible and kick in only when two routers agree to support the mechanisms. 1.0 Overview In PIM-SM, a router builds its multicast forwarding state based on the=20 Join/Prune messages received from its downstream routers (in addition to IGMP/MLD Joins received from local receivers. For the purposes of=20 this document, the local receivers are not considered). In order for=20 this forwarding state to be kept alive, PIM-SM requires the downstream=20 routers to periodically send Join/Prune messages to their corresponding=20 upstream neighbors. As the amount of forwarding state increases, so does = the amount of information that needs to be refreshed, and the processing = overhead associated with that refresh. This makes it difficult to scale=20 PIM-SM to support millions of forwarding entries. Providing IP multicast = as a service in Layer 3 and Layer 2 VPNs requires PIM to scale to such=20 numbers. IP Multicast in Layer 3 and Layer 2 VPNs are applications where = the benefits of Refresh Reduction can be immediately visible. =20 Consider an example of a router that has 1000 Layer 3 VPNs. If each VPN has 1000 forwarding entries and 10 downstream interfaces for each = forwarding=20 entry, the number of downstream states ((*,G), (S,G) Joins and/or = (S,G,Rpt) Prunes)=20 will be equivalent to 1000 * 1000 * 10, i.e. 10 million. If a default = Upstream Join=20 Timer (JT Timer) value of 1 minute is considered, that means 10 million = state=20 refreshes every minute. For each such state, at least one timer needs to = be run.=20 That means 10 million active timers.=20 PIM-SM Join/Prune Message encoding allows for encoding multiple = downstream states in a single message, although an implementation would be fully compliant = if it did=20 not. Considering the best case of the above example, where all = downstream routers=20 did optimum packing of all the Join/Prune Messages, assuming an MTU of = 1500 bytes=20 on an Ethernet interface, after accounting for IP and Ethernet headers, = each=20 Join/Prune message can carry anywhere between 72 to 180 Join/Prune = states (assuming one source per group in one case and one group and multiple sources per = group in=20 the other), it would still be approximately between 50,000 and 140,000 = Join/Prune=20 messages per minute, still a significant number of messages just to = convey to the=20 upstream router that the state it has is still valid.=20 A simple solution to the problem would be to increase the interval at = which=20 the Join/Prune Messages are refreshed. But increasing the refresh = interval has an effect on the convergence of the network in regards to multicast = traffic. It is important to note that there is no reliability built into the PIM = protocol=20 to ensure that a Join/Prune message sent by the downstream router is = indeed=20 received and processed at the upstream router. In bursty scenarios, if a = Join/Prune message is lost or dropped at the upstream router, it can = take upto a minute for the state to be reacquired. A simple example of this is = when a unicast route used by PIM gets updated. If this route effects a large number of forwarding entries, it results in many Join/Prune messages to be generated and transmitted (since a Join needs to be sent for=20 each entry to the new upstream neighbor). If one Join/Prune PDU is=20 dropped, there will be a traffic disruption for all the entries=20 that were encoded in the PDU, for upto a minute (the default Join/Prune interval). This convergence delay may not be acceptable in certain=20 scenarios, especially in MVPN applications, where the Joins may need to=20 be propagated between sites. While the convergence delay can be reduced by reducing the Join/Prune interval to a smaller value, it would=20 increase the processing overhead on the upstream router because now=20 it has to process the same number of downstream state updates more=20 often. =20 This document proposes schemes to achieve the following goals: 1) Reduce Join/Prune refresh processing overhead by reducing=20 the amount of state to be refreshed and thereby reducing the number of messages required to refresh the state. This is achieved by treating a Join/Prune message containing multiple downstream states as one aggregate state and refreshing only that aggregate state. A new TLV called the Message ID TLV is defined that associates a 32 bit = identifier, the Message ID, with the aggregate state in a Join/Prune message.=20 The downstream router sends the new TLV along with the Join/Prune message thereby registering the association with the upstream router. Once the upstream router is aware of the association between the identifier and the aggregate state, only the message IDs are refreshed using a new message called the PIM JP Refresh message.=20 This significantly reduces the number of messages that are used to=20 refresh existing Join/Prune state. The processing overhead at the upstream router is also reduced because now instead of running timers for each downstream state, it can just run one timer per message.=20 This is discussed in more detail in Section ? 2) Add reliability to the Join/Prune message exchange by requiring explicit acknowledgements from the receiver to the sender and=20 retransmissions with exponential backoff by the sender when acknowledgements are not received. It is essential that the Join/Prune message be acknowledged; otherwise, subsequent refreshes sent only with = Message IDs will not have any meaning to the upstream router since it would not have made the association between a Message ID and a Join/Prune message, if = it had not seen the Join/Prune message. This is discussed in more detail=20 in Sections ? 2.0 Refresh Reduction Capability Negotiation The refresh reduction mechanism is used between an upstream and a = downstream router only if both the routers support the mechanism. This capability = is=20 advertised using a Hello Option called the Refresh Reduction Capability=20 Option. The format of the Option is 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 =3D ?? | Length =3D 0 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The presence of the option indicates that the router supports Refresh Reduction Capability. If the upstream router does not support Refresh=20 Reduction, a downstream router MUST NOT use the Refresh Reduction = mechanism. Note that if one downstream router supports Refresh Reduction but = another downstream router does not, both can co-exist on a LAN as long as the = upstream router supports Refresh Reduction (see Section ?) 3.0 Message ID TLV The Message ID TLV identifies a Join/Prune message sent by a downstream = router. It contains a unique identifier, the Message ID, which differentiates a = Join/Prune=20 message from all other Join/Prune messages sent by the downstream = router.=20 The Message ID represents the aggregate of all the downstream states = listed=20 in a Join/Prune message.=20 The format of the Message ID TLV is 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 =3D ?? | Length =3D 8 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I | Join/Prune Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: The first byte following the Length field represents flags for = this message.=20 This draft specifies only the I flag. All the other bits in the flags = field SHOULD=20 be set to zero on transmission and MUST be ignored on receipt. The I bit if set indicates that this is an incremental update to an = existing=20 Join/Prune Message, associated with the Message ID. 4.0 New Packet types This draft introduces the following two new PIM packet types: a) PIM Join/Prune Refresh Message: This message is used by a downstream = router to=20 refresh its Message IDs to the upstream router. This message is unicast = by a downstream router to the upstream router. The format of the message is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HoldTime | NumMessageIDs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID TLV 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID TLV n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ b) PIM JP Acknowledgement Message: This message is used by an upstream = router to=20 acknowledge the receipt of either a Join/Prune Message that has a = Message ID encoded in it or a PIM Join/Prune Refresh Message. This message is unicast by = the upstream=20 router to the downstream router. The format of the message is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | NumMessageIDs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID TLV 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID TLV n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The usage of the above Messages is described in sections ? 5.0 Refresh Reduction Procedures Once a downstream router determines that the upstream router is capable = of supporting Refresh Reduction, the downstream router initiates the Downstream = Refresh Reduction=20 procedures as defined in Section 5.1. The upstream router carries out = the Upstream Refresh Reduction procedures as defined in Section 5.2. 5.1 Downstream Router Refresh Reduction Procedure When a downstream router acquires a new (*,G), (S,G) or (S,G,Rpt) state = (due to local=20 receivers sending IGMP Joins or its downstream routers sending PIM = (*,G), (S,G) Joins=20 or (S,G,Rpt) Prunes), it forwards the (*,G), (S,G) Join or (S,G,Rpt) = Prune to the=20 appropriate upstream neighbor in a Join/Prune Message. The refresh = reduction procedures described in this section update the state machines described = in Sections 4.5.5 through 4.5.9 of [PIM] as follows: 5.1.1 Sending (*,*,RP), (*,G), (S,G) Joins and (S,G,Rpt) Prunes a)When JoinDesired becomes True for a (*,*,RP), (*,G) or (S,G) state or = PruneDesired=20 becomes True for an (S,G,Rpt) Prune state, in addition to the procedures = listed in=20 Sections 4.5.5 through 4.5.7, the downstream router does the following: 1) Assigns a unique identifier, called the Message ID, to every "new" = Join/Prune=20 message it sends to an upstream neighbor. A Join/Prune Message is = considered new if it=20 does not have a Message ID assigned to it. The Message ID needs to be = unique only across=20 messages sent to agiven upstream neighbor. The Message ID uniquely = identifies a Join/Prune message sent by a downstream router to an upstream router. The Message = ID is encoded in a=20 TLV called the Message ID TLV and sent along with the Join/Prune = message. Associated with the Message ID is a sequence number, which enables the upstream router = to keep track of=20 updates to a given message sent by a downstream router. The sequence = number is an increasing 32 bit number starting from 1. The Message ID TLV also contains flags to = describe whether=20 the update is a complete update or an incremental update. When the = Message ID is allocated for the first time, the I bit MUST be zero to indicate that it is a = complete update. 2) Associates every (*,G) Join, (S,G) Join and (S,G,Rpt) Prune encoded = in a Join/Prune Message with the Message ID TLV of the Join/Prune message. If a new state is = ready to be encoded in=20 a Join/Prune Message, an existing Message ID SHOULD be used if there is = room in the message=20 to accomodate an additional state. Otherwise, a new Join/Prune Message = is created and the new state is associated with the new Join/Prune Message. If an existing = Message ID is used, the I bit MUST be set. 3) Sends the Join/Prune message to the upstream router. This message is = retransmitted if=20 necessary (see Section 7) until an acknowledgement is received from the = upstream router.=20 The acknowledgement indicates that the upstream router is aware of the = association between=20 the Message ID and the Join/Prune states listed in the Join/Prune = message. 4) Starts the Upstream Join Timer (JT) per Join/Prune Message (instead = of starting it for each state in the Message). The JT Timer is restarted if it is already = running.=20 b)When JT Timer expires in Joined state, the downstream router does the = following: Sends a refresh of the Join/Prune message using the Join/Prune Refresh = Message. The Join/Prune Refresh Message consists of one or more Message ID TLVs = that represent the Join/Prune states to be refreshed. The hold time in the Refresh Message = represents the time=20 interval in seconds for which the Join/Prune states represented by the = Message IDs in the=20 Refresh Message are valid. After sending a Join/Prune Refresh Message, = the Upstream Join=20 Timer (JT) for the Message is restarted. c)When JoinDesired becomes False for a (*,G) or (S,G) state or = PruneDesired becomes False for a (S,G,Rpt) Prune state, the downstream router does the following: 1)Encodes the (*,G), (S,G) Prune or (S,G,Rpt) Join as usual in a = Join/Prune Message.=20 2)Adds the Message ID TLV corresponding to the downstream state. The = sequence number=20 in the message ID is incremented. The I bit in the flags is set to = indicate that it is an incremental update to a previously advertised Message. 3)The Join/Prune Message is sent to the upstream router and is = retransmitted until acknowledged by the upstream router. 5.2 Upstream Router Refresh Reduction Procedure When an upstream router receives a Join/Prune message that contains the = Message ID TLV, the upstream router follows the procedure described below. These = procedures update the=20 procedures described in Sections 4.5.1, 4.5.2 and 4.5.3 of [PIM].=20 5.2.1 Receiving (*,*,RP), (*,G), (S,G) Join/Prune and (S,G,Rpt) Prune = Messages with=20 Message ID TLV For every downstream router on an interface, the upstream router keeps = track of the following: 1) All the Message IDs sent by the downstream router 2) For each Message ID, the associated sequence number 3) For each Message ID, all the Join/Prune states represented by the = Message ID. 4) For each downstream Join/Prune state, the set of Message IDs = associated with it. A Join/Prune state can have multiple Message IDs associated with it from = the same=20 router.This is useful if a downstream router wants to replace a sparse = set of Message IDs=20 with a more compact set of Message IDs. This is done by creating an = association between the=20 Join/Prune state and a new Message ID and then removing the association = between the Join/Prune state and the old Message ID.=20 1) If the I bit in the Message ID TLV is not set, then the upstream = router will create an=20 association between the Message ID in the TLV and the source of the PIM = Join/Prune Message=20 and all the downstream states in the Join/Prune message. The expiry = timer is started for=20 the entire Message ID (instead of each Join/Prune state), using the = largest value of holdtime encoded in the Join/Prune Message. An acknowledgement is scheduled to be = sent to the downstream router indicating that it is aware of the association between the = Message ID sent by the=20 downstream router and the corresponding Join/Prune states. 2) If the I bit in the Message ID TLV is set, then the upstream router = will fetch its local state corresponding to the Message ID encoded in the message. If it does = not have any local state for that Message ID, or the state it has is more recent than the = one encoded in the=20 Join/Prune Message, the Join/Prune Message is discarded without any = further action. If the update in the Join/Prune Message is more recent than the local state, = the upstream router=20 does the following: a) It updates the aggregate state that the Message ID represents. If the = update contains a=20 (*,*,RP)/(*,G)/(S,G) Join or an (S,G,Rpt) Prune for a downstream state, = the association=20 between the new downstream state and the Message ID is made. If the = update contains a=20 (*,*,RP)/(*,G)/(S,G) Prune or an (S,G,Rpt) Join for the downstream = state, the association=20 between the existing downstream state and the Message ID is removed. If = the association being removed is the last association between a Message ID and the = downstream state, then the=20 Prune Pending timer is started for the downstream state if it is a = (*,*,RP)/(*,G)/(S,G) state. The rest of the processing is as per [PIM]. If there is one or more = Message IDs associated with the downstream state (either from the same downstream router or another = downstream router),=20 no action is taken. b) Schedules an acknowledgement to be sent for the received Message ID. 6.0 Acknowledgement of Join/Prune Messages and Join/Prune Refresh = Messages The Join/Prune Messages containing the Message ID TLVs and the = Join/Prune Refresh Messages=20 are acknowledged using the PIM JP acknowledgement message described in = Section 4.=20 The JP Acknowledgement message contains a list of Message ID TLVs to be = acknowledged.=20 Each Message ID TLV is copied as is from the Join/Prune Message or = Join/Prune Refresh Message=20 that is being acknowledged. The acknowledgement message SHOULD be sent=20 no later than PIM_ACK_INTVL seconds from the earliest received JP = MessageID that is being acknowledged. The PIM_ACK_INTVL delay allows for multiple Message IDs to = be acknowledged=20 in a single acknowledgement message. A Message ID MUST NOT be acknowledged if the sequence number of the = Message ID received in the Join/Prune Message is smaller than the sequence number of the = same Message ID=20 acknowledged earlier. In other words, only updates to Message IDs = represented by increasing sequence numbers SHOULD be acknowledged. 7.0 Retransmission of Join/Prune Messages The Join/Prune Messages containing the Message ID TLVs MUST be = retransmitted by the downstream router until it receives an acknowledgement from the upstream router. = When a downstream router sends a Join/Prune Message with a Message ID TLV in it, it starts the JP = Retransmission timer which is set initially to PIM_RTX_INTVL seconds. This timer is stopped = if an acknowledgement is received. If the timer expires and no acknowledgement is received, the = Message is retransmitted and the timer is restarted with a value of 2 * PIM_RTX_INTVL. The timer = is backed off everytime the Message is retransmitted to (n+1) * PIM_RTX_INTVL where n is the = previous multiplier. The timer is capped off at Upstream JP Timer interval. Implementations can = choose to bring down the adjacency with the upstream router if a message is not acknowledged = after a certain number of=20 retransmissions. While in the middle of retransmissions, if an update occurs to the = Message, causing the sequence number to be incremented, the retransmissions are restarted by setting = the retransmission interval to PIM_RTX_INTVL. 8.0 An example ------- -------- | | | | | D1 |-------------------------| U | | | | | | ------- | -------- | ------- | | | D2 | | | -------- Consider an example where there are two downstream routers D1 and D2 and = one upstream router U.=20 1) D1 acquires a new state (S1,G1) due to one of its downstream = interfaces sending an (S,G) Join for (S1,G1). 2) D1's upstream interface is the interface shown above and the upstream = neighbor is U. D1 and U are aware that both support Refresh Reduction since they = both have advertised Refresh Reduction capability in their Hellos. 3) D1 encodes (S1,G1) Join in a Join/Prune Message assigns the = Join/Prune Message a Message ID of 1 (call this Message M1D1) and sends it to U. The = sequence number is set to 1. It starts the Upstream JP Timer (JT Timer) for M1 (not for (S1,G1)). D1 = also starts the rtx timer for M1. The Message ID TLV has the I bit set to zero. 4) U receives the Join/Prune Message. U creates a forwarding entry for = (S1,G1) and adds the interface shown above to its oif list. U associates (S1,G1) = with M1D1. It starts the expiry timer for M1D1. 5) U sends an acknowledgement back to D1. 6) D1 receives the acknowledgement. It stops the rtx timer for M1. 6) D2 is also interested in (S1,G1) but it sees D1's Join. It restarts = its upstream JT timer for (S1,G1).=20 7) The Upstream JT Timer expires for Message M1 at D1. It sends a = refresh for M1 by sending a Join/Prune Refresh Message and including M1 in it. 8) U acks the Join/Prune Refresh Message. 9) The Upstream JT Timer expires at D2. Since it has not seen any more = joins for (S1,G1), it decides to send a Join/Prune message. D2 also supports refresh = reduction. So it follows the same=20 steps as D1 as described in Step 3 above and sends a Join/Prune Message = with Message ID 1=20 (call this Message M1D2) and sends it to U. The sequence number is set = to 1. 10)U receives the Join/Prune Message. U adds to the association that = (S1,G1) has. Now (S1,G1) is associated with M1D1 and M1D2. It starts the expiry timer for M1D2. 11) D1 acquires more downstream states (S2, G2), (S3, G3), ....(Sm,Gm), = for which the upstream nbr is U. Since there is room to add these to M1D1, D1 encodes these = Joins in a Join/Prune Message and adds the Message ID TLV for M1D1. The I bit is set = indicating that this is an incremental update, the sequence number is incremented to 2 and the = Join/Prune message is sent out. The JT timer is restarted for M1D1. 12) U associates (S2, G2), (S3, G3) and (Sm, Gm) with M1D1. It restarts = the expiry timer for M1D1. U sends back an acknowledgement for M1D1, seq.No=3D2. 13) The Upstream JT Timer expires at D1. M1D1 is refreshed using JP = Refresh Message. JT Timer is restarted.=20 14) JP Refresh is received at U. Expiry timer for M1D1 is restarted. Repeating the above example, if there are a large number of states that = span multiple messages,=20 they all can be refreshed by a much smaller set of JP Refresh Messages = which contain multiple=20 Message IDs to be refreshed. Implementations can choose to intentionally = synchronize refreshes=20 of multiple messages so as to minimize the number of refresh messages = sent to the upstream router. 15) D2 decides to prune (S1,G1). It sends a Join/Prune Message with an = incremental update to M1D2. 16) U removes the association between (S1,G1) and M1D2. It sees that = (S1,G1) is still associated with M1D1. It does not take any further action. 17) D1 does not have to override the Prune sent by D2 since it has not = explicitly removed the association between (S1,G1) and M1D1. D1 takes no action either. 9.0 Backwards Compatibility PIM Refresh Reduction described in this document is completely backwards = compatible. Since the=20 Message ID TLV is an extension to the existing Join/Prune Message, a = downstream router that does not support Refresh Reduction can simply ignore the TLV and process the = Join/Prune Message as=20 specified in [PIM]. The downstream router is not required to understand = PIM Join/Prune Refresh and PIM Join/Prune Acknowledgement messages. The upstream router will also = follow [PIM] procedures for all Join/Prune messages received from a downstream router that does not = support PIM Refresh Reduction. >From an upstream router's point of view, clearly it is beneficial to = have all downstream routers=20 support Refresh Reduction since it now has to support both schemes = (Refresh Reduction procedures with the router that supports it and regular [PIM] procedures with the router = that does not). The upstream router can choose to revert back to regular [PIM] procedures by sending = Hellos without the Refresh=20 Reduction option and a new GenID. 10.0 Snooping considerations Since snooping switches that snoop on PIM Join/Prune messages and build = L2 multicast forwarding state do not understand Refresh Messages, they will not be able to build their = L2 Multicast forwarding state if snooping is turned on after the initial PIM Join/Prune exchange = between the downstream and upstream router (with the I bit set to zero). In order for snooping switches to = build their L2 forwarding state, this document proposes that periodically (every 15 minutes or so), the = downstream router MUST send a=20 complete update of the Join/Prune Message by including all the current = states represented by a Message ID in a Join/Prune Message (with the I bit in the Message ID set to zero). = This way, the snooping state will be eventually built and flooding for the (S,G) will stop. ------=_NextPart_000_0391_01C4E236.794876C0-- From dino@cisco.com Wed Dec 15 14:47:21 2004 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id iBFJlKu3046570 for ; Wed, 15 Dec 2004 14:47:20 -0500 (EST) (envelope-from dino@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 15 Dec 2004 11:47:43 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from dino-lnx.cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBFJl9MI020166; Wed, 15 Dec 2004 11:47:10 -0800 (PST) Received: (from dino@localhost) by dino-lnx.cisco.com (8.11.6/8.11.6) id iBFJlC520986; Wed, 15 Dec 2004 11:47:12 -0800 Date: Wed, 15 Dec 2004 11:47:12 -0800 Message-Id: <200412151947.iBFJlC520986@dino-lnx.cisco.com> From: Dino Farinacci To: suresh.boddapati@alcatel.com In-reply-to: <039001c4e279$876bb6c0$4abb16ac@alcatelxp> (suresh.boddapati@alcatel.com) Subject: Re: [Pim-state] Proposal References: <039001c4e279$876bb6c0$4abb16ac@alcatelxp> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 15 Dec 2004 19:47:21 -0000 >> As we are already off to discussing solutions, I might as well discuss >> mine, I guess. Like I said earlier, I have most of it written, almost in >> draft form. If it's ok with everyone, then we could use this as a >> starting point. I have enclosed a copy of my draft. It is still a rough Yes, we can use it as a starting point if it fits in one of the 3 categories I listed (or if it is a new category) that we all agree fundamentally we should foucs on. >> [1]: Requiring reliability and retransmission per multicast route entry >> will make the control traffic even worse IMO. Why can't a message be >> acked instead of each entry? No, it won't. the entries fate-share with the other entries in the same JP message. I have enclosed the draft a few of us have been working on. We don't want to change too much. The JP-Ack proposal below simply adds a new message type with the same encoding as the JP message. >> [2]: It does not have the advantage of using a Multicast address and >> will also increase the processing on the upstream router. Imagine if Right, and what if not all TCP connections are up at the same time? And what if you wanted to take advantage of Join-Suppression? >> [3]: Can you elaborate on this? Is this something similar to what I am >> suggesting or something else? I think it is close. I will read through all of your proposal though. What the checksum/version idea is to capture the entire downstream router's join/prune state with a checksum value which is periodically sent at the 1 minute JP transmission interval instead of a full set of JP messages. As incremental Joins or Prunes are sent between the periodic message sending, the checksum is updated. If an incremental message is lost, the next periodic interval will catch it with a checksum/version mismatch. So in this case the retransmission delay is *equivalent* to what we have today (not better). >> I volunteer to co-author any proposal this group accepts. Cool. Thanks. Dino ------------------------------------------------------------------------------- JP-Ack Proposal (for reducing periodic JP messages in PIM) ---------------------------------------------------------- [1] Introduce a JP-Ack PIM message. It is always multicasted to 224.0.0.13 or ff02::d. Contains same format as JP message. [2] JP-Ack-Capable routers indicate they can send and receive JP-Acks by including JP-Ack Hello Option in Hello messages. [3] What JP senders do: o When they send JPs to an upstream router which is JP-Ack-Capable, they set a Ack-Received flag to FALSE for each route that is inserted in the join- or prune-list portion of the JP. o Then start a 1 second jittered retransmission timer. Retransmission occur until the upstream router disappears from the neighbor cache. The retransmission timer can optionally be altered but cannot exceed 60 seconds (the default periodic interval). o When the timer expires, build JP for all routes with the Ack-Received flag set to FALSE. o When the 1 minute periodic JP interval expires, only include routes which have the Ack-Received flag set to FALSE. [4] What JP-Ack senders do: o After a received JP is processed, modify the type field to turn the message into a JP-Ack. No other fields change in the PIM payload message other than the type and checksum fields. o For each route in the JP, set Ack-Sent flag to TRUE. This signifies that any oif-list entry will not time out regardless of the holdtime value sent in the JP. This allows the JP transmitter to not worry about refreshing the route. [5] What do receivers of JP-Acks do: o Regardless if you sent an JP or not, for each entry in the JP which you have state for, set the Ack-Received flag to TRUE so at the next periodic interval, the route is not included in a periodic JP. During steady-state, there will be no routes with Ack-Received equal to FALSE, so no JPs are sent. [6] What about triggered JPs? o When new state is created, the Ack-Received flag is set to FALSE, so a JP message is triggered. And will later be JP-Ack'ed. o When an RPF change occurs, for each route that is affected, set the Ack-Received flag to FALSE and trigger a JP. [7] What happens when a joiner goes down? o When a single joiner goes down, you want the upstream router to start timing out routes. o When there is more than one joiner, and a joiner goes down, you want to make sure timeout-suppression still occurs. o Whenever a PIM neighbor goes down, upstream routers will set the Ack-Sent flag to FALSE which will cause timeout processing to start. o Whenever a PIM neighbor goes down, downstream routers will set the Ack-Received flag to FALSE which will cause periodic processing to start. Which means when the 1 minute periodic interval expires, JPs will be sent. This will scatter the JPs across a jittered 1 minute periodic interval. o If, from an upstream router's perspective, a downstream neighbor times out but the downstream neighbor thinks the upstream router is alive (an issue with one-way connectivity), the upstream router should send a triggered Hello with a new GENID value. This will cause the downstream router to detect an adjacency change. In this case, the downstream router will send a full set of JPs. This is necessary so upstream router does not time out oifs when the downstream neighbor thinks it doesn't need to send a JP message. It is important to note that the Hello be unicast with a GENID value of 0. The Hello is unicast so other neighbors on the LAN don't get involved in sending JPs. The reason for a GENID value of 0, is so the downstream router can get solicited to build a full set of JP messages. When the next hello interval expires, the upstream router will transmit a Hello with a GENID equal to it's last value. This way other neighbors don't think there is a neighbor up/down transition. [8] Changing an entry for join-state to prune-state: o When a prune-entry (negative cache state entry) has an empty oif-list which goes to non-empty, a Join will be triggered, in this case the Ack-Received flag is set to FALSE so the Join can be sent reliably and the now join-entry can be suppressed from future JPs. o When a join-entry which has an non-empty oif-list goes to empty, a Prune will be triggered, in this case the Ack-Received flag is set to FALSE so the Prune can be sent reliably and the now prune-entry can be suppressed from future JPs. o In the case an entry changes from a join-entry to a prune-entry or vice versa before an JP-Ack is received for the previous state should cause no problem since the JP sender only cares about the latest state it has. If a JP-Ack is returned for a entry that is in the Join-list but the cached state is a prune-entry (or in the Prune-list for a cached join-entry), the Ack-Received flag is not touched (this is an old Ack). o In the case a JP sequence (3 separate JP messages) consists of a {Join, Prune, Join} for the same multicast route, if the an JP-Ack for the first JP-Join message is received by the downstream router after it had sent the third JP Join message, the downstream router would not ever retransmit a JP-Join message. In the case, the third JP-Join message was lost, the upstream router would have prune-state where the downstream router would have join-state. To avoid this situation, an implementation can delay sending the third JP-Join awaiting the JP-Ack for the first JP-Join. The same situation occurs with a JP sequence of {Prune, Join, Prune} for the same multicast route. In this case, the upstream router keeps forwarding data since it has join-state but the downstream router has prune-state. This situation should be rare since the rate of a multicast route flap would most likely be greater than a JP retransmission interval. [9] Duplicate JP-Acks and JPs: o If a JP-Ack is received for a set of routes which already have the Ack-Received flag set to TRUE, no action is taken. This is known as a duplicate JP-Ack. This is the case where a router on a multi-access LAN either didn't received the JP-Ack or it's JP was not received by the upstream router. So a retransmission of either had occurred. o If a JP-Ack is received for a route where the JP-Ack has a prune-list entry for the route but the route has join-state (oif-list not empty), then the Ack-Received flag should be set to FALSE so retransmission of a Join can happen. The converse is true if the JP-Ack had a join-list entry for a route in prune-state (oif-list that is empty). This can happen when a route transition from join-state to prune-state (or vice- versa) occurs and either the JPs or the JP-Acks were reordered. o If an upstream router receives a JP for a set of routes which already have the Ack-Sent flag set to TRUE, a JP-Ack should be returned. This is a case where a downstream router didn't not receive the previously sent JP-Ack or has triggered a JP it wants an JP-Ack for. [10] RPF Changes: o When an RPF neighbor change occurs, a JP with join-list entries is sent to the newly determined RPF neighbor. It is optional to also send a JP with prune-list entries to the previous RPF neighbor. In the later case, while the JP-prune-list sender is waiting for a JP-Ack from the previous RPF neighbor, other RPF change could occur. An implementation has to remember the previous RPF neighbors so it can make sure the prune-list JP gets reliably sent. [11] Dealing with Prune-Override on multi-access LANs: o On multi-access LAN, a downstream router that is pruning for a multicast route will multicast the JP message on the LAN. The upstream router will delay removing the oif from the multicast route waiting for other downstream routers to override the Prune with a Join message. To make this sequence reliable would require a total of 4 messages. The initial JP-Prune triggers the sequence from the downstream router, the upstream router responds with a JP-Ack multicast to the LAN, then an overriding router (if one exists) will send a multicast JP-Join which causes the upstream router to return a JP-Ack for the Join. o The reliability problem occurs because an overriding router may not see the triggering JP-Prune or the upstream router's JP-Ack. Even though the overriding router has 2 chances to send the Join to override the Prune, both messages could be lost during a congestion period. Since the join-state in the downstream router had previously been acknowledged by the upstream router, the downstream router would never send the Join again. o There are two solutions to the problem, (1) Upstream Router Join Solicitation or (2) Explicit Tracking. o Upstream Router Join Solicitation is when the upstream router will forward the received JP-Prune back out the multi-access LAN and require JP-Acks from each downstream neighbor regardless if they want to Prune- override or not. This assures that all neighbors have the chance to send their Joins. In this case, not all neighbors have to send Joins. The Join suppression mechanism from the base PIM spec can be used. o Explicit Tracking is when the upstream router keeps track of each neighbor who has Joined for a particular multicast route. So when a JP-Prune is sent to the upstream router, it knows when the last Joiner stops joining. In this case, only the JP-Prune needs to be JP-Acked and the oif is removed from the multicast route only when the last Joiner sends a Prune. This will trade-off memory for less messages on the LAN. o We propose when Explicit Tracking is used, that each router on the LAN advertise the fact in a PIM Hello option. This allows the downstream routers to tell the upstream router not to expect Prune-override messages. Also it tells the upstream router that the downstream routers will not be doing Join Suppression (each downstream router must send Joins so the upstream router can explicitly track each one). ------------------------------------------------------------------------------- From rkebler@avici.com Wed Dec 15 19:08:08 2004 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id iBG088PI047037 for ; Wed, 15 Dec 2004 19:08:08 -0500 (EST) (envelope-from rkebler@avici.com) Received: from rkebler-pc (rkebler-pc.avici.com [10.2.20.48]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iBG07q4I016886; Wed, 15 Dec 2004 19:07:52 -0500 Message-Id: <4.2.0.58.20041215182440.00cc5b70@mailhost.avici.com> X-Sender: rkebler@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 15 Dec 2004 19:16:12 -0500 To: Dino Farinacci , From: Robert Kebler Subject: Re: [Pim-state] Proposal In-Reply-To: <200412151947.iBFJlC520986@dino-lnx.cisco.com> References: <039001c4e279$876bb6c0$4abb16ac@alcatelxp> <039001c4e279$876bb6c0$4abb16ac@alcatelxp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 16 Dec 2004 00:08:09 -0000 Dino, I have comments to your draft inline. I will volunteer to help out on co-authoring the accepted proposal. Thanks, Bob >--------------------------------------------------------------------------- >---- > > JP-Ack Proposal (for reducing periodic JP messages in PIM) > ---------------------------------------------------------- > >[1] Introduce a JP-Ack PIM message. It is always multicasted to 224.0.0.13 or > ff02::d. Contains same format as JP message. > >[2] JP-Ack-Capable routers indicate they can send and receive JP-Acks by > including JP-Ack Hello Option in Hello messages. > >[3] What JP senders do: > > o When they send JPs to an upstream router which is JP-Ack-Capable, they > set a Ack-Received flag to FALSE for each route that is inserted in > the > join- or prune-list portion of the JP. > > o Then start a 1 second jittered retransmission timer. Retransmission > occur until the upstream router disappears from the neighbor cache. > The > retransmission timer can optionally be altered but cannot exceed 60 > seconds (the default periodic interval). 1 second interval seems too fast. I think we should at least recommend an exponential backoff mechanism. > o When the timer expires, build JP for all routes with the Ack-Received > flag set to FALSE. > > o When the 1 minute periodic JP interval expires, only include routes > which have the Ack-Received flag set to FALSE. Is the 1 minute periodic JP interval needed for this proposal? >[4] What JP-Ack senders do: > > o After a received JP is processed, modify the type field to turn the > message into a JP-Ack. No other fields change in the PIM payload > message > other than the type and checksum fields. Are bad Joins acknowledged? For example, a Join to a non-Multicast group? If the upstream does not acknowledge them, then the downstream will keep resending if it believes it to be a valid join. > o For each route in the JP, set Ack-Sent flag to TRUE. This signifies > that > any oif-list entry will not time out regardless of the holdtime value > sent in the JP. This allows the JP transmitter to not worry about > refreshing the route. > >[5] What do receivers of JP-Acks do: > > o Regardless if you sent an JP or not, for each entry in the JP which > you have state for, set the Ack-Received flag to TRUE so at the next > periodic interval, the route is not included in a periodic JP. During > steady-state, there will be no routes with Ack-Received equal to > FALSE, > so no JPs are sent. ...assuming ACK came from correct RPF neighbor. >[6] What about triggered JPs? > > o When new state is created, the Ack-Received flag is set to FALSE, so a > JP message is triggered. And will later be JP-Ack'ed. > > o When an RPF change occurs, for each route that is affected, set the > Ack-Received flag to FALSE and trigger a JP. > >[7] What happens when a joiner goes down? > > o When a single joiner goes down, you want the upstream router to start > timing out routes. > > o When there is more than one joiner, and a joiner goes down, you want to > make sure timeout-suppression still occurs. > > o Whenever a PIM neighbor goes down, upstream routers will set the > Ack-Sent > flag to FALSE which will cause timeout processing to start. > > o Whenever a PIM neighbor goes down, downstream routers will set the > Ack-Received flag to FALSE which will cause periodic processing to > start. Which means when the 1 minute periodic interval expires, JPs > will be sent. This will scatter the JPs across a jittered 1 minute > periodic interval. > > o If, from an upstream router's perspective, a downstream neighbor times > out but the downstream neighbor thinks the upstream router is alive > (an issue with one-way connectivity), the upstream router should > send a triggered Hello with a new GENID value. This will cause the > downstream router to detect an adjacency change. In this case, the > downstream router will send a full set of JPs. This is necessary so > upstream router does not time out oifs when the downstream neighbor > thinks it doesn't need to send a JP message. > > It is important to note that the Hello be unicast with a GENID value of > 0. The Hello is unicast so other neighbors on the LAN don't get > involved > in sending JPs. The reason for a GENID value of 0, is so the downstream > router can get solicited to build a full set of JP messages. When the > next hello interval expires, the upstream router will transmit a Hello > with a GENID equal to it's last value. This way other neighbors don't > think there is a neighbor up/down transition. > >[8] Changing an entry for join-state to prune-state: > > o When a prune-entry (negative cache state entry) has an empty oif-list > which goes to non-empty, a Join will be triggered, in this case the > Ack-Received flag is set to FALSE so the Join can be sent reliably and > the now join-entry can be suppressed from future JPs. > > o When a join-entry which has an non-empty oif-list goes to empty, a > Prune > will be triggered, in this case the Ack-Received flag is set to > FALSE so > the Prune can be sent reliably and the now prune-entry can be > suppressed > from future JPs. > > o In the case an entry changes from a join-entry to a prune-entry or > vice versa before an JP-Ack is received for the previous state should > cause no problem since the JP sender only cares about the latest state > it has. If a JP-Ack is returned for a entry that is in the Join-list > but the cached state is a prune-entry (or in the Prune-list for a > cached join-entry), the Ack-Received flag is not touched (this is > an old > Ack). > > o In the case a JP sequence (3 separate JP messages) consists of a > {Join, > Prune, Join} for the same multicast route, if the an JP-Ack for the > first > JP-Join message is received by the downstream router after it had > sent the third JP Join message, the downstream router would not ever > retransmit a JP-Join message. In the case, the third JP-Join message > was lost, the upstream router would have prune-state where the > downstream > router would have join-state. To avoid this situation, an > implementation > can delay sending the third JP-Join awaiting the JP-Ack for the first > JP-Join. > > The same situation occurs with a JP sequence of {Prune, Join, > Prune} for > the same multicast route. In this case, the upstream router keeps > forwarding data since it has join-state but the downstream router has > prune-state. > > This situation should be rare since the rate of a multicast route flap > would most likely be greater than a JP retransmission interval. One way to fix this is to have sequence number. The Join messages could have an sequence number and then the ACKs will specify the sequence number that they are ACKing. This seems like a hole that needs fixing. I think with this method you could have much smaller ACKs. A sequence number could be acknowledged, instead of listing out all of the individual entries. >[9] Duplicate JP-Acks and JPs: > > o If a JP-Ack is received for a set of routes which already have the > Ack-Received flag set to TRUE, no action is taken. This is known as > a duplicate JP-Ack. This is the case where a router on a multi-access > LAN either didn't received the JP-Ack or it's JP was not received > by the > upstream router. So a retransmission of either had occurred. > > o If a JP-Ack is received for a route where the JP-Ack has a prune-list > entry for the route but the route has join-state (oif-list not empty), > then the Ack-Received flag should be set to FALSE so retransmission > of a Join can happen. The converse is true if the JP-Ack had a > join-list > entry for a route in prune-state (oif-list that is empty). This can > happen when a route transition from join-state to prune-state (or vice- > versa) occurs and either the JPs or the JP-Acks were reordered. > > o If an upstream router receives a JP for a set of routes which already > have the Ack-Sent flag set to TRUE, a JP-Ack should be returned. This > is a case where a downstream router didn't not receive the previously > sent JP-Ack or has triggered a JP it wants an JP-Ack for. > >[10] RPF Changes: > > o When an RPF neighbor change occurs, a JP with join-list entries is sent > to the newly determined RPF neighbor. It is optional to also send a > JP with prune-list entries to the previous RPF neighbor. In the later > case, while the JP-prune-list sender is waiting for a JP-Ack from the > previous RPF neighbor, other RPF change could occur. An implementation > has to remember the previous RPF neighbors so it can make sure the > prune-list JP gets reliably sent. The Sparse Draft indicates on an RPF change, a Prune is sent to the old neighbor and a Join to the new neighbor. To be consistent with that spec, this could say that a Prune is sent but not necessarily reliably. You could have some indication that a JP msg does not need to be ACKed. >[11] Dealing with Prune-Override on multi-access LANs: > > o On multi-access LAN, a downstream router that is pruning for a > multicast > route will multicast the JP message on the LAN. The upstream router > will delay removing the oif from the multicast route waiting for other > downstream routers to override the Prune with a Join message. To make > this sequence reliable would require a total of 4 messages. The initial > JP-Prune triggers the sequence from the downstream router, the upstream > router responds with a JP-Ack multicast to the LAN, then an overriding > router (if one exists) will send a multicast JP-Join which causes the > upstream router to return a JP-Ack for the Join. > > o The reliability problem occurs because an overriding router may not see > the triggering JP-Prune or the upstream router's JP-Ack. Even though > the overriding router has 2 chances to send the Join to override the > Prune, both messages could be lost during a congestion period. Since > the join-state in the downstream router had previously been > acknowledged > by the upstream router, the downstream router would never send the Join > again. > > o There are two solutions to the problem, (1) Upstream Router Join > Solicitation or (2) Explicit Tracking. > > o Upstream Router Join Solicitation is when the upstream router will > forward the received JP-Prune back out the multi-access LAN and require > JP-Acks from each downstream neighbor regardless if they want to Prune- > override or not. This assures that all neighbors have the chance to > send their Joins. In this case, not all neighbors have to send Joins. > The Join suppression mechanism from the base PIM spec can be used. > > o Explicit Tracking is when the upstream router keeps track of each > neighbor who has Joined for a particular multicast route. So when a > JP-Prune is sent to the upstream router, it knows when the last Joiner > stops joining. In this case, only the JP-Prune needs to be JP-Acked > and the oif is removed from the multicast route only when the last > Joiner sends a Prune. This will trade-off memory for less messages on > the LAN. > > o We propose when Explicit Tracking is used, that each router on the LAN > advertise the fact in a PIM Hello option. This allows the downstream > routers to tell the upstream router not to expect Prune-override > messages. Also it tells the upstream router that the downstream routers > will not be doing Join Suppression (each downstream router must send > Joins so the upstream router can explicitly track each one). Explicit tracking could be a required part of this draft, in which case, the JP-Ack Hello option would indicate the Explicit tracking capability. I think it may help to indicate in order to run this protocol on an interface, all neighbors must be capable on that interface. Is this what you intended? I think section 7 can be removed if we make this requirement. If a neighbor goes down due to its Hello messages timed out, we remove that neighbor. If there are any other neighbors that have sent Joins then we keep the downstream list. If not, we can remove the interface from the downstream list. >--------------------------------------------------------------------------- >---- >_______________________________________________ >Pim-state mailing list >Pim-state@mountain2sea.com >http://www.mountain2sea.com/mailman/listinfo/pim-state From suresh.boddapati@alcatel.com Thu Dec 16 01:59:45 2004 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id iBG6xiU2047695 for ; Thu, 16 Dec 2004 01:59:44 -0500 (EST) (envelope-from suresh.boddapati@alcatel.com) Received: from alcatelxp ([172.22.187.74] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Dec 2004 22:59:35 -0800 From: "Suresh Boddapati" To: "'Dino Farinacci'" Subject: RE: [Pim-state] Proposal Date: Wed, 15 Dec 2004 23:01:11 -0800 Organization: Alcatel USA Message-ID: <03d601c4e33d$07f36b80$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <200412151947.iBFJlC520986@dino-lnx.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 16 Dec 2004 06:59:35.0212 (UTC) FILETIME=[CD1EFEC0:01C4E33C] Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: suresh.boddapati@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 16 Dec 2004 06:59:45 -0000 I think it is close. I will read through all of your proposal though. SURESH: Thanks. Looking forward to your comments. I have a few comments inline on your proposal. JP-Ack Proposal (for reducing periodic JP messages in PIM) ---------------------------------------------------------- [1] Introduce a JP-Ack PIM message. It is always multicasted to 224.0.0.13 or ff02::d. Contains same format as JP message. SURESH: Why multicast? Why not unicast? Why should one downstream router care if another downstream router goes down. In my proposal, I make this a unicast ACK. The reason behind this is:As long as I have received an ACK from the upstream router, it will not take out the state until I tell it to, because it keeps an association between the downstream state and set of Message IDs (more on this below). [3] What JP senders do: o When they send JPs to an upstream router which is JP-Ack-Capable, they set a Ack-Received flag to FALSE for each route that is inserted in the join- or prune-list portion of the JP. o Then start a 1 second jittered retransmission timer. Retransmission occur until the upstream router disappears from the neighbor cache. The retransmission timer can optionally be altered but cannot exceed 60 seconds (the default periodic interval). SURESH: In my scheme, I have a retransmission interval that backs off exponentially. So best case is the smallest value, worst case is what it is today. [4] What JP-Ack senders do: o After a received JP is processed, modify the type field to turn the message into a JP-Ack. No other fields change in the PIM payload message other than the type and checksum fields. o For each route in the JP, set Ack-Sent flag to TRUE. This signifies that any oif-list entry will not time out regardless of the holdtime value sent in the JP. This allows the JP transmitter to not worry about refreshing the route. SURESH: I don't see why an ACK has to be per entry. Making it per message is better IMO. My scheme does this. [5] What do receivers of JP-Acks do: o Regardless if you sent an JP or not, for each entry in the JP which you have state for, set the Ack-Received flag to TRUE so at the next periodic interval, the route is not included in a periodic JP. During steady-state, there will be no routes with Ack-Received equal to FALSE, so no JPs are sent. SURESH: Is the goal refresh reduction or refresh elimination? Refresh elimination creates more issues some of which you have listed (like persisting states at upstream routers if Prunes are lost). Seems like we can do away with the issues by just reducing the refreshes, not eliminating them. My scheme uses another message type PIM JP Refresh which refreshes just the Message IDs. If refreshes are not received, the upstream router automatically ages out the states represented by the Message ID (see below). [7] What happens when a joiner goes down? o When a single joiner goes down, you want the upstream router to start timing out routes. o When there is more than one joiner, and a joiner goes down, you want to make sure timeout-suppression still occurs. o Whenever a PIM neighbor goes down, upstream routers will set the Ack-Sent flag to FALSE which will cause timeout processing to start. o Whenever a PIM neighbor goes down, downstream routers will set the Ack-Received flag to FALSE which will cause periodic processing to start. Which means when the 1 minute periodic interval expires, JPs will be sent. This will scatter the JPs across a jittered 1 minute periodic interval. o If, from an upstream router's perspective, a downstream neighbor times out but the downstream neighbor thinks the upstream router is alive (an issue with one-way connectivity), the upstream router should send a triggered Hello with a new GENID value. This will cause the downstream router to detect an adjacency change. In this case, the downstream router will send a full set of JPs. This is necessary so upstream router does not time out oifs when the downstream neighbor thinks it doesn't need to send a JP message. It is important to note that the Hello be unicast with a GENID value of 0. The Hello is unicast so other neighbors on the LAN don't get involved in sending JPs. The reason for a GENID value of 0, is so the downstream router can get solicited to build a full set of JP messages. When the next hello interval expires, the upstream router will transmit a Hello with a GENID equal to it's last value. This way other neighbors don't think there is a neighbor up/down transition. SURESH: Goes back to my comment for (1). My scheme keeps it independent of downstream routers going down. The Message ID association is known only to an upstream, downstream router pair and has no relevance to another downstream router. Your scheme would create a new relation between a nbr timing out i.e. the Hello FSM and an (unrelated) upstream Join/Prune FSM. Seems like something that can be avoided. [8] Changing an entry for join-state to prune-state: o When a prune-entry (negative cache state entry) has an empty oif-list which goes to non-empty, a Join will be triggered, in this case the Ack-Received flag is set to FALSE so the Join can be sent reliably and the now join-entry can be suppressed from future JPs. o When a join-entry which has an non-empty oif-list goes to empty, a Prune will be triggered, in this case the Ack-Received flag is set to FALSE so the Prune can be sent reliably and the now prune-entry can be suppressed from future JPs. o In the case an entry changes from a join-entry to a prune-entry or vice versa before an JP-Ack is received for the previous state should cause no problem since the JP sender only cares about the latest state it has. If a JP-Ack is returned for a entry that is in the Join-list but the cached state is a prune-entry (or in the Prune-list for a cached join-entry), the Ack-Received flag is not touched (this is an old Ack). o In the case a JP sequence (3 separate JP messages) consists of a {Join, Prune, Join} for the same multicast route, if the an JP-Ack for the first JP-Join message is received by the downstream router after it had sent the third JP Join message, the downstream router would not ever retransmit a JP-Join message. In the case, the third JP-Join message was lost, the upstream router would have prune-state where the downstream router would have join-state. To avoid this situation, an implementation can delay sending the third JP-Join awaiting the JP-Ack for the first JP-Join. The same situation occurs with a JP sequence of {Prune, Join, Prune} for the same multicast route. In this case, the upstream router keeps forwarding data since it has join-state but the downstream router has prune-state. This situation should be rare since the rate of a multicast route flap would most likely be greater than a JP retransmission interval. SURESH: My scheme uses sequence numbers, where the latest sequence number will represent the aggregate of the changes from the point where the last sequence number was acked. So if sequence number X was acked and (X+1), (X+2), (X+3) are the {Join, Prune, Join} or {Prune, Join, Prune}, then (X+3) will represent {Join} and {Prune} respectively. [11] Dealing with Prune-Override on multi-access LANs: o On multi-access LAN, a downstream router that is pruning for a multicast route will multicast the JP message on the LAN. The upstream router will delay removing the oif from the multicast route waiting for other downstream routers to override the Prune with a Join message. To make this sequence reliable would require a total of 4 messages. The initial JP-Prune triggers the sequence from the downstream router, the upstream router responds with a JP-Ack multicast to the LAN, then an overriding router (if one exists) will send a multicast JP-Join which causes the upstream router to return a JP-Ack for the Join. o The reliability problem occurs because an overriding router may not see the triggering JP-Prune or the upstream router's JP-Ack. SURESH: So there will be another event "SEE ACK" similar to "SEE PRUNE" and "SEE JOIN" in the downstream router's JP FSM? Even though the overriding router has 2 chances to send the Join to override the Prune, both messages could be lost during a congestion period. Since the join-state in the downstream router had previously been acknowledged by the upstream router, the downstream router would never send the Join again. SURESH: Again, if you go with my scheme, the overriding router does not see the ACK. If everybody supports refresh reduction, the overriding router does not even have to override, because it has made an explicit registration with the upstream router that was acked. When the last router removes its association, the upstream router can remove the JP state as if the PrunePending timer expired. It would send the PruneEcho just in case as per the base spec. If the overriding router does not support refresh reduction, then it will simply override because it will not understand the Message ID TLV anyway. In my scheme, the upstream router will not have any Message ID to JP state association left but knows that there is at least one router that does not support refresh reduction. It will start the PrunePending timer at that point and wait for the override. Also, my scheme refreshes Message IDs using a PIM Refresh Message type, which are also acked. Again, IMO, our goal should be to reduce refreshes, not eliminate them. Refreshing keeps it time bound and will remove the state in cases like the ones you mention, instead of persisting them forever. Plus, like I listed in the draft, eliminating does not work well with snooping switches. L2 switches that snoop on PIM Messages rely on periodic updates. Although they will not understand Message ID Refreshes, my scheme does a periodic complete update (every 15 minutes is the proposal) so that flooding of multicast traffic can stop and snooping can be successful. o Explicit Tracking is when the upstream router keeps track of each neighbor who has Joined for a particular multicast route. So when a JP-Prune is sent to the upstream router, it knows when the last Joiner stops joining. In this case, only the JP-Prune needs to be JP-Acked and the oif is removed from the multicast route only when the last Joiner sends a Prune. This will trade-off memory for less messages on the LAN. o We propose when Explicit Tracking is used, that each router on the LAN advertise the fact in a PIM Hello option. This allows the downstream routers to tell the upstream router not to expect Prune-override messages. Also it tells the upstream router that the downstream routers will not be doing Join Suppression (each downstream router must send Joins so the upstream router can explicitly track each one). SURESH: Explicit tracking comes for "free" with my proposal, since we will be explicitly tracking MessageID to JP state associations. ------------------------------------------------------------------------ ------- From marshall.eubanks@gmail.com Thu Dec 16 08:13:49 2004 Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id iBGDDns9048566 for ; Thu, 16 Dec 2004 08:13:49 -0500 (EST) (envelope-from marshall.eubanks@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so1099841rnf for ; Thu, 16 Dec 2004 05:13:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=dDeswhw5kbH/3TjrLf/vT0tfx2GotEp4l4HQz6nZEjus0smf7t/v6vZq4xP+a0HpD2AVE/A+Qn0gYIEMi6X0x0C5gQTG/44Bck2LMKzVXCVbzMPCvX2fcnNlPnYh4rjTlzgzvjHky16yy7WnkokNuxwOH3hMPiDwjSRFvANbjkg= Received: by 10.38.181.65 with SMTP id d65mr3380571rnf; Thu, 16 Dec 2004 05:13:49 -0800 (PST) Received: by 10.38.208.48 with HTTP; Thu, 16 Dec 2004 05:13:49 -0800 (PST) Message-ID: Date: Thu, 16 Dec 2004 08:13:49 -0500 From: Marshall Eubanks To: suresh.boddapati@alcatel.com Subject: Re: [Pim-state] Proposal In-Reply-To: <03d601c4e33d$07f36b80$4abb16ac@alcatelxp> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200412151947.iBFJlC520986@dino-lnx.cisco.com> <03d601c4e33d$07f36b80$4abb16ac@alcatelxp> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: Marshall Eubanks List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 16 Dec 2004 13:13:49 -0000 On Wed, 15 Dec 2004 23:01:11 -0800, Suresh Boddapati wrote: > I think it is close. I will read through all of your proposal > though. > > SURESH: Thanks. Looking forward to your comments. I have a few comments > inline on your proposal. > > JP-Ack Proposal (for reducing periodic JP messages in PIM) > ---------------------------------------------------------- > > [1] Introduce a JP-Ack PIM message. It is always multicasted to > 224.0.0.13 or > ff02::d. Contains same format as JP message. > SURESH: Why multicast? Why not unicast? Why should one downstream router > care if another downstream router goes down. In my proposal, I make this > a unicast ACK. The reason behind this is:As long as I have received an > ACK from the upstream router, it will not take out the state until I > tell it to, because it keeps an association between the downstream state > and set of Message IDs (more on this below). > I don't understand why unicast. Wouldn't going to unicast introduce another layer of complexity ? If it is TCP, you have to worry about TCP time outs. Even if it is UDP, if you are at a border, then unicast traffic and multicast traffic can go out different interfaces (which certainly happens at domain boundaries), so should these be unicast messages that follow the multicast topology, like MSDP ? Also, should assert losers get a copy of this ACK ? It would seem that this is consistent with the recommendation of the PIM draft (that losers should keep state information to help convergence after a change in DR). If so, this is more complexity that could be avoided by keeping things multicast. Regards Marshall > [3] What JP senders do: > > o When they send JPs to an upstream router which is JP-Ack-Capable, > they > set a Ack-Received flag to FALSE for each route that is inserted > in the > join- or prune-list portion of the JP. > > o Then start a 1 second jittered retransmission timer. > Retransmission > occur until the upstream router disappears from the neighbor > cache. The > retransmission timer can optionally be altered but cannot exceed > 60 > seconds (the default periodic interval). > > > SURESH: In my scheme, I have a retransmission interval that backs off > exponentially. So best case is the smallest value, worst case is what it > is today. > > > [4] What JP-Ack senders do: > > o After a received JP is processed, modify the type field to turn > the > message into a JP-Ack. No other fields change in the PIM payload > message > other than the type and checksum fields. > > o For each route in the JP, set Ack-Sent flag to TRUE. This > signifies that > any oif-list entry will not time out regardless of the holdtime > value > sent in the JP. This allows the JP transmitter to not worry about > refreshing the route. > > SURESH: I don't see why an ACK has to be per entry. Making it per > message is better IMO. My scheme does this. > > [5] What do receivers of JP-Acks do: > > o Regardless if you sent an JP or not, for each entry in the JP > which > you have state for, set the Ack-Received flag to TRUE so at the > next > periodic interval, the route is not included in a periodic JP. > During > steady-state, there will be no routes with Ack-Received equal to > FALSE, > so no JPs are sent. > > SURESH: Is the goal refresh reduction or refresh elimination? Refresh > elimination creates more issues some of which you have listed (like > persisting states at upstream routers if Prunes are lost). Seems like we > can do away with the issues by just reducing the refreshes, not > eliminating them. My scheme uses another message type PIM JP Refresh > which refreshes just the Message IDs. If refreshes are not received, the > upstream router automatically ages out the states represented by the > Message ID (see below). > > [7] What happens when a joiner goes down? > > o When a single joiner goes down, you want the upstream router to > start > timing out routes. > > o When there is more than one joiner, and a joiner goes down, you > want to > make sure timeout-suppression still occurs. > > o Whenever a PIM neighbor goes down, upstream routers will set the > Ack-Sent > flag to FALSE which will cause timeout processing to start. > > o Whenever a PIM neighbor goes down, downstream routers will set the > Ack-Received flag to FALSE which will cause periodic processing to > > start. Which means when the 1 minute periodic interval expires, > JPs > will be sent. This will scatter the JPs across a jittered 1 minute > periodic interval. > > o If, from an upstream router's perspective, a downstream neighbor > times > out but the downstream neighbor thinks the upstream router is > alive > (an issue with one-way connectivity), the upstream router should > send a triggered Hello with a new GENID value. This will cause the > downstream router to detect an adjacency change. In this case, the > downstream router will send a full set of JPs. This is necessary > so > upstream router does not time out oifs when the downstream > neighbor > thinks it doesn't need to send a JP message. > > It is important to note that the Hello be unicast with a GENID > value of > 0. The Hello is unicast so other neighbors on the LAN don't get > involved > in sending JPs. The reason for a GENID value of 0, is so the > downstream > router can get solicited to build a full set of JP messages. When > the > next hello interval expires, the upstream router will transmit a > Hello > with a GENID equal to it's last value. This way other neighbors > don't > think there is a neighbor up/down transition. > > SURESH: Goes back to my comment for (1). My scheme keeps it independent > of downstream routers going down. The Message ID association is known > only to an upstream, downstream router pair and has no relevance to > another downstream router. Your scheme would create a new relation > between a nbr timing out i.e. the Hello FSM and an (unrelated) upstream > Join/Prune FSM. Seems like something that can be avoided. > > [8] Changing an entry for join-state to prune-state: > > o When a prune-entry (negative cache state entry) has an empty > oif-list > which goes to non-empty, a Join will be triggered, in this case > the > Ack-Received flag is set to FALSE so the Join can be sent reliably > and > the now join-entry can be suppressed from future JPs. > > o When a join-entry which has an non-empty oif-list goes to empty, a > Prune > will be triggered, in this case the Ack-Received flag is set to > FALSE so > the Prune can be sent reliably and the now prune-entry can be > suppressed > from future JPs. > > o In the case an entry changes from a join-entry to a prune-entry or > vice versa before an JP-Ack is received for the previous state > should > cause no problem since the JP sender only cares about the latest > state > it has. If a JP-Ack is returned for a entry that is in the > Join-list > but the cached state is a prune-entry (or in the Prune-list for a > cached join-entry), the Ack-Received flag is not touched (this is > an old > Ack). > > o In the case a JP sequence (3 separate JP messages) consists of a > {Join, > Prune, Join} for the same multicast route, if the an JP-Ack for > the first > JP-Join message is received by the downstream router after it had > sent the third JP Join message, the downstream router would not > ever > retransmit a JP-Join message. In the case, the third JP-Join > message > was lost, the upstream router would have prune-state where the > downstream > router would have join-state. To avoid this situation, an > implementation > can delay sending the third JP-Join awaiting the JP-Ack for the > first > JP-Join. > > The same situation occurs with a JP sequence of {Prune, Join, > Prune} for > the same multicast route. In this case, the upstream router keeps > forwarding data since it has join-state but the downstream router > has > prune-state. > > This situation should be rare since the rate of a multicast route > flap > would most likely be greater than a JP retransmission interval. > > SURESH: My scheme uses sequence numbers, where the latest sequence > number will represent the aggregate of the changes from the point where > the last sequence number was acked. So if sequence number X was acked > and (X+1), (X+2), (X+3) are the {Join, Prune, Join} or {Prune, Join, > Prune}, then (X+3) will represent {Join} and {Prune} respectively. > > [11] Dealing with Prune-Override on multi-access LANs: > > o On multi-access LAN, a downstream router that is pruning for a > multicast > route will multicast the JP message on the LAN. The upstream > router > will delay removing the oif from the multicast route waiting for > other > downstream routers to override the Prune with a Join message. To > make > this sequence reliable would require a total of 4 messages. The > initial > JP-Prune triggers the sequence from the downstream router, the > upstream > router responds with a JP-Ack multicast to the LAN, then an > overriding > router (if one exists) will send a multicast JP-Join which causes > the > upstream router to return a JP-Ack for the Join. > > o The reliability problem occurs because an overriding router may > not see > the triggering JP-Prune or the upstream router's JP-Ack. > > SURESH: So there will be another event "SEE ACK" similar to "SEE PRUNE" > and > "SEE JOIN" in the downstream router's JP FSM? > > Even though the overriding router has 2 chances to send the Join to > override the > Prune, both messages could be lost during a congestion period. > Since > the join-state in the downstream router had previously been > acknowledged > by the upstream router, the downstream router would never send the > Join > again. > > SURESH: Again, if you go with my scheme, the overriding router does not > see the ACK. If everybody supports refresh reduction, the overriding > router does not even have to override, because it has made an explicit > registration with > the upstream router that was acked. When the last router removes its > association, the upstream router can remove the JP state as if the > PrunePending timer expired. It would send the PruneEcho just in case as > per the base spec. If the overriding router does not support refresh > reduction, then it will simply override because it will not understand > the Message ID TLV anyway. In my scheme, the upstream router will not > have any Message ID to JP state association left but knows that there is > at least one router that does not support refresh reduction. It will > start the PrunePending timer at that point and wait for the override. > > Also, my scheme refreshes Message IDs using a PIM Refresh Message type, > which are also acked. Again, IMO, our goal should be to reduce > refreshes, not eliminate them. Refreshing keeps it time bound and will > remove the state in cases like the ones you mention, instead of > persisting them forever. > > Plus, like I listed in the draft, eliminating does not work well with > snooping switches. L2 switches that snoop on PIM Messages rely on > periodic > updates. Although they will not understand Message ID Refreshes, my > scheme does a periodic complete update (every 15 minutes is the > proposal) so that flooding of multicast traffic can stop and snooping > can be successful. > > > o Explicit Tracking is when the upstream router keeps track of each > neighbor who has Joined for a particular multicast route. So when > a > JP-Prune is sent to the upstream router, it knows when the last > Joiner > stops joining. In this case, only the JP-Prune needs to be > JP-Acked > and the oif is removed from the multicast route only when the last > > Joiner sends a Prune. This will trade-off memory for less messages > on > the LAN. > > o We propose when Explicit Tracking is used, that each router on the > LAN > advertise the fact in a PIM Hello option. This allows the > downstream > routers to tell the upstream router not to expect Prune-override > messages. Also it tells the upstream router that the downstream > routers > will not be doing Join Suppression (each downstream router must > send > Joins so the upstream router can explicitly track each one). > > SURESH: Explicit tracking comes for "free" with my proposal, since we > will be explicitly tracking MessageID to JP state associations. > > ------------------------------------------------------------------------ > ------- > > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state > From suresh.boddapati@alcatel.com Thu Dec 16 13:32:30 2004 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id iBGIWUwZ049133 for ; Thu, 16 Dec 2004 13:32:30 -0500 (EST) (envelope-from suresh.boddapati@alcatel.com) Received: from alcatelxp ([172.22.187.74] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 16 Dec 2004 10:32:21 -0800 From: "Suresh Boddapati" To: "'Marshall Eubanks'" Subject: RE: [Pim-state] Proposal Date: Thu, 16 Dec 2004 10:33:58 -0800 Organization: Alcatel USA Message-ID: <040401c4e39d$cfd9e1f0$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 16 Dec 2004 18:32:21.0223 (UTC) FILETIME=[9464EF70:01C4E39D] Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: suresh.boddapati@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 16 Dec 2004 18:32:31 -0000 I don't understand why unicast. Wouldn't going to unicast introduce another layer of complexity ? If it is TCP, you have to worry about TCP time outs. Even if it is UDP, if you are at a border, then unicast traffic and multicast traffic can go out different interfaces (which certainly happens at domain boundaries), so should these be unicast messages that follow the multicast topology, like MSDP ? SURESH: I never said TCP or UDP. Just raw IP, like we do for Register packets. The reason is simple. Consider an example on a LAN where there are 4 routers, D1, D2, U1, U2. Case 1: D1 sends M1D1 Message ID with Join for (S,G) to U1. D2 sends M1D2 for the same (S,G) to U1. U1 now has two associations. Per my scheme, if D1 wants to Prune M1D1, all it has to make sure is that the Prune got to U1. All U1 has to ensure is to make sure that its ACK got to U1. What will D2 do with the ACK that U1 sends D1. It's of no use to D2. D2 either supports Refresh reduction or does not. If it does, then it does not have to override the Prune because it has made an explicit association with U1 for its Join. If D2 does not support, it will override the Prune as per the base spec and the ACK will not make sense to it anyway. I wanted to avoid the ACK packet going to other downstream routers because there is no action for them to take. As for the IP addressing, the upstream router will send the ACK back to the downstream router only if the downstream router is a directly connected nbr (otherwise, there would not have been a JP Exchange in the first place). I am not sure if we need to worry about the case where the directly connected nbr is not reachable via the interface on which is connected but through another interface (the downstream router certainly needs to have a route to the upstream router for it to resolve RPFs), seems not a common case to me. Even if there is such a case, it really does not matter which path it takes, as long as the source address is U1's interface address that is connected to D1, because all the message says to D1 is that U1 got its message. Also, should assert losers get a copy of this ACK ? It would seem that this is consistent with the recommendation of the PIM draft (that losers should keep state information to help convergence after a change in DR). If so, this is more complexity that could be avoided by keeping things multicast. SURESH: No, assert losers need not get a copy of the ACK. All Assert is deciding is who the RPF neighbor is, which may be different from the mrib nhop. That FSM remains the same, and will figure out the upstream nbr appropriately. In my scheme, the messaging is for a given upstream nbr, so in the above example, if U1 is the mrib nhop and U2 is the assert winner, D1 will make a separate association with U2 for its JP state. This is exactly like in the base spec, U2 does not remember the Join D1 sent to U1. D1 sends a Join to U2 when RPF changes due to Assert. I would prefer to keep the ACK unicast if we can. Suresh From dino@cisco.com Thu Dec 30 20:40:08 2004 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id iBV1e8MQ088060 for ; Thu, 30 Dec 2004 20:40:08 -0500 (EST) (envelope-from dino@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 30 Dec 2004 18:49:47 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from dino-lnx.cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBV1dtl2027976; Thu, 30 Dec 2004 17:39:56 -0800 (PST) Received: (from dino@localhost) by dino-lnx.cisco.com (8.11.6/8.11.6) id iBV1dwJ09411; Thu, 30 Dec 2004 17:39:58 -0800 Date: Thu, 30 Dec 2004 17:39:58 -0800 Message-Id: <200412310139.iBV1dwJ09411@dino-lnx.cisco.com> From: Dino Farinacci To: rkebler@avici.com In-reply-to: <4.2.0.58.20041215182440.00cc5b70@mailhost.avici.com> (message from Robert Kebler on Wed, 15 Dec 2004 19:16:12 -0500) Subject: Re: [Pim-state] Proposal References: <039001c4e279$876bb6c0$4abb16ac@alcatelxp> <039001c4e279$876bb6c0$4abb16ac@alcatelxp> <4.2.0.58.20041215182440.00cc5b70@mailhost.avici.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 31 Dec 2004 01:40:09 -0000 >> Dino, >> I have comments to your draft inline. I will volunteer to help out on >> co-authoring >> the accepted proposal. Thanks all of Robert, Suresh, and Marshall for your comments. This email is a single response to all your emails. This is a long email. Robert>> > o Then start a 1 second jittered retransmission timer. Retransmission Robert>> > occur until the upstream router disappears from the neighbor cache. Robert>> > The Robert>> > retransmission timer can optionally be altered but cannot exceed 60 Robert>> > seconds (the default periodic interval). Robert>> Robert>> 1 second interval seems too fast. I think we should at least recommend an Robert>> exponential backoff mechanism. Fine and agree. We can fix this in the ID. Robert>> > o When the timer expires, build JP for all routes with the Ack-Received Robert>> > flag set to FALSE. Robert>> > Robert>> > o When the 1 minute periodic JP interval expires, only include routes Robert>> > which have the Ack-Received flag set to FALSE. Robert>> Robert>> Is the 1 minute periodic JP interval needed for this proposal? Yes, it is important because there may be entries that point to an upstream router who doesn't support this proposal. We are trying to support both models so you don't have to turn-key all routers on a LAN. Robert>> >[4] What JP-Ack senders do: Robert>> > Robert>> > o After a received JP is processed, modify the type field to turn the Robert>> > message into a JP-Ack. No other fields change in the PIM payload Robert>> > message Robert>> > other than the type and checksum fields. Robert>> Robert>> Are bad Joins acknowledged? For example, a Join to a non-Multicast Robert>> group? If the Robert>> upstream does not acknowledge them, then the downstream will keep resending if Robert>> it believes it to be a valid join. Yes, the semantics of the entries is not important. Since we don't want to change the packet format to add message-based sequence numbers, each entry will fate-share their reliability with other entries in the same message. Now for a message with a bad checksum, an JP-Ack should not be sent. I will add that to the spec. Robert>> >[5] What do receivers of JP-Acks do: Robert>> > Robert>> > o Regardless if you sent an JP or not, for each entry in the JP which Robert>> > you have state for, set the Ack-Received flag to TRUE so at the next Robert>> > periodic interval, the route is not included in a periodic JP. During Robert>> > steady-state, there will be no routes with Ack-Received equal to Robert>> > FALSE, Robert>> > so no JPs are sent. Robert>> Robert>> ...assuming ACK came from correct RPF neighbor. Well, actually no, because if you have changed RPF neighbors, an JP-Ack for a prune-list JP may have come from an old RPF neighbor. But I would agree for a JP with join-list entries, if received from the not current RPF neighbor, can be ignored. I would go farther and say, that if you have the retransmission timer running and you change RPF neighbors, any join-state entries can have the timer canceled (or more likely restarted because you triggered a join to the new RPF neighbor). Robert>> > The same situation occurs with a JP sequence of {Prune, Join, Robert>> > Prune} for Robert>> > the same multicast route. In this case, the upstream router keeps Robert>> > forwarding data since it has join-state but the downstream router has Robert>> > prune-state. Robert> > Robert>> > This situation should be rare since the rate of a multicast route flap Robert>> > would most likely be greater than a JP retransmission interval. Robert>> Robert>> One way to fix this is to have sequence number. The Join messages could Robert>> have an Robert>> sequence number and then the ACKs will specify the sequence number that Robert>> they are Robert>> ACKing. This seems like a hole that needs fixing. Robert>> I think with this method you could have much smaller ACKs. A sequence Robert>> number could Robert>> be acknowledged, instead of listing out all of the individual entries. We didn't want to change the packet format so hence the current design. Yes, the JP-Acks would be smaller but you would then have to keep the sequence number with each entry and if the entry went from prune to join state and sent to one RPF neighbor for the prune and another RPF neighbor for the join you'd have to store multiple sequence numbers. So there are another set of problems as well. It is important to keep the per route state small. This design is using 2 bits per route entry (the ack-sent and ack-received flags). Robert>> >[10] RPF Changes: Robert>> > Robert>> > o When an RPF neighbor change occurs, a JP with join-list entries is sent Robert>> > to the newly determined RPF neighbor. It is optional to also send a Robert>> > JP with prune-list entries to the previous RPF neighbor. In the later Robert>> > case, while the JP-prune-list sender is waiting for a JP-Ack from the Robert>> > previous RPF neighbor, other RPF change could occur. An implementation Robert>> > has to remember the previous RPF neighbors so it can make sure the Robert>> > prune-list JP gets reliably sent. Robert>> Robert>> The Sparse Draft indicates on an RPF change, a Prune is sent to the old Robert>> neighbor and Robert>> a Join to the new neighbor. To be consistent with that spec, this could Robert>> say that Robert>> a Prune is sent but not necessarily reliably. You could have some Robert>> indication that a Robert>> JP msg does not need to be ACKed. Yes, realize this. But many are questioning if this is necessary. You make a good point but I would argue, if you don't want it reliable, then missing it isn't a big deal. And if it isn't a big deal, why send it in the first place. Robert>>> o We propose when Explicit Tracking is used, that each router on the LAN Robert>>> advertise the fact in a PIM Hello option. This allows the downstream Robert>>> routers to tell the upstream router not to expect Prune-override Robert>>> messages. Also it tells the upstream router that the downstream routers Robert>>> will not be doing Join Suppression (each downstream router must send Robert>>> Joins so the upstream router can explicitly track each one). Robert>> Robert>> Robert>>Explicit tracking could be a required part of this draft, in which case, Robert>>the JP-Ack Robert>>Hello option would indicate the Explicit tracking capability. Robert>>I think it may help to indicate in order to run this protocol on an Robert>>interface, all Robert>>neighbors must be capable on that interface. Is this what you intended? Yes, but ET does have per route/per oif memory implications. So we have struggled deciding if we should require it. Robert>>I think section 7 can be removed if we make this requirement. If a Robert>>neighbor goes down Robert>>due to its Hello messages timed out, we remove that neighbor. If there are Robert>>any Robert>>other neighbors that have sent Joins then we keep the downstream list. If Robert>>not, we can Robert>>remove the interface from the downstream list. Agree. We need to have the working group decide how to proceed on this. Suresh>> SURESH: Thanks. Looking forward to your comments. I have a few comments Suresh>> inline on your proposal. I will send them in a seperate email. Suresh>> SURESH: Why multicast? Why not unicast? Why should one downstream router Suresh>> care if another downstream router goes down. In my proposal, I make this Suresh>> a unicast ACK. The reason behind this is:As long as I have received an Suresh>> ACK from the upstream router, it will not take out the state until I Suresh>> tell it to, because it keeps an association between the downstream state Suresh>> and set of Message IDs (more on this below). Because we don't want to change the semantics of other downstream routers creating state. I have found with experience creating (S,G) with oif-list allows packets to be dropped in hardware rather than causing state to be created at data-plane time. Suresh>> SURESH: In my scheme, I have a retransmission interval that backs off Suresh>> exponentially. So best case is the smallest value, worst case is what it Suresh>> is today. The 1 second timer isn't a fixed design goal. But note, if you need to have different backoffs per entry then a retransmission timer per entry will be required. It's a memory/CPU tradeoff to use memory versus a scan. Plus, a per entry retransmission timer can't make use of entry aggregation per message. Suresh>> o For each route in the JP, set Ack-Sent flag to TRUE. This Suresh>> signifies that Suresh>> any oif-list entry will not time out regardless of the holdtime Suresh>> value Suresh>> sent in the JP. This allows the JP transmitter to not worry about Suresh>> refreshing the route. Suresh>> Suresh>> SURESH: I don't see why an ACK has to be per entry. Making it per Suresh>> message is better IMO. My scheme does this. Per message may be better looking at it from the "on-wire" point of view. But you still have the many-to-1 (i.e. multiple entries per message) to deal with (what I stated above). BGP doesn't have this problem because another layer (i.e. TCP) does this for it. IS-IS doesn't have this problem beacuse each entry (i.e. an LSP) has a sequence number. And OSPF uses a sequence number per LSA as well but can group them in an LS Update message. So this approach is more like OSPF but we don't need a sequence number because in most cases there are only two states, prune-state or join-state so this design can work. Suresh>> o Regardless if you sent an JP or not, for each entry in the JP Suresh>> which Suresh>> you have state for, set the Ack-Received flag to TRUE so at the Suresh>> next Suresh>> periodic interval, the route is not included in a periodic JP. Suresh>> During Suresh>> steady-state, there will be no routes with Ack-Received equal to Suresh>> FALSE, Suresh>> so no JPs are sent. Suresh>> Suresh>> SURESH: Is the goal refresh reduction or refresh elimination? Refresh Suresh>> elimination creates more issues some of which you have listed (like Suresh>> persisting states at upstream routers if Prunes are lost). Seems like we Suresh>> can do away with the issues by just reducing the refreshes, not Suresh>> eliminating them. My scheme uses another message type PIM JP Refresh Suresh>> which refreshes just the Message IDs. If refreshes are not received, the Suresh>> upstream router automatically ages out the states represented by the Suresh>> Message ID (see below). The goal is refresh elimination where you can. The goal for the VPN case is to reduce any type of periodic message (even Hellos) because in the VPN case, there can be 1000s of neighbors (reachable over possibly a single physical link). Suresh>> It is important to note that the Hello be unicast with a GENID Suresh>> value of Suresh>> 0. The Hello is unicast so other neighbors on the LAN don't get Suresh>> involved Suresh>> in sending JPs. The reason for a GENID value of 0, is so the Suresh>> downstream Suresh>> router can get solicited to build a full set of JP messages. When Suresh>> the Suresh>> next hello interval expires, the upstream router will transmit a Suresh>> Hello Suresh>> with a GENID equal to it's last value. This way other neighbors Suresh>> don't Suresh>> think there is a neighbor up/down transition. Suresh>> Suresh>> SURESH: Goes back to my comment for (1). My scheme keeps it independent Suresh>> of downstream routers going down. The Message ID association is known Suresh>> only to an upstream, downstream router pair and has no relevance to Suresh>> another downstream router. Your scheme would create a new relation Suresh>> between a nbr timing out i.e. the Hello FSM and an (unrelated) upstream Suresh>> Join/Prune FSM. Seems like something that can be avoided. These corner cases I listed could probably be solved with simpler mechanims. We just wanted to list them and haven't optimized on the solutions yet. Suresh>> The same situation occurs with a JP sequence of {Prune, Join, Suresh>> Prune} for Suresh>> the same multicast route. In this case, the upstream router keeps Suresh>> forwarding data since it has join-state but the downstream router Suresh>> has Suresh>> prune-state. Suresh>> Suresh>> This situation should be rare since the rate of a multicast route Suresh>> flap Suresh>> would most likely be greater than a JP retransmission interval. Suresh>> Suresh>> SURESH: My scheme uses sequence numbers, where the latest sequence Suresh>> number will represent the aggregate of the changes from the point where Suresh>> the last sequence number was acked. So if sequence number X was acked Suresh>> and (X+1), (X+2), (X+3) are the {Join, Prune, Join} or {Prune, Join, Suresh>> Prune}, then (X+3) will represent {Join} and {Prune} respectively. Right, we realize that sequence numbers will solve the problem. Suresh>> Even though the overriding router has 2 chances to send the Join to Suresh>> override the Suresh>> Prune, both messages could be lost during a congestion period. Suresh>> Since Suresh>> the join-state in the downstream router had previously been Suresh>> acknowledged Suresh>> by the upstream router, the downstream router would never send the Suresh>> Join Suresh>> again. Suresh>> Suresh>> SURESH: Again, if you go with my scheme, the overriding router does not Suresh>> see the ACK. If everybody supports refresh reduction, the overriding Suresh>> router does not even have to override, because it has made an explicit Suresh>> registration with Suresh>> the upstream router that was acked. When the last router removes its Suresh>> association, the upstream router can remove the JP state as if the Suresh>> PrunePending timer expired. It would send the PruneEcho just in case as Yes, explicit tracking solves this. But do you want to require it? And do you want to have a mix of old and new routers on a single LAN? That is where the hard decisions have to be made. Suresh>> per the base spec. If the overriding router does not support refresh Suresh>> reduction, then it will simply override because it will not understand Suresh>> the Message ID TLV anyway. In my scheme, the upstream router will not Suresh>> have any Message ID to JP state association left but knows that there is Suresh>> at least one router that does not support refresh reduction. It will Suresh>> start the PrunePending timer at that point and wait for the override. Suresh>> Suresh>> Also, my scheme refreshes Message IDs using a PIM Refresh Message type, Suresh>> which are also acked. Again, IMO, our goal should be to reduce Suresh>> refreshes, not eliminate them. Refreshing keeps it time bound and will Suresh>> remove the state in cases like the ones you mention, instead of Suresh>> persisting them forever. Just reducing them and not eliminating them will not be good enough. A few small messages when multiplied in the VPN case is still a lot of messages. If we can do the reliability at the instance of state change then we have optimized. However, if you talk about 1 million routes, there is a good chance that there will always be activity. So an Ack mechanism can only scale to a certain extent. Maybe a CSNP mechanism, even though periodic is better because a single router is sending the messages. And using handles for the routes allow you to encode ranges in the CSNP so the message can be made really small. Suresh>> Plus, like I listed in the draft, eliminating does not work well with Suresh>> snooping switches. L2 switches that snoop on PIM Messages rely on Suresh>> periodic Suresh>> updates. Although they will not understand Message ID Refreshes, my Suresh>> scheme does a periodic complete update (every 15 minutes is the Suresh>> proposal) so that flooding of multicast traffic can stop and snooping Suresh>> can be successful. Don't worry about PIM snooping switches, that is an over optimization. When you connect routers up to a switched network, it typically is one or two switches and not a large switched network (where IGMP-snooping is important to not waste bandwidth to host segments). Switches are high performance enough to replicate so they can just send to the router ports (and the routers throw packets away at line-rate). Suresh>> o We propose when Explicit Tracking is used, that each router on the Suresh>> LAN Suresh>> advertise the fact in a PIM Hello option. This allows the Suresh>> downstream Suresh>> routers to tell the upstream router not to expect Prune-override Suresh>> messages. Also it tells the upstream router that the downstream Suresh>> routers Suresh>> will not be doing Join Suppression (each downstream router must Suresh>> send Suresh>> Joins so the upstream router can explicitly track each one). Suresh>> Suresh>> SURESH: Explicit tracking comes for "free" with my proposal, since we Suresh>> will be explicitly tracking MessageID to JP state associations. ET is not free. But I have a feeling you are using on a per message basis which is less overhead. I'll get to your draft next. Marshall>> I don't understand why unicast. Marshall>> Marshall>> Wouldn't going to unicast introduce another layer of complexity ? If Marshall>> it is TCP, you have to worry Marshall>> about TCP time outs. Even if it is UDP, if you are at a border, then Marshall>> unicast traffic and multicast traffic can go out different interfaces Marshall>> (which certainly happens at domain boundaries), so should these be Marshall>> unicast messages that follow the multicast topology, like MSDP ? Marshall, Suresh is only talking about this for link-local purposes (however mVPNs change the assumption). Marshall>> Marshall>> Also, should assert losers get a copy of this ACK ? It would seem Marshall>> that this is consistent with Marshall>> the recommendation of the PIM draft (that losers should keep state Marshall>> information to help convergence after Marshall>> a change in DR). If so, this is more complexity that could be avoided Marshall>> by keeping things multicast. Well in this design, Assert losers will see the JP-Acks, so they have the option of keeping state if they wish too. Thanks all for the comments, Dino From dino@cisco.com Thu Dec 30 20:56:53 2004 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id iBV1uqcE088091 for ; Thu, 30 Dec 2004 20:56:52 -0500 (EST) (envelope-from dino@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 30 Dec 2004 18:03:51 -0800 Received: from dino-lnx.cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBV1uel2001963; Thu, 30 Dec 2004 17:56:40 -0800 (PST) Received: (from dino@localhost) by dino-lnx.cisco.com (8.11.6/8.11.6) id iBV1ujg09500; Thu, 30 Dec 2004 17:56:45 -0800 Date: Thu, 30 Dec 2004 17:56:45 -0800 Message-Id: <200412310156.iBV1ujg09500@dino-lnx.cisco.com> From: Dino Farinacci To: suresh.boddapati@alcatel.com In-reply-to: <040401c4e39d$cfd9e1f0$4abb16ac@alcatelxp> (suresh.boddapati@alcatel.com) Subject: Re: [Pim-state] Proposal References: <040401c4e39d$cfd9e1f0$4abb16ac@alcatelxp> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 31 Dec 2004 01:56:53 -0000 >> SURESH: I never said TCP or UDP. Just raw IP, like we do for Register >> packets. The reason is simple. Consider an example on a LAN where there >> are 4 routers, D1, D2, U1, U2. >> Case 1: D1 sends M1D1 Message ID with Join for (S,G) to U1. D2 sends >> M1D2 for the same (S,G) to U1. U1 now has two associations. Per my >> scheme, if D1 wants to Prune M1D1, all it has to make sure is that the >> Prune got to U1. All U1 has to ensure is to make sure that its ACK got >> to U1. What will D2 do with the ACK that U1 sends D1. It's of no use to >> D2. D2 either supports Refresh reduction or does not. If it does, then >> it does not have to override the Prune because it has made an explicit >> association with U1 for its Join. If D2 does not support, it will >> override the Prune as per the base spec and the ACK will not make sense >> to it anyway. I wanted to avoid the ACK packet going to other downstream >> routers because there is no action for them to take. Suresh, you do realize this requires another set of queuing on a per neighbor database. Where you can have state changing from the database and old state in messages on retransmission queues. In this problem space, you don't need to track every transition, but only the latest transition. BTW, in your example U1 sending to D1 and U2 sending to D2 is not a normal situation and is usually a case of broken unicast routing configuration (which Assert processing tries to fix, but people don't like using Assert processing). By the way JP-Acks are useful to third-party upstream and downstream routers. In fact, I was planning on using it as a way to suppress Asserting. So the assert single forwarderdecision could be done when an upstream router sees a join on an oif to another upstream router. 1) The Assert *could* be triggered at that time rather than at data forwarding time or 2) the upstream router could choose not to populate it's oif-list (to force a single direction for unicast routing). Dino From suresh.boddapati@alcatel.com Mon Jan 3 15:10:39 2005 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j03KAcIo098458 for ; Mon, 3 Jan 2005 15:10:38 -0500 (EST) (envelope-from suresh.boddapati@alcatel.com) Received: from alcatelxp ([172.22.187.74] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 3 Jan 2005 12:10:24 -0800 From: "Suresh Boddapati" To: "'Dino Farinacci'" , Subject: RE: [Pim-state] Proposal Date: Mon, 3 Jan 2005 12:08:34 -0800 Organization: Alcatel USA Message-ID: <030201c4f1d0$0252f820$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200412310139.iBV1dwJ09411@dino-lnx.cisco.com> Importance: Normal X-OriginalArrivalTime: 03 Jan 2005 20:10:24.0120 (UTC) FILETIME=[424F4780:01C4F1D0] Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: suresh.boddapati@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 03 Jan 2005 20:10:39 -0000 Comments inline. This one is long too. Suresh > Suresh>> SURESH: Why multicast? Why not unicast? Why should one downstream > router > Suresh>> care if another downstream router goes down. In my proposal, I > make this > Suresh>> a unicast ACK. The reason behind this is:As long as I have > received an > Suresh>> ACK from the upstream router, it will not take out the state > until I > Suresh>> tell it to, because it keeps an association between the > downstream state > Suresh>> and set of Message IDs (more on this below). > > Because we don't want to change the semantics of other downstream > routers > creating state. I have found with experience creating (S,G) with oif- > list > allows packets to be dropped in hardware rather than causing state to > be > created at data-plane time. How does my proposal change the semantics of other downstream routers creating state? All I am saying is that ACKs should be unicast, not the Joins. If D1 sends a Join to U1, D2 will see the Join. The Join being associated with a message M1 sent by D1 is what is being acked by U1 to D1. This information is not relevant to D2.D2 does not have to remember the association between M1 and the Join sent by D1. > > Suresh>> SURESH: In my scheme, I have a retransmission interval that backs > off > Suresh>> exponentially. So best case is the smallest value, worst case is > what it > Suresh>> is today. > > The 1 second timer isn't a fixed design goal. But note, if you need to > have different backoffs per entry then a retransmission timer per > entry > will be required. It's a memory/CPU tradeoff to use memory versus a > scan. > Plus, a per entry retransmission timer can't make use of entry > aggregation > per message. > Why do we need to have different backoffs per entry? I am not requiring retransmission timer per entry. If you read my proposal, I am talking about retransmission of a Join message (represented by an aggregate Message ID) until the message is acked. So if you have Joins for (S1,G1), (S2, G2), ... (Sn, Gn) in a Join Message and that is associated with Message ID M1, then the Join message along with the Message ID TLV will be retransmitted until the upstream router acks M1. Once M1 is acked, only M1 is refreshed using a new PDU type, not each entry. The memory required for creating an association between an entry and a message ID is not much. You can think of it as a list of (S,G)s associated with a message M and vice versa. The CPU savings are significant because now we need to run timers only for Messages, not each entry and less traffic on the wire. > Suresh>> o For each route in the JP, set Ack-Sent flag to TRUE. This > Suresh>> signifies that > Suresh>> any oif-list entry will not time out regardless of the > holdtime > Suresh>> value > Suresh>> sent in the JP. This allows the JP transmitter to not worry > about > Suresh>> refreshing the route. > Suresh>> > Suresh>> SURESH: I don't see why an ACK has to be per entry. Making it per > Suresh>> message is better IMO. My scheme does this. > > Per message may be better looking at it from the "on-wire" point of > view. > But you still have the many-to-1 (i.e. multiple entries per message) > to > deal with (what I stated above). > > BGP doesn't have this problem because another layer (i.e. TCP) does > this > for it. IS-IS doesn't have this problem beacuse each entry (i.e. an > LSP) > has a sequence number. And OSPF uses a sequence number per LSA as well > but > can group them in an LS Update message. > > So this approach is more like OSPF but we don't need a sequence number > because in most cases there are only two states, prune-state or join- > state > so this design can work. Hmm. I am not sure if you are agreeing with me or disagreeing with me here. We agree that it is better from the "on-wire" point of view. I lost you on the rest of your comments. What is the problem with many-to-1? Again, my scheme aggregates entries into a message represented by a Message ID TLV, and it is this TLV that has a sequence number which tracks changes to that message ID. Agreed there are two states Join and Prune, but there can be many entries with state change. So for example, if M1 represents {(S1,G1), (S2, G2),... (Sn, Gn)} and the sequence number is 1, if (S1,G1) decides to prune, we just send the regular Join as today with (S1,G1) Prune encoded. The Message ID TLV will also be included, but now it will have sequence number 2 and the I bit set which means that it is an incremental update to M1. The upstream router will ack back M1,seq.=2. Now if (S2,G2) and (S3,G3) get pruned and (Sp, Gp) is joined, it will be another JP message with these three entries, seq.=3, and I bit set, and so on... Everytime the upstream router gets the incremental update, it restarts the timer for the entire message, so we don't have to refresh all the remaining states. > > Suresh>> o Regardless if you sent an JP or not, for each entry in the > JP > Suresh>> which > Suresh>> you have state for, set the Ack-Received flag to TRUE so at > the > Suresh>> next > Suresh>> periodic interval, the route is not included in a periodic > JP. > Suresh>> During > Suresh>> steady-state, there will be no routes with Ack-Received > equal to > Suresh>> FALSE, > Suresh>> so no JPs are sent. > Suresh>> > Suresh>> SURESH: Is the goal refresh reduction or refresh elimination? > Refresh > Suresh>> elimination creates more issues some of which you have listed > (like > Suresh>> persisting states at upstream routers if Prunes are lost). Seems > like we > Suresh>> can do away with the issues by just reducing the refreshes, not > Suresh>> eliminating them. My scheme uses another message type PIM JP > Refresh > Suresh>> which refreshes just the Message IDs. If refreshes are not > received, the > Suresh>> upstream router automatically ages out the states represented by > the > Suresh>> Message ID (see below). > > The goal is refresh elimination where you can. > > The goal for the VPN case is to reduce any type of periodic message > (even > Hellos) because in the VPN case, there can be 1000s of neighbors > (reachable > over possibly a single physical link). Refresh elimination is not a good thing if you do not have hard state (like TCP). If you add reliability, you can always set the hold time to infinity and get rid of refreshes. We don't need a new scheme IMO. > Suresh>> Even though the overriding router has 2 chances to send the Join > to > Suresh>> override the > Suresh>> Prune, both messages could be lost during a congestion > period. > Suresh>> Since > Suresh>> the join-state in the downstream router had previously been > Suresh>> acknowledged > Suresh>> by the upstream router, the downstream router would never > send the > Suresh>> Join > Suresh>> again. > Suresh>> > Suresh>> SURESH: Again, if you go with my scheme, the overriding router > does not > Suresh>> see the ACK. If everybody supports refresh reduction, the > overriding > Suresh>> router does not even have to override, because it has made an > explicit > Suresh>> registration with > Suresh>> the upstream router that was acked. When the last router removes > its > Suresh>> association, the upstream router can remove the JP state as if > the > Suresh>> PrunePending timer expired. It would send the PruneEcho just in > case as > > Yes, explicit tracking solves this. But do you want to require it? And > do you want to have a mix of old and new routers on a single LAN? That > is where the hard decisions have to be made. I am not requiring explicit tracking (tracking as mentioned in the base spec). I am saying you will get it automatically if you go with my scheme. Do we want to support old and new routers on a single LAN? I don't see why not. My scheme is backwards compatible. It is upto an implementation if it wants to allow it or not. For example, if an upstream router sees that one of the downstream routers does not support Refresh reduction, it can resend its Hello with a new Gen ID without the refresh reduction support TLV. > > Just reducing them and not eliminating them will not be good enough. A > few small messages when multiplied in the VPN case is still a lot of > messages. If we can do the reliability at the instance of state change > then we have optimized. > > However, if you talk about 1 million routes, there is a good chance > that > there will always be activity. So an Ack mechanism can only scale to > a certain extent. > > Maybe a CSNP mechanism, even though periodic is better because a > single > router is sending the messages. And using handles for the routes allow > you to encode ranges in the CSNP so the message can be made really > small. The messages would still be small. The refresh message would carry Message IDs so the number of messages and acks would be more than an order smaller. Making it CSNP like increases the processing on all the downstream routers because now each downstream router would have to look at all states that others have as well. > Don't worry about PIM snooping switches, that is an over optimization. > When > you connect routers up to a switched network, it typically is one or > two > switches and not a large switched network (where IGMP-snooping is > important to not waste bandwidth to host segments). Switches are high > performance enough to replicate so they can just send to the router > ports (and the routers throw packets away at line-rate). Over optimization? What about L2 VPLS? All L2 VPNs would have to do snooping of some sort in order to reduce multicast traffic to the minimum required. There are already drafts floating around that try to address snooping issues in L2 VPLS. I don't think we can ignore snooping "systems" (not necessarily couple of switches on a switched network). > Suresh>> SURESH: Explicit tracking comes for "free" with my proposal, > since we > Suresh>> will be explicitly tracking MessageID to JP state associations. > > ET is not free. But I have a feeling you are using on a per message > basis which is less overhead. I'll get to your draft next. > Yes, it's on a per message basis. For an entry, if the upstream router remembers the list of Message IDs sent by different downstream routers, taking an association out does not mean anything unless it is the last association, which translates to no downstream router wanting traffic for that entry. In that case, the upstream router can just take out the entry and just send a Prune Echo on the wire (which it would do today after the expiration of the Prune Pending timer) From suresh.boddapati@alcatel.com Mon Jan 3 17:43:24 2005 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j03MhKgF098703 for ; Mon, 3 Jan 2005 17:43:24 -0500 (EST) (envelope-from suresh.boddapati@alcatel.com) Received: from alcatelxp ([172.22.187.74] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 3 Jan 2005 14:43:14 -0800 From: "Suresh Boddapati" To: "'Dino Farinacci'" Subject: RE: [Pim-state] Proposal Date: Mon, 3 Jan 2005 14:41:25 -0800 Organization: Alcatel USA Message-ID: <030b01c4f1e5$5c94ffd0$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200412310156.iBV1ujg09500@dino-lnx.cisco.com> Importance: Normal X-OriginalArrivalTime: 03 Jan 2005 22:43:14.0659 (UTC) FILETIME=[9C607B30:01C4F1E5] Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: suresh.boddapati@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 03 Jan 2005 22:43:24 -0000 > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Thursday, December 30, 2004 5:57 PM > To: suresh.boddapati@alcatel.com > Cc: marshall.eubanks@gmail.com; pim-state@mountain2sea.com > Subject: Re: [Pim-state] Proposal > > >> SURESH: I never said TCP or UDP. Just raw IP, like we do for Register > >> packets. The reason is simple. Consider an example on a LAN where there > >> are 4 routers, D1, D2, U1, U2. > >> Case 1: D1 sends M1D1 Message ID with Join for (S,G) to U1. D2 sends > >> M1D2 for the same (S,G) to U1. U1 now has two associations. Per my > >> scheme, if D1 wants to Prune M1D1, all it has to make sure is that the > >> Prune got to U1. All U1 has to ensure is to make sure that its ACK got > >> to U1. What will D2 do with the ACK that U1 sends D1. It's of no use to > >> D2. D2 either supports Refresh reduction or does not. If it does, then > >> it does not have to override the Prune because it has made an explicit > >> association with U1 for its Join. If D2 does not support, it will > >> override the Prune as per the base spec and the ACK will not make sense > >> to it anyway. I wanted to avoid the ACK packet going to other > downstream > >> routers because there is no action for them to take. > > Suresh, you do realize this requires another set of queuing on a per > neighbor database. Where you can have state changing from the database > and old state in messages on retransmission queues. Are we talking implementation details here? Look at it this way. If a Message has not been acked and there is a change to some entry in the message, all I am saying is that we bump up the sequence number and do a union of the current message state and the new state. It is this message with the higher sequence number that we want acked. So we always have to keep only one outstanding version of message, the latest one that has not yet been acked. A couple of examples for this (I am assuming you have gone through my draft): 1) M1 is a complete message (not an incremental one, I bit is not set). If we sent Joins for {(S1,G1), (S2, G2), (S3, G3)} with seq=1 and we have not received an ACK for M1, and now (S3, G3) is pruned and (S4, G4) is joined, then M1 will now be {(S1,G1)J, (S2, G2)J, (S4,G4)J, (S3, G3)P} with seq=2. The I bit will still not be set. When the upstream router gets this, it will have the most upto date state even if it acked seq=1. The ACK for seq=1 will be ignored by the downstream router, since it is now expecting ack for seq=2. 2) M1 is an incremental update (I bit is set). If we sent the incremental JP message containing {(Sp,Gp)J, (Sq,Gq)P} with seq=X and now we have to prune (Sp,Gp), we would simply send the Join {(Sp,Gp)P, (Sq, Gq)P} with seq=X+1. We will still have the correct state. So if a state changes in the database, it is not that we would have outdated messages on the rtx queue waiting to be acked. The messages on the rtx queue will also be updated when the state changes in the database. Of course, an implementation may choose not to do it that way; it can even queue up multiple messages and want each of them to be acked, but that would be the implementation's issue, not the protocol's. Does this make sense? > > In this problem space, you don't need to track every transition, but > only > the latest transition. Agreed. That's what I am saying too. > > BTW, in your example U1 sending to D1 and U2 sending to D2 is not a > normal situation and is usually a case of broken unicast routing > configuration (which Assert processing tries to fix, but people don't > like > using Assert processing). Not necessarily. You could have (S,G) traffic and (*,G) traffic being received on a LAN for the same (S,G) because some downstream (*,G) router decided not to switch to (S,G) because of threshold limits. I don't like Assert processing myself, but since the spec has it, our scheme has to accommodate it anyway. > > By the way JP-Acks are useful to third-party upstream and downstream > routers. In fact, I was planning on using it as a way to suppress > Asserting. So the assert single forwarderdecision could be done when > an upstream router sees a join on an oif to another upstream router. > 1) The > Assert *could* be triggered at that time rather than at data > forwarding > time or 2) the upstream router could choose not to populate it's oif- > list > (to force a single direction for unicast routing). > The Assert optimization seems outside the scope of refresh reduction, and goes against the "let's not change too much" motto, although it is still possible to achieve it without the ACKS being multicast. It is the Joins that would trigger the assert if you want it that way (as you state yourself), not the ACKS. So it would be the "See Join" event, not the "See Join Ack" event that would take care of it. I am trying to avoid the "See Join Ack" event. Suresh From dino@cisco.com Mon Jan 3 19:27:30 2005 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j040RUKn098866 for ; Mon, 3 Jan 2005 19:27:30 -0500 (EST) (envelope-from dino@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 03 Jan 2005 17:37:57 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from dino-lnx.cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j040RHl2022368; Mon, 3 Jan 2005 16:27:17 -0800 (PST) Received: (from dino@localhost) by dino-lnx.cisco.com (8.11.6/8.11.6) id j040RMo12961; Mon, 3 Jan 2005 16:27:22 -0800 Date: Mon, 3 Jan 2005 16:27:22 -0800 Message-Id: <200501040027.j040RMo12961@dino-lnx.cisco.com> From: Dino Farinacci To: suresh.boddapati@alcatel.com In-reply-to: <030201c4f1d0$0252f820$4abb16ac@alcatelxp> (suresh.boddapati@alcatel.com) Subject: Re: [Pim-state] Proposal References: <030201c4f1d0$0252f820$4abb16ac@alcatelxp> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 04 Jan 2005 00:27:30 -0000 [Responding to both of your emails here]. >> How does my proposal change the semantics of other downstream routers >> creating state? All I am saying is that ACKs should be unicast, not the I didn't say it did. I was responding to why you want to keep JP messages as multicast on the LAN. And by transmitting the JP-Acks as multicast gives another chance for other routers to see the join/prune state if they didn't see the JP message. >> Why do we need to have different backoffs per entry? I am not requiring You may have them because the upstream routers may be different and hence might have different loss and delay characteristics. What you descirbe is to a single upstream neigthbor, and yes, in this case you can group the backoff timer for all entries sent to the single upstream router. >> Hmm. I am not sure if you are agreeing with me or disagreeing with me I wasn't doing either. I was showing the pros and cons of each. >> So for example, if M1 represents {(S1,G1), (S2, G2),... (Sn, Gn)} and >> the sequence number is 1, if (S1,G1) decides to prune, we just send the >> regular Join as today with (S1,G1) Prune encoded. The Message ID TLV >> will also be included, but now it will have sequence number 2 and the I >> bit set which means that it is an incremental update to M1. The upstream >> router will ack back M1,seq.=2. Now if (S2,G2) and (S3,G3) get pruned >> and (Sp, Gp) is joined, it will be another JP message with these three >> entries, seq.=3, and I bit set, and so on... Everytime the upstream >> router gets the incremental update, it restarts the timer for the entire >> message, so we don't have to refresh all the remaining states. I'm saying the grouping requires more logic to the JP code. Today, you don't care what message a specific (S,G) goes in. Now, you might because it's reliability may depend on the message. If you used TCP, you wouldn't have to worry about this. In your proposal you do. >> Refresh elimination is not a good thing if you do not have hard state >> (like TCP). If you add reliability, you can always set the hold time to >> infinity and get rid of refreshes. We don't need a new scheme IMO. This doesn't make sense and has never to me in 20 years. As long as you malloc() in your code, one maintains state. I don't know what's the difference between hard and soft state!!! Some people in the distant past called "soft state protocols" ones that retransmitted via refresh messages, and "hard state protocols" did not. BTW, there are many different forms of reliability with different levels of persistence. >> I am not requiring explicit tracking (tracking as mentioned in the base >> spec). I am saying you will get it automatically if you go with my You are explicitly tracking ack'ers per message. >> The messages would still be small. The refresh message would carry >> Message IDs so the number of messages and acks would be more than an >> order smaller. Making it CSNP like increases the processing on all the >> downstream routers because now each downstream router would have to look >> at all states that others have as well. Isn't less messages better? >> Over optimization? What about L2 VPLS? All L2 VPNs would have to do >> snooping of some sort in order to reduce multicast traffic to the >> minimum required. There are already drafts floating around that try to >> address snooping issues in L2 VPLS. I don't think we can ignore snooping >> "systems" (not necessarily couple of switches on a switched network). If L2 VPLS doesn't scale by itself, why should PIM solve it's problem. Yes, to a certain extent, within the scope of this problem, I want to ignore VPLS. >> Are we talking implementation details here? Look at it this way. If a Since we are modifying an existing protocol which has widespread deployment, from multiple vendors, we cannot ignore implementations. Or else we are building an entirely different new protocol. >> Message has not been acked and there is a change to some entry in the >> message, all I am saying is that we bump up the sequence number and do a >> union of the current message state and the new state. It is this message >> with the higher sequence number that we want acked. So we always have to >> keep only one outstanding version of message, the latest one that has >> not yet been acked. A couple of examples for this (I am assuming you >> have gone through my draft): That is what I was saying about extra queuing. >> 1) M1 is a complete message (not an incremental one, I bit is not set). >> If we sent Joins for {(S1,G1), (S2, G2), (S3, G3)} with seq=1 and we >> have not received an ACK for M1, and now (S3, G3) is pruned and (S4, G4) >> is joined, then M1 will now be {(S1,G1)J, (S2, G2)J, (S4,G4)J, (S3, So when you receive an Ack, how do you know which entries have been acknowledged? Is it really an Ack for M1 or does M1 have the contacts of the original JP message so you know which entries have been acked? Because you may have multiple M1s sent, not just two messages. I think if you are going to have sequence numbers, it's not good form to change the contents for what the sequence number will cover. What are you saving by doing this? Why not just send the new info with a M2 sequence number? >> 2) M1 is an incremental update (I bit is set). If we sent the >> incremental JP message containing {(Sp,Gp)J, (Sq,Gq)P} with seq=X and >> now we have to prune (Sp,Gp), we would simply send the Join {(Sp,Gp)P, >> (Sq, Gq)P} with seq=X+1. We will still have the correct state. Right, why not always do this? >> Agreed. That's what I am saying too. You can per entry beacuse there are only 2 states, but you can't do this with a sequence numbered message since it has multiple entries per message and you want to know what has got to the receiver. >> Not necessarily. You could have (S,G) traffic and (*,G) traffic being >> received on a LAN for the same (S,G) because some downstream (*,G) >> router decided not to switch to (S,G) because of threshold limits. I >> don't like Assert processing myself, but since the spec has it, our >> scheme has to accommodate it anyway. Yes, but these are two different routes! >> > >> > By the way JP-Acks are useful to third-party upstream and >> downstream >> > routers. In fact, I was planning on using it as a way to suppress >> > Asserting. So the assert single forwarderdecision could be done >> when >> > an upstream router sees a join on an oif to another upstream >> router. >> > 1) The >> > Assert *could* be triggered at that time rather than at data >> > forwarding >> > time or 2) the upstream router could choose not to populate it's >> oif- >> > list >> > (to force a single direction for unicast routing). >> > >> The Assert optimization seems outside the scope of refresh reduction, >> and goes against the "let's not change too much" motto, although it is >> still possible to achieve it without the ACKS being multicast. It is the >> Joins that would trigger the assert if you want it that way (as you >> state yourself), not the ACKS. So it would be the "See Join" event, not >> the "See Join Ack" event that would take care of it. I am trying to >> avoid the "See Join Ack" event. That is why I said you *could*. If you have a design that works and other things benefit, this is a win. We are not changing the design to make Asserts work, it is fallout. Dino From suresh.boddapati@alcatel.com Mon Jan 3 20:35:30 2005 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j041ZT2g098992 for ; Mon, 3 Jan 2005 20:35:30 -0500 (EST) (envelope-from suresh.boddapati@alcatel.com) Received: from alcatelxp ([172.22.187.74] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 3 Jan 2005 17:35:13 -0800 From: "Suresh Boddapati" To: "'Dino Farinacci'" Subject: RE: [Pim-state] Proposal Date: Mon, 3 Jan 2005 17:33:24 -0800 Organization: Alcatel USA Message-ID: <032701c4f1fd$639f9840$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200501040027.j040RMo12961@dino-lnx.cisco.com> Importance: Normal X-OriginalArrivalTime: 04 Jan 2005 01:35:13.0981 (UTC) FILETIME=[A32C0ED0:01C4F1FD] Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: suresh.boddapati@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 04 Jan 2005 01:35:31 -0000 > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Monday, January 03, 2005 4:27 PM > To: suresh.boddapati@alcatel.com > Cc: rkebler@avici.com; pim-state@mountain2sea.com > Subject: Re: [Pim-state] Proposal > > [Responding to both of your emails here]. > > >> How does my proposal change the semantics of other downstream routers > >> creating state? All I am saying is that ACKs should be unicast, not the > > I didn't say it did. I was responding to why you want to keep JP > messages > as multicast on the LAN. And by transmitting the JP-Acks as multicast > gives another chance for other routers to see the join/prune state if > they didn't see the JP message. > The JP Acks are only for Messages in my scheme. So they only have the Message ID TLV in it. If D1 sent M1 and D2 sent M1, then U1 keeps track of M1D1 and M1D2 and acks each. But D1 does not have to keep track of M1D2, nor does D2 have to keep track of M1D1. So my point was D1 has no use for the ack pertaining to M1D2, unless it kept track of M1D2 which I didn't want to do. > >> Why do we need to have different backoffs per entry? I am not requiring > > You may have them because the upstream routers may be different and > hence > might have different loss and delay characteristics. > > What you descirbe is to a single upstream neigthbor, and yes, in this > case you can group the backoff timer for all entries sent to the > single > upstream router. My scheme is messaging PER upstream nbr, not messaging per LAN. > > I'm saying the grouping requires more logic to the JP code. Today, you > don't care what message a specific (S,G) goes in. Now, you might > because > it's reliability may depend on the message. Of course. No matter what scheme we use, we will have to add extra code. Grouping JP states does create an association with a Message ID. But the benefits are that you will have less processing to do in terms of timers, plus it reduces the number of refreshes and their associated processing. > > >> Refresh elimination is not a good thing if you do not have hard state > >> (like TCP). If you add reliability, you can always set the hold time to > >> infinity and get rid of refreshes. We don't need a new scheme IMO. > > This doesn't make sense and has never to me in 20 years. As long as > you > malloc() in your code, one maintains state. I don't know what's the > difference between hard and soft state!!! > > Some people in the distant past called "soft state protocols" ones > that > retransmitted via refresh messages, and "hard state protocols" did > not. > > BTW, there are many different forms of reliability with different > levels > of persistence. > I see what you are saying. But the fact remains that if you just wanted to eliminate refreshes, you can do that today by setting the holdtime to 0xffff. If you add the reliability scheme, you can set the holdtime to infinity and not refresh at all. I was just saying that we do not need a new scheme to eliminate refreshes. > >> I am not requiring explicit tracking (tracking as mentioned in the base > >> spec). I am saying you will get it automatically if you go with my > > You are explicitly tracking ack'ers per message. > Yes I am. I thought you were saying there was an issue if somebody did not support explicit tracking and I assumed you meant the tracking support as specified in the base spec. Since the upstream router will keep track of Message ID associations per downstream nbr, tracking will happen automatically. > >> The messages would still be small. The refresh message would carry > >> Message IDs so the number of messages and acks would be more than an > >> order smaller. Making it CSNP like increases the processing on all the > >> downstream routers because now each downstream router would have to > look > >> at all states that others have as well. > > Isn't less messages better? So is less processing. If D1 has only 1 state and D2 a million, I don't see the point in D1 seeing a CSNP like thing with a million states in it which has no relevance to it. > > >> Over optimization? What about L2 VPLS? All L2 VPNs would have to do > >> snooping of some sort in order to reduce multicast traffic to the > >> minimum required. There are already drafts floating around that try to > >> address snooping issues in L2 VPLS. I don't think we can ignore > snooping > >> "systems" (not necessarily couple of switches on a switched network). > > If L2 VPLS doesn't scale by itself, why should PIM solve it's problem. > Yes, to a certain extent, within the scope of this problem, I want to > ignore VPLS. > The problem is not necessarily about VPLS scaling. The problem is VPLS using PIM snooping just like a layer 2 switch does. Today there are L2 switches supporting PIM snooping. You said we do not need to worry about couple of them on a switched network. I am saying with VPLS, you can have a huge switched network and PIM snooping being done by a lot of PEs. We cannot just ignore them saying what works today will no longer work because we decided so. I would be curious to hear what providers would have to say if we proposed something like that. It's not that difficult to accommodate it I feel. > > >> 1) M1 is a complete message (not an incremental one, I bit is not set). > >> If we sent Joins for {(S1,G1), (S2, G2), (S3, G3)} with seq=1 and we > >> have not received an ACK for M1, and now (S3, G3) is pruned and (S4, > G4) > >> is joined, then M1 will now be {(S1,G1)J, (S2, G2)J, (S4,G4)J, (S3, > > So when you receive an Ack, how do you know which entries have been > acknowledged? Is it really an Ack for M1 or does M1 have the contacts > of > the original JP message so you know which entries have been acked? It's an ack for M1 which has the sequence number. So if I got an ACK for M1 seq=1, then I ignore it because I am expecting an ACK for M1 seq=2, so I would continue to retransmit until I get an ACK for M1 seq=2. > > Because you may have multiple M1s sent, not just two messages. > > I think if you are going to have sequence numbers, it's not good form > to change the contents for what the sequence number will cover. What > are you saving by doing this? Why not just send the new info with a M2 > sequence number? I think you are getting confused with M1 being the sequence number. A message has two things, a Message ID which is M1 and a sequence number X. I am saying when M1's contents change, M1's sequence number will change to X+1. > > >> 2) M1 is an incremental update (I bit is set). If we sent the > >> incremental JP message containing {(Sp,Gp)J, (Sq,Gq)P} with seq=X and > >> now we have to prune (Sp,Gp), we would simply send the Join {(Sp,Gp)P, > >> (Sq, Gq)P} with seq=X+1. We will still have the correct state. > > Right, why not always do this? > I am trying to differentiate between a complete update and an incremental update for the sake of those poor snooping switches where I would send a complete update periodically. Somehow, you don't seem to like snooping, I take it :-) > >> Agreed. That's what I am saying too. > > You can per entry beacuse there are only 2 states, but you can't do > this > with a sequence numbered message since it has multiple entries per > message > and you want to know what has got to the receiver. > > >> Not necessarily. You could have (S,G) traffic and (*,G) traffic being > >> received on a LAN for the same (S,G) because some downstream (*,G) > >> router decided not to switch to (S,G) because of threshold limits. I > >> don't like Assert processing myself, but since the spec has it, our > >> scheme has to accommodate it anyway. > > Yes, but these are two different routes! > True, but the traffic is still duplicate. So there would be an Assert election to ensure that only one guy sends the traffic for that (S,G). I am talking about the case when one has (S,G) forwarding state and it receives an Assert with rpt bit set. From Yetik_Serbest@labs.sbc.com Tue Jan 4 17:33:11 2005 Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j04MXB1T002080 for ; Tue, 4 Jan 2005 17:33:11 -0500 (EST) (envelope-from Yetik_Serbest@labs.sbc.com) Received: from sbctri.tri.sbc.com (mayhem-webdmz.tri.sbc.com [144.60.9.139]) by howler.tri.sbc.com (8.12.10/8.12.10) with ESMTP id j04MX8Rt017770; Tue, 4 Jan 2005 16:33:09 -0600 (CST) Received: from TSMAIL2.ad.tri.sbc.com (tsmail2.ad.tri.sbc.com [144.60.55.226]) by sbctri.tri.sbc.com (8.12.10/8.12.10) with ESMTP id j04MX80u004296; Tue, 4 Jan 2005 16:33:08 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Pim-state] Proposal Date: Tue, 4 Jan 2005 16:33:08 -0600 Message-ID: <0CED449E95A92A42991EB71B778C17BF18BE4A@TSMAIL2.ad.tri.sbc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pim-state] Proposal Thread-Index: AcTx9EBYOBkWeZ/xQuagvXLLhHVTHQAuL+yw From: "Serbest, Yetik" To: "Dino Farinacci" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by rock.mountain2sea.com id j04MXB1T002080 Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 04 Jan 2005 22:33:12 -0000 Dino, I think you can ignore VPLS, but you should not ignore PIM snooping. In VPLS-mcast proposals, we utilize PIM-snooping but we have added nothing to PIM-snooping. Thanks, yetik -----Original Message----- From: pim-state-bounces@mountain2sea.com [mailto:pim-state-bounces@mountain2sea.com] On Behalf Of Dino Farinacci Sent: Monday, January 03, 2005 6:27 PM To: suresh.boddapati@alcatel.com Cc: pim-state@mountain2sea.com Subject: Re: [Pim-state] Proposal [Responding to both of your emails here]. >> How does my proposal change the semantics of other downstream routers >> creating state? All I am saying is that ACKs should be unicast, not the I didn't say it did. I was responding to why you want to keep JP messages as multicast on the LAN. And by transmitting the JP-Acks as multicast gives another chance for other routers to see the join/prune state if they didn't see the JP message. >> Why do we need to have different backoffs per entry? I am not requiring You may have them because the upstream routers may be different and hence might have different loss and delay characteristics. What you descirbe is to a single upstream neigthbor, and yes, in this case you can group the backoff timer for all entries sent to the single upstream router. >> Hmm. I am not sure if you are agreeing with me or disagreeing with me I wasn't doing either. I was showing the pros and cons of each. >> So for example, if M1 represents {(S1,G1), (S2, G2),... (Sn, Gn)} and >> the sequence number is 1, if (S1,G1) decides to prune, we just send the >> regular Join as today with (S1,G1) Prune encoded. The Message ID TLV >> will also be included, but now it will have sequence number 2 and the I >> bit set which means that it is an incremental update to M1. The upstream >> router will ack back M1,seq.=2. Now if (S2,G2) and (S3,G3) get pruned >> and (Sp, Gp) is joined, it will be another JP message with these three >> entries, seq.=3, and I bit set, and so on... Everytime the upstream >> router gets the incremental update, it restarts the timer for the entire >> message, so we don't have to refresh all the remaining states. I'm saying the grouping requires more logic to the JP code. Today, you don't care what message a specific (S,G) goes in. Now, you might because it's reliability may depend on the message. If you used TCP, you wouldn't have to worry about this. In your proposal you do. >> Refresh elimination is not a good thing if you do not have hard state >> (like TCP). If you add reliability, you can always set the hold time to >> infinity and get rid of refreshes. We don't need a new scheme IMO. This doesn't make sense and has never to me in 20 years. As long as you malloc() in your code, one maintains state. I don't know what's the difference between hard and soft state!!! Some people in the distant past called "soft state protocols" ones that retransmitted via refresh messages, and "hard state protocols" did not. BTW, there are many different forms of reliability with different levels of persistence. >> I am not requiring explicit tracking (tracking as mentioned in the base >> spec). I am saying you will get it automatically if you go with my You are explicitly tracking ack'ers per message. >> The messages would still be small. The refresh message would carry >> Message IDs so the number of messages and acks would be more than an >> order smaller. Making it CSNP like increases the processing on all the >> downstream routers because now each downstream router would have to look >> at all states that others have as well. Isn't less messages better? >> Over optimization? What about L2 VPLS? All L2 VPNs would have to do >> snooping of some sort in order to reduce multicast traffic to the >> minimum required. There are already drafts floating around that try to >> address snooping issues in L2 VPLS. I don't think we can ignore snooping >> "systems" (not necessarily couple of switches on a switched network). If L2 VPLS doesn't scale by itself, why should PIM solve it's problem. Yes, to a certain extent, within the scope of this problem, I want to ignore VPLS. >> Are we talking implementation details here? Look at it this way. If a Since we are modifying an existing protocol which has widespread deployment, from multiple vendors, we cannot ignore implementations. Or else we are building an entirely different new protocol. >> Message has not been acked and there is a change to some entry in the >> message, all I am saying is that we bump up the sequence number and do a >> union of the current message state and the new state. It is this message >> with the higher sequence number that we want acked. So we always have to >> keep only one outstanding version of message, the latest one that has >> not yet been acked. A couple of examples for this (I am assuming you >> have gone through my draft): That is what I was saying about extra queuing. >> 1) M1 is a complete message (not an incremental one, I bit is not set). >> If we sent Joins for {(S1,G1), (S2, G2), (S3, G3)} with seq=1 and we >> have not received an ACK for M1, and now (S3, G3) is pruned and (S4, G4) >> is joined, then M1 will now be {(S1,G1)J, (S2, G2)J, (S4,G4)J, (S3, So when you receive an Ack, how do you know which entries have been acknowledged? Is it really an Ack for M1 or does M1 have the contacts of the original JP message so you know which entries have been acked? Because you may have multiple M1s sent, not just two messages. I think if you are going to have sequence numbers, it's not good form to change the contents for what the sequence number will cover. What are you saving by doing this? Why not just send the new info with a M2 sequence number? >> 2) M1 is an incremental update (I bit is set). If we sent the >> incremental JP message containing {(Sp,Gp)J, (Sq,Gq)P} with seq=X and >> now we have to prune (Sp,Gp), we would simply send the Join {(Sp,Gp)P, >> (Sq, Gq)P} with seq=X+1. We will still have the correct state. Right, why not always do this? >> Agreed. That's what I am saying too. You can per entry beacuse there are only 2 states, but you can't do this with a sequence numbered message since it has multiple entries per message and you want to know what has got to the receiver. >> Not necessarily. You could have (S,G) traffic and (*,G) traffic being >> received on a LAN for the same (S,G) because some downstream (*,G) >> router decided not to switch to (S,G) because of threshold limits. I >> don't like Assert processing myself, but since the spec has it, our >> scheme has to accommodate it anyway. Yes, but these are two different routes! >> > >> > By the way JP-Acks are useful to third-party upstream and >> downstream >> > routers. In fact, I was planning on using it as a way to suppress >> > Asserting. So the assert single forwarderdecision could be done >> when >> > an upstream router sees a join on an oif to another upstream >> router. >> > 1) The >> > Assert *could* be triggered at that time rather than at data >> > forwarding >> > time or 2) the upstream router could choose not to populate it's >> oif- >> > list >> > (to force a single direction for unicast routing). >> > >> The Assert optimization seems outside the scope of refresh reduction, >> and goes against the "let's not change too much" motto, although it is >> still possible to achieve it without the ACKS being multicast. It is the >> Joins that would trigger the assert if you want it that way (as you >> state yourself), not the ACKS. So it would be the "See Join" event, not >> the "See Join Ack" event that would take care of it. I am trying to >> avoid the "See Join Ack" event. That is why I said you *could*. If you have a design that works and other things benefit, this is a win. We are not changing the design to make Asserts work, it is fallout. Dino _______________________________________________ Pim-state mailing list Pim-state@mountain2sea.com http://www.mountain2sea.com/mailman/listinfo/pim-state From dino@cisco.com Tue Jan 4 21:06:27 2005 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0526RC2002401 for ; Tue, 4 Jan 2005 21:06:27 -0500 (EST) (envelope-from dino@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 04 Jan 2005 18:14:24 -0800 Received: from dino-lnx.cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0526Hvl029641; Tue, 4 Jan 2005 18:06:17 -0800 (PST) Received: (from dino@localhost) by dino-lnx.cisco.com (8.11.6/8.11.6) id j0526Jq09050; Tue, 4 Jan 2005 18:06:19 -0800 Date: Tue, 4 Jan 2005 18:06:19 -0800 Message-Id: <200501050206.j0526Jq09050@dino-lnx.cisco.com> From: Dino Farinacci To: Yetik_Serbest@labs.sbc.com In-reply-to: <0CED449E95A92A42991EB71B778C17BF18BE4A@TSMAIL2.ad.tri.sbc.com> (Yetik_Serbest@labs.sbc.com) Subject: Re: [Pim-state] Proposal References: <0CED449E95A92A42991EB71B778C17BF18BE4A@TSMAIL2.ad.tri.sbc.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 05 Jan 2005 02:06:28 -0000 >> I think you can ignore VPLS, but you should not ignore PIM snooping. >> In VPLS-mcast proposals, we utilize PIM-snooping but we have added >> nothing to PIM-snooping. If we are changing the protocol, PIM snooping switches have to change too. We have to eliminate periodic messages in this rev or else we'll hit the next scaling problem before this solution ever gets deployed. Dino From suresh.boddapati@alcatel.com Wed Jan 5 00:12:18 2005 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j055CHsr002693 for ; Wed, 5 Jan 2005 00:12:18 -0500 (EST) (envelope-from suresh.boddapati@alcatel.com) Received: from alcatelxp ([172.22.187.74] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 4 Jan 2005 21:12:11 -0800 From: "Suresh Boddapati" To: "'Dino Farinacci'" , Subject: RE: [Pim-state] Proposal Date: Tue, 4 Jan 2005 21:13:54 -0800 Organization: Alcatel USA Message-ID: <036d01c4f2e5$5b69f600$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200501050206.j0526Jq09050@dino-lnx.cisco.com> Importance: Normal X-OriginalArrivalTime: 05 Jan 2005 05:12:11.0497 (UTC) FILETIME=[1CA11D90:01C4F2E5] Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: suresh.boddapati@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 05 Jan 2005 05:12:18 -0000 Ok. Let's assume that PIM snooping switches are willing to change. What should they do? Let's say snooping is turned on on a switch after all the PIM JP exchanges have happened. How does the snooping switch acquire the PIM JP state on the LAN? There are no periodic messages anymore, nothing to snoop on. That's the reason why I was proposing that we periodically (something like every 20-30 minutes) send complete JP messages (complete as opposed to incremental ones) so that snooping switches can learn the state. Another way of achieving this (if you do not like the periodic messages) is to create a new message type, call it "PIM Refresh All JP states" message, which a snooping switch will multicast on the LAN upon enabling snooping. Whenever a downstream router sees this message, it will send out complete JP messages on the LAN at an extremely low, possibly configurable rate (something like a message every 10 seconds say) until it is done with all the JP states for that LAN. Then it will shut up and continue to send incremental updates whenever state changes happen. Does this seem acceptable? Suresh > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Tuesday, January 04, 2005 6:06 PM > To: Yetik_Serbest@labs.sbc.com > Cc: suresh.boddapati@alcatel.com; pim-state@mountain2sea.com > Subject: Re: [Pim-state] Proposal > > >> I think you can ignore VPLS, but you should not ignore PIM snooping. > >> In VPLS-mcast proposals, we utilize PIM-snooping but we have added > >> nothing to PIM-snooping. > > If we are changing the protocol, PIM snooping switches have to change > too. > We have to eliminate periodic messages in this rev or else we'll hit > the > next scaling problem before this solution ever gets deployed. > > Dino From dino@cisco.com Wed Jan 5 01:59:19 2005 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j056xIfb002856 for ; Wed, 5 Jan 2005 01:59:19 -0500 (EST) (envelope-from dino@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 Jan 2005 23:07:18 -0800 Received: from dino-lnx.cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j056xBjw003361; Tue, 4 Jan 2005 22:59:11 -0800 (PST) Received: (from dino@localhost) by dino-lnx.cisco.com (8.11.6/8.11.6) id j056xBJ10076; Tue, 4 Jan 2005 22:59:11 -0800 Date: Tue, 4 Jan 2005 22:59:11 -0800 Message-Id: <200501050659.j056xBJ10076@dino-lnx.cisco.com> From: Dino Farinacci To: suresh.boddapati@alcatel.com In-reply-to: <036d01c4f2e5$5b69f600$4abb16ac@alcatelxp> (suresh.boddapati@alcatel.com) Subject: Re: [Pim-state] Proposal References: <036d01c4f2e5$5b69f600$4abb16ac@alcatelxp> Cc: pim-state@mountain2sea.com, Yetik_Serbest@labs.sbc.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 05 Jan 2005 06:59:19 -0000 >> Ok. Let's assume that PIM snooping switches are willing to change. What >> should they do? Let's say snooping is turned on on a switch after all >> the PIM JP exchanges have happened. How does the snooping switch acquire >> the PIM JP state on the LAN? There are no periodic messages anymore, >> nothing to snoop on. That's the reason why I was proposing that we >> periodically (something like every 20-30 minutes) send complete JP >> messages (complete as opposed to incremental ones) so that snooping >> switches can learn the state. The switch needs to see the JP messages and cache them. Regardless if they are sent triggered or periodically. Snooping does not assume periodic transmission. Snooping is simply eavesdropping, parsing messages, and caching the state. The good news is, if the triggered JP is lost, it can be retransmitted. And in the proposal I forwarded to this list, an JP-Ack gives the switch another opportunity to see the JP message (since the contents of a JP and JP-Ack message are identical). >> Another way of achieving this (if you do not like the periodic messages) >> is to create a new message type, call it "PIM Refresh All JP states" >> message, which a snooping switch will multicast on the LAN upon enabling >> snooping. Whenever a downstream router sees this message, it will send Yes, but not necessary. Dino From suresh.boddapati@alcatel.com Wed Jan 5 10:23:24 2005 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j05FNNYa006767 for ; Wed, 5 Jan 2005 10:23:24 -0500 (EST) (envelope-from suresh.boddapati@alcatel.com) Received: from alcatelxp ([172.22.187.74] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 5 Jan 2005 07:23:14 -0800 From: "Suresh Boddapati" To: "'Dino Farinacci'" Subject: RE: [Pim-state] Proposal Date: Wed, 5 Jan 2005 07:25:19 -0800 Organization: Alcatel USA Message-ID: <037601c4f33a$c5519f50$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200501050659.j056xBJ10076@dino-lnx.cisco.com> Importance: Normal X-OriginalArrivalTime: 05 Jan 2005 15:23:14.0792 (UTC) FILETIME=[79A7F680:01C4F33A] Cc: pim-state@mountain2sea.com, Yetik_Serbest@labs.sbc.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: suresh.boddapati@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 05 Jan 2005 15:23:24 -0000 > >> Ok. Let's assume that PIM snooping switches are willing to change. What > >> should they do? Let's say snooping is turned on on a switch after all > >> the PIM JP exchanges have happened. How does the snooping switch > acquire > >> the PIM JP state on the LAN? There are no periodic messages anymore, > >> nothing to snoop on. That's the reason why I was proposing that we > >> periodically (something like every 20-30 minutes) send complete JP > >> messages (complete as opposed to incremental ones) so that snooping > >> switches can learn the state. > > The switch needs to see the JP messages and cache them. Regardless if > they > are sent triggered or periodically. Snooping does not assume periodic > transmission. Snooping is simply eavesdropping, parsing messages, and > caching the state. > You are assuming that the eavesdropping will always begin before any PIM JP packets have been exchanged. Today, that's not the case. The eavesdropping can occur any time and the state can be built. To require the eavesdropping to begin before any JP messages are sent is a big restriction, isn't it? If the network is stable after the initial JP exchange (i.e. there are no triggered changes) and then the eavesdropping begins, how does the switch acquire the state? > The good news is, if the triggered JP is lost, it can be > retransmitted. Lost from whose point of view? A switch may not see it, but the upstream router (which may be on the same physical LAN as the downstream router, not going through that switch) may see it and may ack it. Same thing goes for ACK. Not every downstream router and switch may see the ACK. How does the switch acquire the state then if it does not see the JP or JP ACK? If there is such a failure scenario and there are periodic messages, the switch will eventually build its state. My point is, some applications/deployments may want periodic messages, some may not. The protocol provides for both today with the holdtime parameter in the JP PDU. If one is sure that there need not be any retransmissions, one can simply set it to 0xffff. Otherwise, it will just refresh periodically. The protocol should not mandate that there be no refreshes. But if there are refreshes, the protocol can ensure that the refreshes happen efficiently with less number of PDUs and less amount of processing. That should be the goal of refresh reduction IMO and that provides maximum flexibility. Suresh From dino@cisco.com Wed Jan 5 12:50:19 2005 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j05HoIJ4007767 for ; Wed, 5 Jan 2005 12:50:18 -0500 (EST) (envelope-from dino@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 05 Jan 2005 11:01:05 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from dino-lnx.cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j05HoAvl016665; Wed, 5 Jan 2005 09:50:11 -0800 (PST) Received: (from dino@localhost) by dino-lnx.cisco.com (8.11.6/8.11.6) id j05HoAQ12142; Wed, 5 Jan 2005 09:50:10 -0800 Date: Wed, 5 Jan 2005 09:50:10 -0800 Message-Id: <200501051750.j05HoAQ12142@dino-lnx.cisco.com> From: Dino Farinacci To: suresh.boddapati@alcatel.com In-reply-to: <037601c4f33a$c5519f50$4abb16ac@alcatelxp> (suresh.boddapati@alcatel.com) Subject: Re: [Pim-state] Proposal References: <037601c4f33a$c5519f50$4abb16ac@alcatelxp> Cc: pim-state@mountain2sea.com, Yetik_Serbest@labs.sbc.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 05 Jan 2005 17:50:19 -0000 >> You are assuming that the eavesdropping will always begin before any PIM >> JP packets have been exchanged. Today, that's not the case. The >> eavesdropping can occur any time and the state can be built. To require >> the eavesdropping to begin before any JP messages are sent is a big >> restriction, isn't it? If the network is stable after the initial JP >> exchange (i.e. there are no triggered changes) and then the >> eavesdropping begins, how does the switch acquire the state? The proposal I forwarded has a GENID-of-0 Hello that can be used to probe for state. Just like you said. >> Lost from whose point of view? A switch may not see it, but the upstream >> router (which may be on the same physical LAN as the downstream router, >> not going through that switch) may see it and may ack it. Same thing But the JPs are multicasted. And since these are link-local multicasts, all switches must see them. >> goes for ACK. Not every downstream router and switch may see the ACK. >> How does the switch acquire the state then if it does not see the JP or >> JP ACK? If there is such a failure scenario and there are periodic >> messages, the switch will eventually build its state. JP-Acks are link-local multicasted as well. >> My point is, some applications/deployments may want periodic messages, >> some may not. The protocol provides for both today with the holdtime >> parameter in the JP PDU. If one is sure that there need not be any >> retransmissions, one can simply set it to 0xffff. Otherwise, it will Large holdtimes don't work good in practice beacuse you can't anticipate JP lossage so you always have to assume you need retransmission. >> no refreshes. But if there are refreshes, the protocol can ensure that >> the refreshes happen efficiently with less number of PDUs and less >> amount of processing. That should be the goal of refresh reduction IMO >> and that provides maximum flexibility. If you want refreshes, we are better off not changing anything. We should get some other opinions from this group regarding this. There is no proposal that won't require any changes to switches. Unless, we just keep things the way they are. Another question to ask, on Gigabtis ethernet, how much of the problem did we solve if we used 9K MTU-sized JP messages and keep the periodic transmission? There is some benefit to this but is it enough? Dino From suresh.boddapati@alcatel.com Wed Jan 5 17:01:05 2005 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j05M13Hr008385 for ; Wed, 5 Jan 2005 17:01:04 -0500 (EST) (envelope-from suresh.boddapati@alcatel.com) Received: from alcatelxp ([172.22.187.74] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 5 Jan 2005 14:00:50 -0800 From: "Suresh Boddapati" To: "'Dino Farinacci'" Subject: RE: [Pim-state] Proposal Date: Wed, 5 Jan 2005 14:02:55 -0800 Organization: Alcatel USA Message-ID: <038a01c4f372$50e43190$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200501051750.j05HoAQ12142@dino-lnx.cisco.com> Importance: Normal X-OriginalArrivalTime: 05 Jan 2005 22:00:50.0412 (UTC) FILETIME=[04B6B2C0:01C4F372] Cc: pim-state@mountain2sea.com, Yetik_Serbest@labs.sbc.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: suresh.boddapati@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 05 Jan 2005 22:01:05 -0000 > >> You are assuming that the eavesdropping will always begin before any > PIM > >> JP packets have been exchanged. Today, that's not the case. The > >> eavesdropping can occur any time and the state can be built. To require > >> the eavesdropping to begin before any JP messages are sent is a big > >> restriction, isn't it? If the network is stable after the initial JP > >> exchange (i.e. there are no triggered changes) and then the > >> eavesdropping begins, how does the switch acquire the state? > > The proposal I forwarded has a GENID-of-0 Hello that can be used to > probe for state. Just like you said. > Your GENID-of-0 Hello proposal is for a router, not for a switch (in your proposal this hello is unicast to a downstream router). Why would the switch send out a Hello, to whom? > >> Lost from whose point of view? A switch may not see it, but the > upstream > >> router (which may be on the same physical LAN as the downstream router, > >> not going through that switch) may see it and may ack it. Same thing > > But the JPs are multicasted. And since these are link-local > multicasts, > all switches must see them. Of course they are multicast. But you can drop a packet for many reasons (not having rx buffers etc). Just because the pkt is on the wire does not mean the packet will definitely be consumed and processed. If the switch is busy and has to drop a few control frames, it may not see the JP exchange. > > >> goes for ACK. Not every downstream router and switch may see the ACK. > >> How does the switch acquire the state then if it does not see the JP or > >> JP ACK? If there is such a failure scenario and there are periodic > >> messages, the switch will eventually build its state. > > JP-Acks are link-local multicasted as well. > Same as above. > > We should get some other opinions from this group regarding this. I agree. > > Another question to ask, on Gigabtis ethernet, how much of the problem > did > we solve if we used 9K MTU-sized JP messages and keep the periodic > transmission? There is some benefit to this but is it enough? > Hmm, I'm not sure I see the benefit. Whatever be the size of the JP message, we are still sending a large number of control octets on the wire, plus the processing on the upstream router remains the same. From rkebler@avici.com Wed Jan 5 17:50:10 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j05MoAEe008464 for ; Wed, 5 Jan 2005 17:50:10 -0500 (EST) (envelope-from rkebler@avici.com) Received: from rkebler-pc (rkebler-pc.avici.com [10.2.20.48]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id j05Mmt7l002707; Wed, 5 Jan 2005 17:48:55 -0500 Message-Id: <4.2.0.58.20050105174120.00ce3310@mailhost.avici.com> X-Sender: rkebler@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 05 Jan 2005 17:57:27 -0500 To: , pim-state@mountain2sea.com From: Robert Kebler Subject: Re: [Pim-state] Proposal In-Reply-To: <200501051750.j05HoAQ12142@dino-lnx.cisco.com> References: <037601c4f33a$c5519f50$4abb16ac@alcatelxp> <037601c4f33a$c5519f50$4abb16ac@alcatelxp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 05 Jan 2005 22:50:10 -0000 > > >> no refreshes. But if there are refreshes, the protocol can ensure that > >> the refreshes happen efficiently with less number of PDUs and less > >> amount of processing. That should be the goal of refresh reduction IMO > >> and that provides maximum flexibility. > > If you want refreshes, we are better off not changing anything. > > We should get some other opinions from this group regarding this. There > is no proposal that won't require any changes to switches. Unless, we > just > keep things the way they are. > > Another question to ask, on Gigabtis ethernet, how much of the > problem did > we solve if we used 9K MTU-sized JP messages and keep the periodic > transmission? There is some benefit to this but is it enough? > >Dino > > I believe we should have the JP messages periodically refreshed (30 minutes) even if the the JP msgs are ACKed. This proposal would be very beneficial even with refreshes. Also, having a method of asking for complete Join/Prune state is a good idea. If a snooping switch is unable to do this (if we go with the Hello Option), then a switch will have to lower the refresh interval (assuming it's configurable) or turn on PIM Refresh reduction. I don't think we need to go beyond that. I don't think the jumbo MTUs will really solve our problems. -Bob From Yetik_Serbest@labs.sbc.com Wed Jan 5 17:55:07 2005 Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j05Mt6ZX008481 for ; Wed, 5 Jan 2005 17:55:06 -0500 (EST) (envelope-from Yetik_Serbest@labs.sbc.com) Received: from sbctri.tri.sbc.com (mayhem-webdmz.tri.sbc.com [144.60.9.139]) by howler.tri.sbc.com (8.12.10/8.12.10) with ESMTP id j05Ms4Rt012669; Wed, 5 Jan 2005 16:54:04 -0600 (CST) Received: from TSMAIL2.ad.tri.sbc.com (tsmail2.ad.tri.sbc.com [144.60.55.226]) by sbctri.tri.sbc.com (8.12.10/8.12.10) with ESMTP id j05Ms40w000874; Wed, 5 Jan 2005 16:54:04 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Pim-state] Proposal Date: Wed, 5 Jan 2005 16:54:04 -0600 Message-ID: <0CED449E95A92A42991EB71B778C17BF18BE53@TSMAIL2.ad.tri.sbc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pim-state] Proposal Thread-Index: AcTzcg3fFS78eAYmTSq/lfE4O+2WDAAB0qJg From: "Serbest, Yetik" To: , "Dino Farinacci" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by rock.mountain2sea.com id j05Mt6ZX008481 Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 05 Jan 2005 22:55:07 -0000 I really think Suresh's proposal is good. Yetik -----Original Message----- From: Suresh Boddapati [mailto:suresh.boddapati@alcatel.com] Sent: Wednesday, January 05, 2005 4:03 PM To: 'Dino Farinacci' Cc: Serbest, Yetik; pim-state@mountain2sea.com Subject: RE: [Pim-state] Proposal > >> You are assuming that the eavesdropping will always begin before any > PIM > >> JP packets have been exchanged. Today, that's not the case. The > >> eavesdropping can occur any time and the state can be built. To require > >> the eavesdropping to begin before any JP messages are sent is a big > >> restriction, isn't it? If the network is stable after the initial JP > >> exchange (i.e. there are no triggered changes) and then the > >> eavesdropping begins, how does the switch acquire the state? > > The proposal I forwarded has a GENID-of-0 Hello that can be used to > probe for state. Just like you said. > Your GENID-of-0 Hello proposal is for a router, not for a switch (in your proposal this hello is unicast to a downstream router). Why would the switch send out a Hello, to whom? > >> Lost from whose point of view? A switch may not see it, but the > upstream > >> router (which may be on the same physical LAN as the downstream router, > >> not going through that switch) may see it and may ack it. Same thing > > But the JPs are multicasted. And since these are link-local > multicasts, > all switches must see them. Of course they are multicast. But you can drop a packet for many reasons (not having rx buffers etc). Just because the pkt is on the wire does not mean the packet will definitely be consumed and processed. If the switch is busy and has to drop a few control frames, it may not see the JP exchange. > > >> goes for ACK. Not every downstream router and switch may see the ACK. > >> How does the switch acquire the state then if it does not see the JP or > >> JP ACK? If there is such a failure scenario and there are periodic > >> messages, the switch will eventually build its state. > > JP-Acks are link-local multicasted as well. > Same as above. > > We should get some other opinions from this group regarding this. I agree. > > Another question to ask, on Gigabtis ethernet, how much of the problem > did > we solve if we used 9K MTU-sized JP messages and keep the periodic > transmission? There is some benefit to this but is it enough? > Hmm, I'm not sure I see the benefit. Whatever be the size of the JP message, we are still sending a large number of control octets on the wire, plus the processing on the upstream router remains the same. From rkebler@avici.com Wed Jan 5 18:16:35 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j05NGZEQ008525 for ; Wed, 5 Jan 2005 18:16:35 -0500 (EST) (envelope-from rkebler@avici.com) Received: from rkebler-pc (rkebler-pc.avici.com [10.2.20.48]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id j05NFM7l007151; Wed, 5 Jan 2005 18:15:22 -0500 Message-Id: <4.2.0.58.20050105180513.00bc3f00@mailhost.avici.com> X-Sender: rkebler@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 05 Jan 2005 18:23:54 -0500 To: Dino Farinacci , pim-state@mountain2sea.com From: Robert Kebler Subject: Re: [Pim-state] Proposal In-Reply-To: <200412310139.iBV1dwJ09411@dino-lnx.cisco.com> References: <4.2.0.58.20041215182440.00cc5b70@mailhost.avici.com> <039001c4e279$876bb6c0$4abb16ac@alcatelxp> <039001c4e279$876bb6c0$4abb16ac@alcatelxp> <4.2.0.58.20041215182440.00cc5b70@mailhost.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 05 Jan 2005 23:16:35 -0000 Dino, Here are just a couple small comments for now. >Robert>> >[5] What do receivers of JP-Acks do: >Robert>> > >Robert>> > o Regardless if you sent an JP or not, for each entry in >the JP which >Robert>> > you have state for, set the Ack-Received flag to TRUE so >at the next >Robert>> > periodic interval, the route is not included in a >periodic JP. During >Robert>> > steady-state, there will be no routes with Ack-Received >equal to >Robert>> > FALSE, >Robert>> > so no JPs are sent. >Robert>> >Robert>> ...assuming ACK came from correct RPF neighbor. > > Well, actually no, because if you have changed RPF neighbors, an JP-Ack > for a prune-list JP may have come from an old RPF neighbor. But I would > agree for a JP with join-list entries, if received from the not current > RPF neighbor, can be ignored. I would go farther and say, that if you > have the retransmission timer running and you change RPF neighbors, any > join-state entries can have the timer canceled (or more likely restarted > because you triggered a join to the new RPF neighbor). In the case of RPF change and we send Prunes to old upstream neighbor, I think we should send Prunes but disregard the ACKS (or indicate that ACKS are not needed). That is, we only need to care about ACKs that come from RPF neighbors. It would just be unnecessary overhead to deal with Prune ACKs from old RPF neighbors. >Robert>> >[10] RPF Changes: >Robert>> > >Robert>> > o When an RPF neighbor change occurs, a JP with join-list >entries is sent >Robert>> > to the newly determined RPF neighbor. It is optional to >also send a >Robert>> > JP with prune-list entries to the previous RPF neighbor. >In the later >Robert>> > case, while the JP-prune-list sender is waiting for a >JP-Ack from the >Robert>> > previous RPF neighbor, other RPF change could occur. An >implementation >Robert>> > has to remember the previous RPF neighbors so it can make >sure the >Robert>> > prune-list JP gets reliably sent. >Robert>> >Robert>> The Sparse Draft indicates on an RPF change, a Prune is sent to >the old >Robert>> neighbor and >Robert>> a Join to the new neighbor. To be consistent with that spec, >this could >Robert>> say that >Robert>> a Prune is sent but not necessarily reliably. You could have some >Robert>> indication that a >Robert>> JP msg does not need to be ACKed. > > Yes, realize this. But many are questioning if this is necessary. You > make > a good point but I would argue, if you don't want it reliable, then > missing > it isn't a big deal. And if it isn't a big deal, why send it in the first > place. I think the Prunes should still be sent, but not reliably. We have longer timeouts now so there is even more reason to send Prunes. From ycai@cypher.cisco.com Thu Jan 6 15:24:06 2005 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j06KO53s010809 for ; Thu, 6 Jan 2005 15:24:06 -0500 (EST) (envelope-from ycai@cypher.cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 06 Jan 2005 12:32:23 -0800 Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j06KNvvl022535; Thu, 6 Jan 2005 12:23:58 -0800 (PST) Received: (from ycai@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA10849; Thu, 6 Jan 2005 12:23:57 -0800 (PST) Date: Thu, 6 Jan 2005 12:23:57 -0800 (PST) Message-Id: <200501062023.MAA10849@cisco.com> X-Authentication-Warning: cypher.cisco.com: ycai set sender to ycai@cypher.cisco.com using -f From: Yiqun Cai To: suresh.boddapati@alcatel.com In-reply-to: <038a01c4f372$50e43190$4abb16ac@alcatelxp> (suresh.boddapati@alcatel.com) Subject: Re: [Pim-state] Proposal References: <038a01c4f372$50e43190$4abb16ac@alcatelxp> Cc: pim-state@mountain2sea.com, Yetik_Serbest@labs.sbc.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: ycai@cisco.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 06 Jan 2005 20:24:10 -0000 > Importance: Normal > > > > >> You are assuming that the eavesdropping will always begin before > any > > PIM > > >> JP packets have been exchanged. Today, that's not the case. The > > >> eavesdropping can occur any time and the state can be built. To > require > > >> the eavesdropping to begin before any JP messages are sent is a big > > >> restriction, isn't it? If the network is stable after the initial > JP > > >> exchange (i.e. there are no triggered changes) and then the > > >> eavesdropping begins, how does the switch acquire the state? > > > > The proposal I forwarded has a GENID-of-0 Hello that can be used > to > > probe for state. Just like you said. > > > > Your GENID-of-0 Hello proposal is for a router, not for a switch (in > your proposal this hello is unicast to a downstream router). Why would > the switch send out a Hello, to whom? When a switch receives the first PIM Hello from a router, it can do the following before forwarding the Hello downstream, 1. if the PIM Hello doesn't have a GenID, the switch inserts a GenID of 0, 2. if the PIM Hello does have a GenID, the switch remembers the GenID received and changes it to 0 in the Hello packet going out, > > > >> Lost from whose point of view? A switch may not see it, but the > > upstream > > >> router (which may be on the same physical LAN as the downstream > router, > > >> not going through that switch) may see it and may ack it. Same > thing > > > > But the JPs are multicasted. And since these are link-local > > multicasts, > > all switches must see them. > > Of course they are multicast. But you can drop a packet for many reasons > (not having rx buffers etc). Just because the pkt is on the wire does > not mean the packet will definitely be consumed and processed. If the > switch is busy and has to drop a few control frames, it may not see the > JP exchange. > > > > > >> goes for ACK. Not every downstream router and switch may see the > ACK. > > >> How does the switch acquire the state then if it does not see the > JP or > > >> JP ACK? If there is such a failure scenario and there are periodic > > >> messages, the switch will eventually build its state. > > > > JP-Acks are link-local multicasted as well. > > > Same as above. > > > > > We should get some other opinions from this group regarding this. > > I agree. > > > > > Another question to ask, on Gigabtis ethernet, how much of the > problem > > did > > we solve if we used 9K MTU-sized JP messages and keep the periodic > > transmission? There is some benefit to this but is it enough? > > > Hmm, I'm not sure I see the benefit. Whatever be the size of the JP > message, we are still sending a large number of control octets on the > wire, plus the processing on the upstream router remains the same. > > > > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state > -- Yiqun From suresh.boddapati@alcatel.com Thu Jan 6 18:52:08 2005 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j06Nq66h011131 for ; Thu, 6 Jan 2005 18:52:07 -0500 (EST) (envelope-from suresh.boddapati@alcatel.com) Received: from alcatelxp ([172.22.187.74] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 Jan 2005 15:52:00 -0800 From: "Suresh Boddapati" To: Subject: RE: [Pim-state] Proposal Date: Thu, 6 Jan 2005 15:54:08 -0800 Organization: Alcatel USA Message-ID: <03c101c4f44b$04632ef0$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200501062023.MAA10849@cisco.com> Importance: Normal X-OriginalArrivalTime: 06 Jan 2005 23:52:00.0441 (UTC) FILETIME=[B6C61A90:01C4F44A] Cc: pim-state@mountain2sea.com, Yetik_Serbest@labs.sbc.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: suresh.boddapati@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 06 Jan 2005 23:52:08 -0000 > When a switch receives the first PIM Hello from a router, it can do > the following before forwarding the Hello downstream, > > 1. if the PIM Hello doesn't have a GenID, the switch inserts a GenID > of 0, > > 2. if the PIM Hello does have a GenID, the switch remembers the GenID > received and changes it to 0 in the Hello packet going out, > > Consider an example. The switched network consists of two switches A & B which are interconnected. If the upstream and downstream routers are connected to A. The link between A & B is down. The JP Exchange happens. Now the link between A & B comes up, and B sees the upstream router's hello for the first time, it does it no good to insert/modify the genID and send it downstream on other ports. It is not going to acquire the downstream router's state because the downstream router is connected to A and does not see the 0 genID pkt. Also if there are N routers when the switch comes up, it would send out N Hellos inserting/remembering+modifying the GenID. If a new router comes up on the LAN, the switch would do the same, which is unnecessary, because that router is not an upstream router for any state. If you want the switch to initiate acquiring of snooping state, why not just make the switch send out one pkt, (a new pkt type of course) like I was suggesting, when it comes up or starts snooping, telling everyone to refresh their downstream states? Keeps it simple, doesn't it? Suresh From ycai@cypher.cisco.com Thu Jan 6 19:21:13 2005 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j070LDRI011191 for ; Thu, 6 Jan 2005 19:21:13 -0500 (EST) (envelope-from ycai@cypher.cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 06 Jan 2005 16:29:33 -0800 Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j070L0l2009736; Thu, 6 Jan 2005 16:21:00 -0800 (PST) Received: (from ycai@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA22089; Thu, 6 Jan 2005 16:21:05 -0800 (PST) Date: Thu, 6 Jan 2005 16:21:05 -0800 (PST) Message-Id: <200501070021.QAA22089@cisco.com> X-Authentication-Warning: cypher.cisco.com: ycai set sender to ycai@cypher.cisco.com using -f From: Yiqun Cai To: suresh.boddapati@alcatel.com In-reply-to: <03c101c4f44b$04632ef0$4abb16ac@alcatelxp> (suresh.boddapati@alcatel.com) Subject: Re: [Pim-state] Proposal References: <03c101c4f44b$04632ef0$4abb16ac@alcatelxp> Cc: pim-state@mountain2sea.com, Yetik_Serbest@labs.sbc.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: ycai@cisco.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Jan 2005 00:21:14 -0000 > Importance: Normal > > > > > When a switch receives the first PIM Hello from a router, it can do > > the following before forwarding the Hello downstream, > > > > 1. if the PIM Hello doesn't have a GenID, the switch inserts a GenID > > of 0, > > > > 2. if the PIM Hello does have a GenID, the switch remembers the GenID > > received and changes it to 0 in the Hello packet going out, > > > > > Consider an example. The switched network consists of two switches A & B > which are interconnected. If the upstream and downstream routers are > connected to A. The link between A & B is down. The JP Exchange happens. > Now the link between A & B comes up, and B sees the upstream router's > hello for the first time, it does it no good to insert/modify the genID > and send it downstream on other ports. It is not going to acquire the > downstream router's state because the downstream router is connected to > A and does not see the 0 genID pkt. In this example, the traffic would not flow through B, so why does it matter whether B has states or not? > > Also if there are N routers when the switch comes up, it would send out > N Hellos inserting/remembering+modifying the GenID. If a new router > comes up on the LAN, the switch would do the same, which is unnecessary, > because that router is not an upstream router for any state. > > If you want the switch to initiate acquiring of snooping state, why not > just make the switch send out one pkt, (a new pkt type of course) like I > was suggesting, when it comes up or starts snooping, telling everyone to > refresh their downstream states? Keeps it simple, doesn't it? > I don't agree. The new message does basically what GenID-0 Hello does, so why have two messages of similar semantics? -- Yiqun From sboddapa@yahoo.com Thu Jan 6 21:29:40 2005 Received: from web81310.mail.yahoo.com (web81310.mail.yahoo.com [206.190.37.85]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j072Te7O011387 for ; Thu, 6 Jan 2005 21:29:40 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050107022934.38087.qmail@web81310.mail.yahoo.com> Received: from [64.163.214.249] by web81310.mail.yahoo.com via HTTP; Thu, 06 Jan 2005 18:29:34 PST Date: Thu, 6 Jan 2005 18:29:34 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] Proposal To: ycai@cisco.com, suresh.boddapati@alcatel.com In-Reply-To: <200501070021.QAA22089@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pim-state@mountain2sea.com, Yetik_Serbest@labs.sbc.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Jan 2005 02:29:40 -0000 > > In this example, the traffic would not flow through > B, so why does it > matter whether B has states or not? > Because there could be other downstream routers connected to B. All routers connected to A & B are on the same LAN, same subnet. It's just that the two switches are interconnected. > > > > Also if there are N routers when the switch comes > up, it would send out > > N Hellos inserting/remembering+modifying the > GenID. If a new router > > comes up on the LAN, the switch would do the same, > which is unnecessary, > > because that router is not an upstream router for > any state. > > > > If you want the switch to initiate acquiring of > snooping state, why not > > just make the switch send out one pkt, (a new pkt > type of course) like I > > was suggesting, when it comes up or starts > snooping, telling everyone to > > refresh their downstream states? Keeps it simple, > doesn't it? > > > > I don't agree. The new message does basically what > GenID-0 Hello > does, so why have two messages of similar semantics? > For the following reasons: First off, you have to have the switch look at every hello packet and determine if this is a first hello or not (which means it has to keep a list of known routers from which hellos have been received on the LAN for this purpose), then modify the hello packet sent by a router, possibly insert a gen ID; processing that can be avoided (contrast this with the switch just sending one message on the LAN when it comes up, no additional state required). Plus, this is not always achieving the intended result as I described above. Second, the switch has to do this for every router on the LAN, having to remember the original genID from every router(why?). Third, the switch would do this even if a new router comes up, totally unnecessary. From dino@dino-lnx.cisco.com Thu Jan 6 22:27:18 2005 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j073RHI8011483 for ; Thu, 6 Jan 2005 22:27:18 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 06 Jan 2005 19:27:55 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j073R81X003206; Thu, 6 Jan 2005 19:27:10 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j073R7jR007146; Thu, 6 Jan 2005 19:27:07 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j073R7XR007142; Thu, 6 Jan 2005 19:27:07 -0800 Date: Thu, 6 Jan 2005 19:27:07 -0800 Message-Id: <200501070327.j073R7XR007142@dino-lnx.cisco.com> From: Dino Farinacci To: rkebler@avici.com In-reply-to: <4.2.0.58.20050105180513.00bc3f00@mailhost.avici.com> (message from Robert Kebler on Wed, 05 Jan 2005 18:23:54 -0500) Subject: Re: [Pim-state] Proposal References: <4.2.0.58.20041215182440.00cc5b70@mailhost.avici.com> <039001c4e279$876bb6c0$4abb16ac@alcatelxp> <039001c4e279$876bb6c0$4abb16ac@alcatelxp> <4.2.0.58.20041215182440.00cc5b70@mailhost.avici.com> <4.2.0.58.20050105180513.00bc3f00@mailhost.avici.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Jan 2005 03:27:22 -0000 >> In the case of RPF change and we send Prunes to old upstream neighbor, I >> think we >> should send Prunes but disregard the ACKS (or indicate that ACKS are not >> needed). Yes, we talked about that. I am actually fine with this. >> That is, we only need to care about ACKs that come from RPF neighbors. It >> would >> just be unnecessary overhead to deal with Prune ACKs from old RPF neighbors. Agree. >> I think the Prunes should still be sent, but not reliably. We have longer >> timeouts now >> so there is even more reason to send Prunes. And if the prune is lost, isn't it more reason to send them reliably? Dino From venu.hemige@alcatel.com Fri Jan 7 00:33:07 2005 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j075X4ni011680 for ; Fri, 7 Jan 2005 00:33:07 -0500 (EST) (envelope-from venu.hemige@alcatel.com) Received: from venuxp ([172.22.187.78] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 Jan 2005 21:32:57 -0800 From: "Venu Hemige" To: "'Dino Farinacci'" , Subject: RE: [Pim-state] Proposal Date: Thu, 6 Jan 2005 21:32:48 -0800 Message-ID: <046601c4f47a$5423db40$4ebb16ac@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200501070327.j073R7XR007142@dino-lnx.cisco.com> X-OriginalArrivalTime: 07 Jan 2005 05:32:57.0849 (UTC) FILETIME=[5856D690:01C4F47A] Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: venu.hemige@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Jan 2005 05:33:07 -0000 Why is it ok if Prunes to an old upstream neighbor are not reliably delivered? With this proposal, if the old upstream neighbor does not receive a prune sent by a downstream router, then it will never age out the Join received by that downstream router. Traffic will be unnecessarily forwarded by the old upstream neighbor for the life of that adjacency only to get dropped at the downstream router due to rpf-mismatch. If the old neighbor is on the same LAN as the new neighbor, it would result in duplicate traffic forwarded to the LAN resulting in ASSERT election. I think ACKs for Prunes would be a must to prevent stale state from being left on the upstream routers. When there are multiple RPF changes happening with ACKs from old rpf neighbors still pending, then the router would have to make sure ACKs from all the routers to which Prunes were sent are received. This can get pretty complex. ACKs per entry (with ACKs being multicast to the LAN) means each router on a LAN has to process the entire J/P pdu twice. In rpf-change or gen-id change scenarios affecting a large number of multicast entries, each entry would have to be processed by each router twice. It is even worse when ACKs are lost since every router on the LAN sees the same J/P pdu within an order of seconds. When a J/P pdu is received with N entries encoded in it, it is unlikely that some of them get ACKed correctly while others do not. ACKing the pdu as opposed to ACKing an entry scales better IMO. And the ACK can be unicast back to the router waiting on the ACK instead of multicasting it to all routers. ACKing each entry keeps changes to a minimal, but if the goal is to scale, it is probably not a good idea. With the refresh mechanism Suresh is proposing, each refresh message-id can potentially represent a large number of entries. It even helps reduce processing overhead on the routers by having timers per message-id as opposed to timers per multicast entry. So processing refresh messages should be fairly light-weight IMO. Relying on refreshes also allows us to lose Prunes and not have stale states left behind. The primary difference in the two proposals has to do with whether to refresh or not. Does everyone feel that refreshes are not required? We have not even looked into Suresh's proposal yet. Should we discuss that as well? Regards, -Venu > -----Original Message----- > From: pim-state-bounces@mountain2sea.com [mailto:pim-state- > bounces@mountain2sea.com] On Behalf Of Dino Farinacci > Sent: Thursday, January 06, 2005 7:27 PM > To: rkebler@avici.com > Cc: pim-state@mountain2sea.com > Subject: Re: [Pim-state] Proposal > > >> In the case of RPF change and we send Prunes to old upstream neighbor, > I > >> think we > >> should send Prunes but disregard the ACKS (or indicate that ACKS are > not > >> needed). > > Yes, we talked about that. I am actually fine with this. > > >> That is, we only need to care about ACKs that come from RPF neighbors. > It > >> would > >> just be unnecessary overhead to deal with Prune ACKs from old RPF > neighbors. > > Agree. > > >> I think the Prunes should still be sent, but not reliably. We have > longer > >> timeouts now > >> so there is even more reason to send Prunes. > > And if the prune is lost, isn't it more reason to send them reliably? > > Dino > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state From dino@dino-lnx.cisco.com Fri Jan 7 01:06:40 2005 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0766dLZ011748 for ; Fri, 7 Jan 2005 01:06:40 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 06 Jan 2005 22:07:18 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j0766WRO005843; Thu, 6 Jan 2005 22:06:32 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j0766Wdd025978; Thu, 6 Jan 2005 22:06:32 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j0766TTF025972; Thu, 6 Jan 2005 22:06:29 -0800 Date: Thu, 6 Jan 2005 22:06:29 -0800 Message-Id: <200501070606.j0766TTF025972@dino-lnx.cisco.com> From: Dino Farinacci To: venu.hemige@alcatel.com In-reply-to: <046601c4f47a$5423db40$4ebb16ac@eng.timetra.com> (venu.hemige@alcatel.com) Subject: Re: [Pim-state] Proposal References: <046601c4f47a$5423db40$4ebb16ac@eng.timetra.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Jan 2005 06:06:40 -0000 >> Why is it ok if Prunes to an old upstream neighbor are not reliably >> delivered? With this proposal, if the old upstream neighbor does not I feel they should be reliably delivered if sent or not sent at all. But indeed since the state is incremental, there are too many cases to make sure the state goes away. Yes, as you say, Asserts can fix it but what about the case where there is a link or node outage upstream, is then repaired, the downstream router RPFs back to the old neighbor but before this the oif-list went to NULL. In this case, the downstream router is in prune mode, the upstream in join mode, and data will flow forever. This is the reason, we indicated in our spec to send the Prune reliably. >> I think ACKs for Prunes would be a must to prevent stale state from >> being left on the upstream routers. When there are multiple RPF changes >> happening with ACKs from old rpf neighbors still pending, then the >> router would have to make sure ACKs from all the routers to which Prunes >> were sent are received. This can get pretty complex. Yes, agree. >> ACKs per entry (with ACKs being multicast to the LAN) means each router >> on a LAN has to process the entire J/P pdu twice. In rpf-change or Yes, this is a good point. Since the join sender is no longer encoded in the JP-Ack message, you can't address the single Ack receiver (i.e. the JP sender). But it does help the Prune-override case. Gives one more chance to fix a single lost packet. >> pdu within an order of seconds. When a J/P pdu is received with N >> entries encoded in it, it is unlikely that some of them get ACKed >> correctly while others do not. ACKing the pdu as opposed to ACKing an I don't understand this point. How do some entries get ack'ed and others don't if they are reflected from the JP. Each entry in the same JP will fate-share. >> correctly while others do not. ACKing the pdu as opposed to ACKing an >> entry scales better IMO. And the ACK can be unicast back to the router It is the same thing. It's saying rather than acking the message, which means every entry in the message is acked, it's just every entry is acked. There is no difference. It's the other level of queuing which is the additional code and level of indirection creates another buffering point in the transmission path. >> With the refresh mechanism Suresh is proposing, each refresh message-id >> can potentially represent a large number of entries. It even helps >> reduce processing overhead on the routers by having timers per >> message-id as opposed to timers per multicast entry. So processing >> refresh messages should be fairly light-weight IMO. Yes, understand. But it is not solving enough of the problem. We have to remove all refresh messages if we want to scale to more entries. We can do refresh on-demand for some cases. Also, consider the situation were millions of entries in the network, with the law of large numbers, will cause *constant/continued* change, so triggered message will be the norm and not the rare exception. >> Relying on refreshes also allows us to lose Prunes and not have stale >> states left behind. The primary difference in the two proposals has to >> do with whether to refresh or not. Does everyone feel that refreshes are We need to reduce number of messages so it should be a requirement to not have refresh messages. >> not required? We have not even looked into Suresh's proposal yet. Should >> we discuss that as well? I got sidetracked with other stuff. But I will send comments to Suresh's proposal this weekend (was suppose to get it done last weekend). Dino From ycai@cypher.cisco.com Fri Jan 7 01:13:11 2005 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j076DBF0011765 for ; Fri, 7 Jan 2005 01:13:11 -0500 (EST) (envelope-from ycai@cypher.cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 06 Jan 2005 23:24:16 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j076D3vl003463; Thu, 6 Jan 2005 22:13:03 -0800 (PST) Received: (from ycai@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA14474; Thu, 6 Jan 2005 22:13:03 -0800 (PST) Date: Thu, 6 Jan 2005 22:13:03 -0800 (PST) Message-Id: <200501070613.WAA14474@cisco.com> X-Authentication-Warning: cypher.cisco.com: ycai set sender to ycai@cypher.cisco.com using -f From: Yiqun Cai To: sboddapa@yahoo.com In-reply-to: <20050107022934.38087.qmail@web81310.mail.yahoo.com> (message from Suresh Boddapati on Thu, 6 Jan 2005 18:29:34 -0800 (PST)) Subject: Re: [Pim-state] Proposal References: <20050107022934.38087.qmail@web81310.mail.yahoo.com> Cc: Yetik_Serbest@labs.sbc.com, pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: ycai@cisco.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Jan 2005 06:13:11 -0000 > > > > > In this example, the traffic would not flow through > > B, so why does it > > matter whether B has states or not? > > > Because there could be other downstream routers > connected to B. All routers connected to A & B are on > the same LAN, same subnet. It's just that the two > switches are interconnected. This is not the case Suresh described, which was the context when I made the above claim. Suresh described a case where all the routers were connected to A only. In the case you described, A would forward the Hellos to B, and B would forward Hellos to these routers, during the process B can modify the GEN-ID if necessary. > > > > > > > Also if there are N routers when the switch comes > > up, it would send out > > > N Hellos inserting/remembering+modifying the > > GenID. If a new router > > > comes up on the LAN, the switch would do the same, > > which is unnecessary, > > > because that router is not an upstream router for > > any state. > > > > > > If you want the switch to initiate acquiring of > > snooping state, why not > > > just make the switch send out one pkt, (a new pkt > > type of course) like I > > > was suggesting, when it comes up or starts > > snooping, telling everyone to > > > refresh their downstream states? Keeps it simple, > > doesn't it? > > > > > > > I don't agree. The new message does basically what > > GenID-0 Hello > > does, so why have two messages of similar semantics? > > > For the following reasons: First off, you have to have > the switch look at every hello packet and determine if > this is a first hello or not (which means it has to > keep a list of known routers from which hellos have > been received on the LAN for this purpose), A PIM snooping switch already does this. > then > modify the hello packet sent by a router, possibly > insert a gen ID; processing that can be avoided > (contrast this with the switch just sending one > message on the LAN when it comes up, no additional > state required). That is a reasonable argument against. > Plus, this is not always achieving > the intended result as I described above. I still don't see the problem you were describing. Perhaps a diagram would help? > Second, the > switch has to do this for every router on the LAN, > having to remember the original genID from every > router(why?). I erred. A switch doesn't have to remember the GenID for this purpose. > Third, the switch would do this even if > a new router comes up, totally unnecessary. > The switch can tell whether this is a new router coming up or not by looking at the holdtime value in the Hello packet and compare it with the uptime of the port from which the Hello was received, if we want to cut that extra GenID-0 packet from the switch. But I'm not sure whether it is worth it. Besides, if the new router comes up and sends a Hello of GenID-0, the switch doesn't have to do anything. In either case, the amount of J/P traffic from downstream is the same. -- Yiqun From venu.hemige@alcatel.com Fri Jan 7 01:50:33 2005 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j076oXwQ011831 for ; Fri, 7 Jan 2005 01:50:33 -0500 (EST) (envelope-from venu.hemige@alcatel.com) Received: from venuxp ([172.22.187.78] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 Jan 2005 22:50:27 -0800 From: "Venu Hemige" To: "'Dino Farinacci'" Subject: RE: [Pim-state] Proposal Date: Thu, 6 Jan 2005 22:50:17 -0800 Message-ID: <046701c4f485$275fbd30$4ebb16ac@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200501070606.j0766TTF025972@dino-lnx.cisco.com> X-OriginalArrivalTime: 07 Jan 2005 06:50:27.0122 (UTC) FILETIME=[2B859920:01C4F485] Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: venu.hemige@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Jan 2005 06:50:33 -0000 Dino, Thanks for your reply. Please see my comments inline: -Venu > > >> pdu within an order of seconds. When a J/P pdu is received with N > >> entries encoded in it, it is unlikely that some of them get ACKed > >> correctly while others do not. ACKing the pdu as opposed to ACKing an > > I don't understand this point. How do some entries get ack'ed and > others > don't if they are reflected from the JP. Each entry in the same JP > will > fate-share. > [Venu Hemige] Exactly my point. Since each entry in the same JP fate-share, it should suffice to ack the JP instead of acking each entry. It reduces the amount of processing required by the routers. > >> correctly while others do not. ACKing the pdu as opposed to ACKing an > >> entry scales better IMO. And the ACK can be unicast back to the router > > It is the same thing. It's saying rather than acking the message, > which > means every entry in the message is acked, it's just every entry is > acked. > There is no difference. > > It's the other level of queuing which is the additional code and level > of > indirection creates another buffering point in the transmission path. > [Venu Hemige] This is where I think we differ. If the JP message (as opposed to each entry in the JP) is acked, it should be a short message. Plus the downstream router waiting on the ack has less processing to do than have to walk all the entries encoded in the JP, thus helping scale better. I agree there is additional code required to manage this extra level of indirection, but it is in the interest of reducing the amount of processing in the routers and thus scaling better. > >> With the refresh mechanism Suresh is proposing, each refresh message-id > >> can potentially represent a large number of entries. It even helps > >> reduce processing overhead on the routers by having timers per > >> message-id as opposed to timers per multicast entry. So processing > >> refresh messages should be fairly light-weight IMO. > > Yes, understand. But it is not solving enough of the problem. We have > to > remove all refresh messages if we want to scale to more entries. We > can > do refresh on-demand for some cases. > > Also, consider the situation were millions of entries in the network, > with > the law of large numbers, will cause *constant/continued* change, so > triggered message will be the norm and not the rare exception. > [Venu Hemige] If we can reduce the refresh messages to a very small percentage of the traffic on the LAN, then is it still bad for scalability? In steady state, even with lets say 1,000,000 entries being refreshed by a router to it's upstream neighbor, the number of refresh messages (assuming mtu of 1500) needed could be as few as 15. And the processing of refresh messages by the downstream & upstream routers would be limited to the order of how many message-ids are active. Assuming 255 entries represented by a message-id, with 15 refresh messages, only 3825 message-ids would be processed to refresh 1,000,000 entries. So, while using this approach does not eliminate refreshes completely (which is probably a good thing), it does not add too much messaging or processing to the routers to affect scalability. -Venu From sboddapa@yahoo.com Fri Jan 7 02:29:13 2005 Received: from web81308.mail.yahoo.com (web81308.mail.yahoo.com [206.190.37.83]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j077TDMo011898 for ; Fri, 7 Jan 2005 02:29:13 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050107072908.53219.qmail@web81308.mail.yahoo.com> Received: from [64.163.214.249] by web81308.mail.yahoo.com via HTTP; Thu, 06 Jan 2005 23:29:08 PST Date: Thu, 6 Jan 2005 23:29:08 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] Proposal To: ycai@cisco.com In-Reply-To: <200501070613.WAA14474@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Yetik_Serbest@labs.sbc.com, pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Jan 2005 07:29:13 -0000 --- Yiqun Cai wrote: > > > > > > > > > In this example, the traffic would not flow > through > > > B, so why does it > > > matter whether B has states or not? > > > > > Because there could be other downstream routers > > connected to B. All routers connected to A & B are > on > > the same LAN, same subnet. It's just that the two > > switches are interconnected. > > This is not the case Suresh described, which was the > context when I > made the above claim. Suresh described a case where > all the routers > were connected to A only. > > In the case you described, A would forward the > Hellos to B, and B > would forward Hellos to these routers, during the > process B can modify > the GEN-ID if necessary. > You are right. My mistake. If all routers are on A, B will not receive traffic until a router connected to B sends Joins. So your scheme would work. > > > then > > modify the hello packet sent by a router, possibly > > insert a gen ID; processing that can be avoided > > (contrast this with the switch just sending one > > message on the LAN when it comes up, no additional > > state required). > > That is a reasonable argument against. Ultimately, we would need some scheme like this only if there are no periodic JP refreshes. That is something we still need to decide on first before we decide which scheme is better. From sboddapa@yahoo.com Fri Jan 7 04:01:04 2005 Received: from web81308.mail.yahoo.com (web81308.mail.yahoo.com [206.190.37.83]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j07914Zg012331 for ; Fri, 7 Jan 2005 04:01:04 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050107090059.64710.qmail@web81308.mail.yahoo.com> Received: from [64.163.214.249] by web81308.mail.yahoo.com via HTTP; Fri, 07 Jan 2005 01:00:59 PST Date: Fri, 7 Jan 2005 01:00:59 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] Proposal To: Dino Farinacci , venu.hemige@alcatel.com In-Reply-To: <200501070606.j0766TTF025972@dino-lnx.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Jan 2005 09:01:04 -0000 > I don't understand this point. How do some > entries get ack'ed and others > don't if they are reflected from the JP. Each > entry in the same JP will > fate-share. > > >> correctly while others do not. ACKing the pdu as > opposed to ACKing an > >> entry scales better IMO. And the ACK can be > unicast back to the router > > It is the same thing. It's saying rather than > acking the message, which > means every entry in the message is acked, it's > just every entry is acked. > There is no difference. > There is a difference. If there is a lot of JP messages being sent to an upstream router, in your scheme the amount of control traffic (in terms of bytes on the wire) will double because of the acks. If the acks are lost, then the JP messages will be retransmitted and reacked, more traffic. In my scheme, the amount of traffic will be a little more than the number of JP messages that are transmitted and retransmitted, not twice, because the ACKs are per message and are much smaller in comparison to the JP messages themselves. Moreover, my scheme allows for multiple message IDs to be acked at once. Also, I am not sure I understand your concern about queueing. Queueing is not always a bad thing. If multiple JP states are to be encoded in one JP message, there has to be queueing. But that is still way better than sending one JP state per JP message. Everybody (hopefully) does this queueing today. Instead of randomly queueing up multiple JP states into a JP message, all my proposal does is makes it a little more deterministic i.e. once a JP state goes into a message, it always stays with that message. Then refreshing just becomes refreshing that message ID, which reduces the processing overhead because now instead of refreshing N states, you are refreshing an aggregate representation of those N states. > >> With the refresh mechanism Suresh is proposing, > each refresh message-id > >> can potentially represent a large number of > entries. It even helps > >> reduce processing overhead on the routers by > having timers per > >> message-id as opposed to timers per multicast > entry. So processing > >> refresh messages should be fairly light-weight > IMO. > > Yes, understand. But it is not solving enough of > the problem. We have to > remove all refresh messages if we want to scale > to more entries. We can > do refresh on-demand for some cases. > You say it is not solving enough of the problem. Goes back to what problem are we trying to solve here. I see the goal as reducing the amount of control traffic and the associated processing required to keep existing state alive, plus providing some sort of reliability so that the downstream router knows whether the upstream router got its Join/Prune or not. Clearly on the reliability front, the amount of control traffic required to achieve this and the processing of this control traffic is much more in your scheme than in the scheme I am suggesting. You seem to suggest that the only way to scale is by eliminating refreshes. As we have discussed, the major con of refresh elimination is persistent state in the event that Prunes are lost until the Prunes are retransmitted and acked. The longer this interval, the longer the persistence of the state. Plus the scheme you are suggesting modifies the protocol in a way that holdtime in the JP PDU always becomes equal to infinity, no matter what the encoded value is and does not give the deployer a choice to decide whether he wants to timeout upstream state or not and still achieve refresh reduction. Is this restriction good? I think not. Maybe the provider does not like Prunes getting lost and state persisting for longer than a particular interval. Maybe all the provider is wishing for is that the control traffic be less than what it is today in stable state, but still wants the capability to timeout upstream state after a certain interval in the absence of any refreshes. These are two different things IMO. > Also, consider the situation were millions of > entries in the network, with > the law of large numbers, will cause > *constant/continued* change, so > triggered message will be the norm and not the > rare exception. > And how much more traffic do you want to generate when we are dealing with large numbers, twice or just a little more than the existing traffic? If millions of entries are changing, do you want to ack them back by replaying the JP PDUs, thus doubling the control traffic or sending shorter acks, much smaller than the JP PDUs? > I got sidetracked with other stuff. But I will > send comments to Suresh's > proposal this weekend (was suppose to get it > done last weekend). Thanks. Looking forward to your comments. Suresh From rkebler@avici.com Fri Jan 7 11:51:00 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j07Gp0kL013268 for ; Fri, 7 Jan 2005 11:51:00 -0500 (EST) (envelope-from rkebler@avici.com) Received: from rkebler-pc (rkebler-pc.avici.com [10.2.20.48]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id j07Gok7l004188 for ; Fri, 7 Jan 2005 11:50:51 -0500 Message-Id: <4.2.0.58.20050107112805.00d0d400@mailhost.avici.com> X-Sender: rkebler@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 07 Jan 2005 11:59:19 -0500 To: pim-state@mountain2sea.com From: Robert Kebler Subject: RE: [Pim-state] Proposal In-Reply-To: <046601c4f47a$5423db40$4ebb16ac@eng.timetra.com> References: <200501070327.j073R7XR007142@dino-lnx.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Jan 2005 16:51:00 -0000 I think that Joins should still have a lifetime and should still be refreshed (30 minutes) even if they are sent reliably. I was trying to propose a way to simplify things by not requiring Prunes to old RPF neighbors be sent reliably. This would be extra state and extra overhead that I think isn't completely necessary. -Bob At 09:32 PM 1/6/05 -0800, you wrote: >Why is it ok if Prunes to an old upstream neighbor are not reliably >delivered? With this proposal, if the old upstream neighbor does not >receive a prune sent by a downstream router, then it will never age out >the Join received by that downstream router. Traffic will be >unnecessarily forwarded by the old upstream neighbor for the life of >that adjacency only to get dropped at the downstream router due to >rpf-mismatch. If the old neighbor is on the same LAN as the new >neighbor, it would result in duplicate traffic forwarded to the LAN >resulting in ASSERT election. > >I think ACKs for Prunes would be a must to prevent stale state from >being left on the upstream routers. When there are multiple RPF changes >happening with ACKs from old rpf neighbors still pending, then the >router would have to make sure ACKs from all the routers to which Prunes >were sent are received. This can get pretty complex. > >ACKs per entry (with ACKs being multicast to the LAN) means each router >on a LAN has to process the entire J/P pdu twice. In rpf-change or >gen-id change scenarios affecting a large number of multicast entries, >each entry would have to be processed by each router twice. It is even >worse when ACKs are lost since every router on the LAN sees the same J/P >pdu within an order of seconds. When a J/P pdu is received with N >entries encoded in it, it is unlikely that some of them get ACKed >correctly while others do not. ACKing the pdu as opposed to ACKing an >entry scales better IMO. And the ACK can be unicast back to the router >waiting on the ACK instead of multicasting it to all routers. ACKing >each entry keeps changes to a minimal, but if the goal is to scale, it >is probably not a good idea. > >With the refresh mechanism Suresh is proposing, each refresh message-id >can potentially represent a large number of entries. It even helps >reduce processing overhead on the routers by having timers per >message-id as opposed to timers per multicast entry. So processing >refresh messages should be fairly light-weight IMO. > >Relying on refreshes also allows us to lose Prunes and not have stale >states left behind. The primary difference in the two proposals has to >do with whether to refresh or not. Does everyone feel that refreshes are >not required? We have not even looked into Suresh's proposal yet. Should >we discuss that as well? > >Regards, >-Venu > > > -----Original Message----- > > From: pim-state-bounces@mountain2sea.com [mailto:pim-state- > > bounces@mountain2sea.com] On Behalf Of Dino Farinacci > > Sent: Thursday, January 06, 2005 7:27 PM > > To: rkebler@avici.com > > Cc: pim-state@mountain2sea.com > > Subject: Re: [Pim-state] Proposal > > > > >> In the case of RPF change and we send Prunes to old upstream >neighbor, > > I > > >> think we > > >> should send Prunes but disregard the ACKS (or indicate that ACKS >are > > not > > >> needed). > > > > Yes, we talked about that. I am actually fine with this. > > > > >> That is, we only need to care about ACKs that come from RPF >neighbors. > > It > > >> would > > >> just be unnecessary overhead to deal with Prune ACKs from old RPF > > neighbors. > > > > Agree. > > > > >> I think the Prunes should still be sent, but not reliably. We have > > longer > > >> timeouts now > > >> so there is even more reason to send Prunes. > > > > And if the prune is lost, isn't it more reason to send them >reliably? > > > > Dino > > _______________________________________________ > > Pim-state mailing list > > Pim-state@mountain2sea.com > > http://www.mountain2sea.com/mailman/listinfo/pim-state From sboddapa@yahoo.com Fri Jan 7 12:31:21 2005 Received: from web81308.mail.yahoo.com (web81308.mail.yahoo.com [206.190.37.83]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j07HVLZQ013342 for ; Fri, 7 Jan 2005 12:31:21 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050107173116.52777.qmail@web81308.mail.yahoo.com> Received: from [64.163.214.249] by web81308.mail.yahoo.com via HTTP; Fri, 07 Jan 2005 09:31:16 PST Date: Fri, 7 Jan 2005 09:31:16 -0800 (PST) From: Suresh Boddapati Subject: RE: [Pim-state] Proposal To: Robert Kebler , pim-state@mountain2sea.com In-Reply-To: <4.2.0.58.20050107112805.00d0d400@mailhost.avici.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Jan 2005 17:31:22 -0000 --- Robert Kebler wrote: > I think that Joins should still have a lifetime and > should still be refreshed > (30 minutes) even if they are sent reliably. > > I was trying to propose a way to simplify things by > not requiring Prunes to > old RPF > neighbors be sent reliably. This would be extra > state and extra overhead > that I > think isn't completely necessary. > Joins and Prunes go in the same Message. If we are talking about acknowledging a Message as a whole as my scheme suggests, for the cases where the Message has at least one Join, the message would still have to be acked (even in Dino's scheme, the whole JP message would come back, so does not matter much if you dont ack the prune, the traffic is the same). The ack for the Prune is at no cost on the wire. The only case that will not be acked to achieve what you want is when the Message contains all Prunes. Plus, this has the issue of possible duplicate traffic like Venu pointed out causing Assert mechanisms to trigger, until the time the upstream state times out at the old router. So there is benefit to sending Prunes reliably as well. Imagine if the state being pruned has a high bandwidth consuming traffic associated with it, you would unnecessarily get traffic. IMO it is better for the downstream router to clean the state up reliably. If your concern is the state persisting at the downstream router until the Prune is acked, whether to wait for Acks or not can be left to the implementation as a configuration knob. Those who want to get rid of the downstream state immediately can choose not to retransmit and not wait for acks if the JP message has only Prunes in it. If there is a combo of Joins and Prunes, the downstream router can get rid of the Pruned states after one (or a fixed number of) retransmissions and resend only the new Joins in the Message with a higher sequence number and wait for that to be acked. Suresh From rkebler@avici.com Fri Jan 7 13:18:37 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j07IIXoQ013421 for ; Fri, 7 Jan 2005 13:18:37 -0500 (EST) (envelope-from rkebler@avici.com) Received: from rkebler-pc (rkebler-pc.avici.com [10.2.20.48]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id j07IIN7l018688; Fri, 7 Jan 2005 13:18:24 -0500 Message-Id: <4.2.0.58.20050107125342.00d265b0@mailhost.avici.com> X-Sender: rkebler@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 07 Jan 2005 13:26:56 -0500 To: Suresh Boddapati , pim-state@mountain2sea.com From: Robert Kebler Subject: RE: [Pim-state] Proposal In-Reply-To: <20050107173116.52777.qmail@web81308.mail.yahoo.com> References: <4.2.0.58.20050107112805.00d0d400@mailhost.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 07 Jan 2005 18:18:37 -0000 At 09:31 AM 1/7/05 -0800, Suresh Boddapati wrote: >--- Robert Kebler wrote: > > > I think that Joins should still have a lifetime and > > should still be refreshed > > (30 minutes) even if they are sent reliably. > > > > > > I was trying to propose a way to simplify things by > > not requiring Prunes to > > old RPF > > neighbors be sent reliably. This would be extra > > state and extra overhead > > that I > > think isn't completely necessary. > > >Joins and Prunes go in the same Message. If we are >talking about acknowledging a Message as a whole as my >scheme suggests, for the cases where the Message has >at least one Join, the message would still have to be >acked (even in Dino's scheme, the whole JP message >would come back, so does not matter much if you dont >ack the prune, the traffic is the same). The ack for >the Prune is at no cost on the wire. The only case >that will not be acked to achieve what you want is >when the Message contains all Prunes. Plus, this has >the issue of possible duplicate traffic like Venu >pointed out causing Assert mechanisms to trigger, >until the time the upstream state times out at the old >router. So there is benefit to sending Prunes reliably >as well. Imagine if the state being pruned has a high >bandwidth consuming traffic associated with it, you >would unnecessarily get traffic. IMO it is better for >the downstream router to clean the state up reliably. > >If your concern is the state persisting at the >downstream router until the Prune is acked, whether to >wait for Acks or not can be left to the implementation >as a configuration knob. Those who want to get rid of >the downstream state immediately can choose not to >retransmit and not wait for acks if the JP message has >only Prunes in it. If there is a combo of Joins and >Prunes, the downstream router can >get rid of the Pruned states after one (or a fixed >number of) retransmissions and resend only the new >Joins in the Message with a higher sequence number and >wait for that to be acked. > > >Suresh I was talking about the case where the RPF neighbor changes and we send triggered Prunes (and only Prunes) to the old RPF neighbor. I completely agree and understand that there are benefits to having Reliable Prunes in this case. There are also benefits to not requiring Reliable Prunes in this case (less state on downstream routers). My preference would be to not require an implementation to send Prunes reliably to old RPF neighbors. From dino@dino-lnx.cisco.com Sat Jan 8 14:16:05 2005 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j08JG4u5016463 for ; Sat, 8 Jan 2005 14:16:04 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 08 Jan 2005 11:17:02 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j08JFsRO025760; Sat, 8 Jan 2005 11:15:55 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j08JFsaW032415; Sat, 8 Jan 2005 11:15:54 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j08JFsHN032411; Sat, 8 Jan 2005 11:15:54 -0800 Date: Sat, 8 Jan 2005 11:15:54 -0800 Message-Id: <200501081915.j08JFsHN032411@dino-lnx.cisco.com> From: Dino Farinacci To: venu.hemige@alcatel.com In-reply-to: <046701c4f485$275fbd30$4ebb16ac@eng.timetra.com> (venu.hemige@alcatel.com) Subject: Re: [Pim-state] Proposal References: <046701c4f485$275fbd30$4ebb16ac@eng.timetra.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 08 Jan 2005 19:16:12 -0000 >> [Venu Hemige] Exactly my point. Since each entry in the same JP >> fate-share, it should suffice to ack the JP instead of acking each >> entry. It reduces the amount of processing required by the routers. Yes, but this is on-demand and not periodically. When the multicast state is quiesent, there is no resource usage. >> [Venu Hemige] This is where I think we differ. If the JP message (as >> opposed to each entry in the JP) is acked, it should be a short message. If you ack a message, that means each state within in the message is acked. I don't see any *semantic* difference. Yes, there is a mechanical difference. >> I agree there is additional code required to manage this extra level of >> indirection, but it is in the interest of reducing the amount of >> processing in the routers and thus scaling better. It increases memory and buffer requirements in the router. We have learned over decades that to deal with routing entry flow control, you need to control the producer so you don't overwelm the consumer. So, you need the flow control throttling done from the routing table. If you don't the producer is the state change routing table and the consumer is the transmission layer. If the producer is changing and the the consumer is slowed because of external events, you create a buffer situation in your transmission layer. If you go this route, you may as well use TCP because it is implemented to already deal with this. Don't duplicate this functionality in PIM. This was the same debate that BGP and IDRP had. BGP decided to use TCP and IDRP did it's own transmission layer. Hence, we have heard that TCP may not be good in this PIM situation so we want to create a very lightweight incremental ack mechanism. The proposal I forwarded to the list needs to be simplified a lot more by the way. >> [Venu Hemige] If we can reduce the refresh messages to a very small >> percentage of the traffic on the LAN, then is it still bad for >> scalability? In steady state, even with lets say 1,000,000 entries being I think it can help for the general case, but am worried about the VPN case. That is a small number of refresh messages M may have to be replicated V times, for V VPNs. V can be very large to overwelm the raw link bandwidth from the router. Dino From sboddapa@yahoo.com Sun Jan 9 01:55:14 2005 Received: from web81302.mail.yahoo.com (web81302.mail.yahoo.com [206.190.37.77]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j096tEsV017872 for ; Sun, 9 Jan 2005 01:55:14 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050109065509.49942.qmail@web81302.mail.yahoo.com> Received: from [64.172.59.150] by web81302.mail.yahoo.com via HTTP; Sat, 08 Jan 2005 22:55:09 PST Date: Sat, 8 Jan 2005 22:55:09 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] Proposal To: Dino Farinacci , venu.hemige@alcatel.com In-Reply-To: <200501081915.j08JFsHN032411@dino-lnx.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sun, 09 Jan 2005 06:55:14 -0000 > It increases memory and buffer requirements in > the router. We have learned > over decades that to deal with routing entry > flow control, you need to > control the producer so you don't overwelm the > consumer. So, you need > the flow control throttling done from the > routing table. > > If you don't the producer is the state change > routing table and the > consumer is the transmission layer. If the > producer is changing and the > the consumer is slowed because of external > events, you create a buffer > situation in your transmission layer. Where is the consumer getting slowed in this case? The consumer does not have a transmission window like TCP does because it knows what it is sending, not like TCP, a pure transport. In my proposal, there is no slowdown like TCP. If there is state to be acked and that state changes, what is outstanding is the union of the old and new state, the outstanding (to be acked) buffer is only one, not two. Slowdown would occur if we did not send the latest state until the old state was acked (ala TCP). This is not the case in my scheme. In fact, it is your proposal that actually delays sending a Join or Prune in the event that there is a situation where a Join, Prune, Join combination needs to be sent for the same state and the ack has not been received for the first join. You propose delaying sending the second Join because you cannot distinguish whether the ack was for the first join or the second. Whereas my proposal just uses sequence numbers and does not have to delay sending the second Join. It would just send out with the higher sequence number. It does not wait for the lower sequence number to be acked before sending the message with a higher sequence number. Where is the flow control issue here? > > If you go this route, you may as well use TCP > because it is implemented > to already deal with this. Don't duplicate this > functionality in PIM. Please, we are not duplicating TCP functionality in PIM. We are not introducing any delays, any transmission windows, nor are we requiring any flow control schemes. We are simply introducing a sequence number to keep track of the latest state, to determine whether what is being acked is the latest state or an older one. From dino@dino-lnx.cisco.com Sun Jan 9 23:55:19 2005 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0A4tJR2020122 for ; Sun, 9 Jan 2005 23:55:19 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 09 Jan 2005 20:56:34 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0A4t3ej013120; Sun, 9 Jan 2005 20:55:11 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j0A2AeIA027083; Sun, 9 Jan 2005 18:10:40 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j0A2AeHY027079; Sun, 9 Jan 2005 18:10:40 -0800 Date: Sun, 9 Jan 2005 18:10:40 -0800 Message-Id: <200501100210.j0A2AeHY027079@dino-lnx.cisco.com> From: Dino Farinacci To: sboddapa@yahoo.com In-reply-to: <20050109065509.49942.qmail@web81302.mail.yahoo.com> (message from Suresh Boddapati on Sat, 8 Jan 2005 22:55:09 -0800 (PST)) Subject: Re: [Pim-state] Proposal References: <20050109065509.49942.qmail@web81302.mail.yahoo.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 10 Jan 2005 04:55:19 -0000 >> Where is the consumer getting slowed in this case? The >> consumer does not have a transmission window like TCP >> does because it knows what it is sending, not like >> TCP, a pure transport. In my proposal, there is no You have an external Ack that speeds up the consumer. But the producer can offer at a faster rate. The point is there is a toggle of state sitting in the retransmission queues which is unnecessary. That is the "queuing problem" I vaguely was referring to. >> In fact, it is your proposal that actually delays >> sending a Join or Prune in the event that there is a >> situation where a Join, Prune, Join combination needs >> to be sent for the same state and the ack has not been >> received for the first join. You propose delaying >> sending the second Join because you cannot distinguish >> whether the ack was for the first join or the second. This is incorrect. The delay is good, because it damps state transitions. In your proposal, all of a (join1,prune2,join2,prune2,join3} would get queued sent, and acked. Where you really only need to know that an upstream router has acked some sort of binary state either the latest join or prune. In our proposal, if all 5 changes occured before join1-ack came back, then only {join1,join3} would be sent. In yours, all 5 is being sent which results in more messages. >> > >> > If you go this route, you may as well use TCP >> > because it is implemented >> > to already deal with this. Don't duplicate this >> > functionality in PIM. >> Please, we are not duplicating TCP functionality in >> PIM. We are not introducing any delays, any >> transmission windows, nor are we requiring any flow >> control schemes. We are simply introducing a sequence >> number to keep track of the latest state, to determine >> whether what is being acked is the latest state or an >> older one. I didn't say you were. But I said if you are going to implement a lot of transport like protocol in PIM, one should consider using TCP. Dino From venu.hemige@alcatel.com Mon Jan 10 14:54:33 2005 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0AJsXZT021783 for ; Mon, 10 Jan 2005 14:54:33 -0500 (EST) (envelope-from venu.hemige@alcatel.com) Received: from venuxp ([172.22.187.78] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 10 Jan 2005 11:53:33 -0800 From: "Venu Hemige" To: "'Dino Farinacci'" Subject: RE: [Pim-state] Proposal Date: Mon, 10 Jan 2005 11:53:25 -0800 Message-ID: <04a201c4f74e$0d5328c0$4ebb16ac@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200501081915.j08JFsHN032411@dino-lnx.cisco.com> X-OriginalArrivalTime: 10 Jan 2005 19:53:33.0644 (UTC) FILETIME=[10E920C0:01C4F74E] Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: venu.hemige@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 10 Jan 2005 19:54:34 -0000 Dino, Replying to one of your older emails: > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Saturday, January 08, 2005 11:16 AM > To: venu.hemige@alcatel.com > Cc: rkebler@avici.com; pim-state@mountain2sea.com > Subject: Re: [Pim-state] Proposal > > >> [Venu Hemige] Exactly my point. Since each entry in the same JP > >> fate-share, it should suffice to ack the JP instead of acking each > >> entry. It reduces the amount of processing required by the routers. > > Yes, but this is on-demand and not periodically. When the multicast > state > is quiesent, there is no resource usage. > When an interface or a router comes up or if there is a topology change, there can be a very large number of JPs (think 100s of thousands or larger). By acking each entry, every router is spending twice the time they would have normally spent. By acking messages, every router spends only 1x the time AND only the router that is waiting on acks spends a trifle more. About unicasting or multicasting the ack, I do not agree that prune-override should be the reason to multicast the ack. The upstream router then does a prune-echo after that anyway. So if you are considering only prunes, there is actually 3x the amount of traffic and processing to be done on all routers on the LAN. > >> [Venu Hemige] This is where I think we differ. If the JP message (as > >> opposed to each entry in the JP) is acked, it should be a short > message. > > If you ack a message, that means each state within in the message is > acked. I don't see any *semantic* difference. Yes, there is a > mechanical > difference. Yes, there is no semantic difference. It achieves the same. But it does save processing time on the routers and helps scaling better. When you talk in the order of a million entries, the savings become quite apparent. > > >> I agree there is additional code required to manage this extra level of > >> indirection, but it is in the interest of reducing the amount of > >> processing in the routers and thus scaling better. > > It increases memory and buffer requirements in the router. We have > learned > over decades that to deal with routing entry flow control, you need to > control the producer so you don't overwelm the consumer. So, you need > the flow control throttling done from the routing table. > > If you don't the producer is the state change routing table and the > consumer is the transmission layer. If the producer is changing and > the > the consumer is slowed because of external events, you create a buffer > situation in your transmission layer. > If implemented right, the memory requirements are a small delta over current memory usage in PIM. There is no complex queueing logic this would add either. Today's implementations have to pack multiple JP entries in a pdu. The same queueing logic used to do this can be used to add the extra indirection we are proposing here. Yes, there is additional code required, but the amount of memory it adds should not be a concern. Even in your approach, you would have to keep a retransmission queue to retransmit JPs when acks are not received. It is the same here. The complexity of additional code required is not much different. Regarding buffer requirements, I agree you need to control the producer so you do not overwhelm the consumer. That applies even today with PIM. Unless the producer (sender of JP messages) "paces" the messages, the consumer might get overwhelmed and start dropping some of them. The same pacing requirement applies to this too. Just because the producer gets more time because it has optimized things does not mean it should throttle the consumer. The extra time can be used to do other work thus helping scale better. Look at the benefits of doing this: it obviously means less processing time in the routers to achieve the same semantic objective. It means a lot fewer Downstream JP and Upstream JP timers than we currently use (as few as approx 4000 for a million entries). Refreshes are very light-weight, both in the amount of messages generated and the amount of processing time spent on the routers, as I mentioned in the previous email with the 1 million entries example. > If you go this route, you may as well use TCP because it is > implemented > to already deal with this. Don't duplicate this functionality in PIM. > > This was the same debate that BGP and IDRP had. BGP decided to use TCP > and IDRP did it's own transmission layer. Hence, we have heard that > TCP > may not be good in this PIM situation so we want to create a very > lightweight incremental ack mechanism. > > The proposal I forwarded to the list needs to be simplified a lot more > by the way. > This proposal is not suggesting anything like TCP. It is very light-weight and in-fact quite similar to what you are proposing. The only difference is you are suggesting we do it per entry and we are saying it is better to do it per message. If a message-id is not acked, the producer does not have to remember to retransmit the same message-id to JP entries mapping. It can change the mapping per it's current state at the time. So there is no complex retransmission logic to be remembered at the producer. > >> [Venu Hemige] If we can reduce the refresh messages to a very small > >> percentage of the traffic on the LAN, then is it still bad for > >> scalability? In steady state, even with lets say 1,000,000 entries > being > > I think it can help for the general case, but am worried about the > VPN case. That is a small number of refresh messages M may have to > be replicated V times, for V VPNs. V can be very large to overwelm the > raw link bandwidth from the router. > I just gave an example for a million entries and showed how small the bandwidth usage is for that. However you divide a million entries among V VPNs, I do not see how it greatly changes the raw link bandwidth usage. With very large number of VPNs, the number of refresh messages per VPN will be very small and the message sizes will also be small. I do not see how it would overwhelm the raw link badwidth. We can talk examples if that helps. -Venu From sboddapa@yahoo.com Mon Jan 10 22:11:12 2005 Received: from web81305.mail.yahoo.com (web81305.mail.yahoo.com [206.190.37.80]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j0B3BCTp022477 for ; Mon, 10 Jan 2005 22:11:12 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050111031107.97663.qmail@web81305.mail.yahoo.com> Received: from [67.123.82.41] by web81305.mail.yahoo.com via HTTP; Mon, 10 Jan 2005 19:11:07 PST Date: Mon, 10 Jan 2005 19:11:07 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] Proposal To: Dino Farinacci In-Reply-To: <200501100210.j0A2AeHY027079@dino-lnx.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 11 Jan 2005 03:11:12 -0000 > >> Where is the consumer getting slowed in this case? The > >> consumer does not have a transmission window like TCP > >> does because it knows what it is sending, not like > >> TCP, a pure transport. In my proposal, there is no > You have an external Ack that speeds up the >consumer. >But the >producer can > offer at a faster rate. > The point is there is a toggle of state sitting in >the >retransmission > queues which is unnecessary. That is >the "queuing problem" I >vaguely > was referring to. I still do not understand what you mean by "toggle of state sitting in the retransmission queue". If a state sends from J to P to J, what sits in the retransmission queue is the final J, not the first two J & Ps. Can you please explain with an example what exactly you mean? > >> In fact, it is your proposal that actually delays > >> sending a Join or Prune in the event that there > is a > >> situation where a Join, Prune, Join combination > needs > >> to be sent for the same state and the ack has not > been > >> received for the first join. You propose delaying > >> sending the second Join because you cannot > distinguish > >> whether the ack was for the first join or the > second. > > This is incorrect. The delay is good, because it > damps state transitions. > In your proposal, all of a > (join1,prune2,join2,prune2,join3} would get > queued sent, and acked. Where you really only > need to know that an > upstream router has acked some sort of binary > state either the latest > join or prune. In our proposal, if all 5 changes > occured before join1-ack > came back, then only {join1,join3} would be > sent. In yours, all 5 is being > sent which results in more messages. > You say you do not like queueing; at the same time, you describe what is happening above as damping, even though it is a kind of queueing (you are remembering two states, the previous join and the new one). How is this binary state? What if the old Join and the subsequent Prune are lost, you would have to retransmit all your first Joins until they are acked before you send the second one because you still want to override the Prune in between with the final Join (you as a sender do not know if the Join and Prune are lost). More messages here as well right, since retransmissions have to occur for the first Joins, until they are acked followed by the second Joins, since you can never be sure if the ack you received was sent before or after you sent the Prune? (The upstream nbr may be horribly slow and the first join and the subsequent Prune might be sitting in its rx buffers and your subsequent Joins may get lost). This is the problem I was talking about. Clearly in your scheme, you cannot distinguish between the ack for the first Join and that for the second Join; there is nothing in the PDU that can tell you the difference. Is there? With the Message scheme, retransmissions will not have to occur for the first Joins, only the last one. Damping is a separate issue. Both our proposals can achieve damping wherein an update can be generated only after a certain amount of time to make sure that we dont send out state changes as soon as they occur or penalize an update if it is changing too often. I am sure we can come up with best and worst cases in each scheme where one generates more messages than the other. If the argument is about keeping the latest state, clearly the Message scheme achieves that without exception with sequence numbers. If the argument is about queueing, I do not still see where the additional queueing comes into picture with the Message scheme. If the argument is about memory, then yes, the Message scheme takes up a little more memory, but the benefits in terms of processor cycle savings and the reduction in bytes on the wire are significant enough to warrant it. Suresh From yakov@juniper.net Mon Jan 17 18:24:51 2005 Received: from colo-dns-ext2.juniper.net (colo-dns-ext2.juniper.net [207.17.137.64]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0HNOoqS063354 for ; Mon, 17 Jan 2005 18:24:50 -0500 (EST) (envelope-from yakov@juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j0HNOhBm044375; Mon, 17 Jan 2005 15:24:43 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j0HNOVe11833; Mon, 17 Jan 2005 15:24:31 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200501172324.j0HNOVe11833@merlot.juniper.net> To: Dino Farinacci Subject: Re: [Pim-state] Proposal In-Reply-To: Your message of "Sat, 08 Jan 2005 11:15:54 PST." <200501081915.j08JFsHN032411@dino-lnx.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20593.1106004271.1@juniper.net> Date: Mon, 17 Jan 2005 15:24:31 -0800 From: Yakov Rekhter Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 17 Jan 2005 23:24:51 -0000 Dino, > It increases memory and buffer requirements in the router. We have learned > over decades that to deal with routing entry flow control, you need to > control the producer so you don't overwelm the consumer. So, you need > the flow control throttling done from the routing table. > > If you don't the producer is the state change routing table and the > consumer is the transmission layer. If the producer is changing and the > the consumer is slowed because of external events, you create a buffer > situation in your transmission layer. > > If you go this route, you may as well use TCP because it is implemented > to already deal with this. Don't duplicate this functionality in PIM. > > This was the same debate that BGP and IDRP had. BGP decided to use TCP > and IDRP did it's own transmission layer. Hence, we have heard that TCP > may not be good in this PIM situation so we want to create a very > lightweight incremental ack mechanism. I'd like to get the record straight on the issue of transport for BGP and IDRP. Folks who designed BGP decided to use TCP as a reliable transport because they were driven by purely *pragmatic* considerations, and were not constrained by other than pragmatic considerations. Use of TCP allowed them to avoid re-inventing/implementing/debugging yet another transport protocol. Folks who designed IDRP operated in a quite different environment, as they had to go through the OSI/ANSI X3S3.3 committee, and some folks on that committee had problems with using TP4 as a reliable transport. That is why IDRP "did it's own transmission layer". But to be honest I have to acknowledge that the IDRP's "own tranmission layer" was *not* invented from scratch, but rather borrowed heavily (to say the least) from an existing protocol. Yakov. From pusateri@juniper.net Mon Jan 17 18:38:39 2005 Received: from colo-dns-ext2.juniper.net (colo-dns-ext2.juniper.net [207.17.137.64]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0HNcdZK063387 for ; Mon, 17 Jan 2005 18:38:39 -0500 (EST) (envelope-from pusateri@juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j0HNcXBm044477; Mon, 17 Jan 2005 15:38:33 -0800 (PST) (envelope-from pusateri@juniper.net) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j0HNcXe13970; Mon, 17 Jan 2005 15:38:33 -0800 (PST) (envelope-from pusateri@juniper.net) Message-Id: <200501172338.j0HNcXe13970@merlot.juniper.net> To: Yakov Rekhter Subject: Re: [Pim-state] Proposal In-Reply-To: Message from Yakov Rekhter of "Mon, 17 Jan 2005 15:24:31 PST." <200501172324.j0HNOVe11833@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <94516.1106005113.1@juniper.net> Date: Mon, 17 Jan 2005 15:38:33 -0800 From: Tom Pusateri Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 17 Jan 2005 23:38:39 -0000 In message <200501172324.j0HNOVe11833@merlot.juniper.net> you write: >Dino, > >> It increases memory and buffer requirements in the router. We have learn >ed >> over decades that to deal with routing entry flow control, you need to >> control the producer so you don't overwelm the consumer. So, you need >> the flow control throttling done from the routing table. >> >> If you don't the producer is the state change routing table and the >> consumer is the transmission layer. If the producer is changing and the >> the consumer is slowed because of external events, you create a buffer >> situation in your transmission layer. >> >> If you go this route, you may as well use TCP because it is implemented >> to already deal with this. Don't duplicate this functionality in PIM. >> >> This was the same debate that BGP and IDRP had. BGP decided to use TCP >> and IDRP did it's own transmission layer. Hence, we have heard that TCP >> may not be good in this PIM situation so we want to create a very >> lightweight incremental ack mechanism. > >I'd like to get the record straight on the issue of transport for BGP >and IDRP. > >Folks who designed BGP decided to use TCP as a reliable transport >because they were driven by purely *pragmatic* considerations, and >were not constrained by other than pragmatic considerations. Use >of TCP allowed them to avoid re-inventing/implementing/debugging >yet another transport protocol. > >Folks who designed IDRP operated in a quite different environment, >as they had to go through the OSI/ANSI X3S3.3 committee, and some >folks on that committee had problems with using TP4 as a reliable >transport. That is why IDRP "did it's own transmission layer". But >to be honest I have to acknowledge that the IDRP's "own tranmission >layer" was *not* invented from scratch, but rather borrowed heavily >(to say the least) from an existing protocol. > >Yakov. When implementing MSDP, I had to put in so much code overhead to reliably deal with TCP re-assembly and buffer management that I REALLY don't want to go down that path again. There is a simplistic beauty associated with self contained message packets that make error condition handling so much easier than stream protocols that adding reliability to PIM packets is much preferred for me than moving to TCP. As an example, if you have a TLV that is encoded incorrectly and you send it over a stream protocol, there is no way to recover from it except to hopefully be able to detect the condition and tear down the connection. This eats a lot of resources since you will be more than likely opening it up again and tearing it down again due to the same bug. With packet based messages, you just throw it away and continue. Tom From yakov@juniper.net Tue Jan 18 07:45:41 2005 Received: from colo-dns-ext1.juniper.net (colo-dns-ext1.juniper.net [207.17.137.57]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0ICjfh2064884 for ; Tue, 18 Jan 2005 07:45:41 -0500 (EST) (envelope-from yakov@juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j0ICjV999218; Tue, 18 Jan 2005 04:45:35 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j0ICjQe03846; Tue, 18 Jan 2005 04:45:26 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200501181245.j0ICjQe03846@merlot.juniper.net> To: Dino Farinacci Subject: Re: [Pim-state] Proposal In-Reply-To: Your message of "Sat, 08 Jan 2005 11:15:54 PST." <200501081915.j08JFsHN032411@dino-lnx.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <67605.1106052325.1@juniper.net> Date: Tue, 18 Jan 2005 04:45:25 -0800 From: Yakov Rekhter Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 18 Jan 2005 12:45:42 -0000 Dino, [clipped...] Just to add to the e-mail I sent yesterday... > It increases memory and buffer requirements in the router. We have learned > over decades that to deal with routing entry flow control, you need to > control the producer so you don't overwelm the consumer. So, you need > the flow control throttling done from the routing table. > > If you don't the producer is the state change routing table and the > consumer is the transmission layer. If the producer is changing and the > the consumer is slowed because of external events, you create a buffer > situation in your transmission layer. > > If you go this route, you may as well use TCP because it is implemented > to already deal with this. Don't duplicate this functionality in PIM. > > This was the same debate that BGP and IDRP had. BGP decided to use TCP > and IDRP did it's own transmission layer. Hence, we have heard that TCP > may not be good in this PIM situation so we want to create a very > lightweight incremental ack mechanism. I hope you do not imply in your last sentence above that TCP is not a lightweight transport protocol. Yakov. From yakov@juniper.net Tue Jan 18 09:05:08 2005 Received: from colo-dns-ext2.juniper.net (colo-dns-ext2.juniper.net [207.17.137.64]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0IE589L065029 for ; Tue, 18 Jan 2005 09:05:08 -0500 (EST) (envelope-from yakov@juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j0IE3pBm049760; Tue, 18 Jan 2005 06:03:51 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j0IE3pe12522; Tue, 18 Jan 2005 06:03:51 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200501181403.j0IE3pe12522@merlot.juniper.net> To: Dino Farinacci Subject: Re: [Pim-state] Proposal In-Reply-To: Your message of "Sat, 08 Jan 2005 11:15:54 PST." <200501081915.j08JFsHN032411@dino-lnx.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71427.1106057030.1@juniper.net> Date: Tue, 18 Jan 2005 06:03:51 -0800 From: Yakov Rekhter Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 18 Jan 2005 14:05:08 -0000 Dino, > >> I agree there is additional code required to manage this extra level of > >> indirection, but it is in the interest of reducing the amount of > >> processing in the routers and thus scaling better. > > It increases memory and buffer requirements in the router. We have learne d > over decades that to deal with routing entry flow control, you need to > control the producer so you don't overwelm the consumer. So, you need > the flow control throttling done from the routing table. > > If you don't the producer is the state change routing table and the > consumer is the transmission layer. If the producer is changing and the > the consumer is slowed because of external events, you create a buffer > situation in your transmission layer. How do the proposals posted so far on this list deal with the above ? Yakov. From sboddapa@yahoo.com Tue Jan 18 13:05:32 2005 Received: from web81310.mail.yahoo.com (web81310.mail.yahoo.com [206.190.37.85]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j0II5Wf7065414 for ; Tue, 18 Jan 2005 13:05:32 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050118180527.96551.qmail@web81310.mail.yahoo.com> Received: from [64.163.212.154] by web81310.mail.yahoo.com via HTTP; Tue, 18 Jan 2005 10:05:26 PST Date: Tue, 18 Jan 2005 10:05:26 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] Proposal To: Yakov Rekhter , Dino Farinacci In-Reply-To: <200501181403.j0IE3pe12522@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 18 Jan 2005 18:05:32 -0000 > > It increases memory and buffer requirements in > the router. We have learne > d > > over decades that to deal with routing entry > flow control, you need to > > control the producer so you don't overwelm the > consumer. So, you need > > the flow control throttling done from the > routing table. > > > > If you don't the producer is the state change > routing table and the > > consumer is the transmission layer. If the > producer is changing and the > > the consumer is slowed because of external > events, you create a buffer > > situation in your transmission layer. > > How do the proposals posted so far on this list deal > with the above ? > There were a lot of email exchanges on this till last week. I thought we might have beaten it to a premature death because the emails stopped coming. It's good to see more people stepping in. Coming to the point, the buffering problem as Dino presents, is something that I do not completely claim to understand. The last email exchange ended with me asking for an example to help understand it. Let me try to describe it as I understand it (forgive me if it is verbose). We know the flow control with TCP. Loosely put, TCP gets data to transport, it chops it up into segments and sends out as many segments as the transmission window permits, thus making sure that it does not bombard the receiver with too much traffic and sends traffic at a rate that is in proportion to the rate at which the receiver can consume it (assuming the window size is set right). If the window is full, additional data is buffered at the sender which is sent only when the window slides or opens up. Taking this into PIM's context. Let's say that there is an (S,G) Join that is sent from a downstream router D to an upstream one U. D is expecting an ACK from U for the Join it sent. The scheme I proposed has a Message ID TLV that has a sequence number associated with it. Let's say the seq number is 1 for this Message M. If an ACK is not received from U within a certain time, D will retransmit M. Let's say before the ACK is received (at any point of this retransmission sequence), the (S,G) state changes to Prune. M is updated and D sends out M with seq num 2. Now D is expecting an ACK only for M with seq num 2. It does not care about an ACK for M with seq=1, nor will it retransmit M with seq=1. So there is no additional buffering here, but Dino does not seem to think so. The transmission layer is in sync with the routing table changes. D does not wait for ACK for M with seq=1 before sending out M with seq=2. If it receives it, it ignores it. All it wants ACKed is the latest state. So the retransmissions will occur only for the latest state. If the sequence of events for an (S,G) is Join, Prune, Join, the only outstanding message to be acked would be for the final Join. The problem Dino seems to have with this is that we are sending all the events when we should be sending only one (the final Join). According to him, there is no damping here. I think damping is orthogonal. We always want the latest state to be conveyed to the upstream nbr as soon as possible. Damping is at a higher layer where you wait for a certain amount of time before sending out the latest state. Even with damping, you can have a scenario where the damped state changes are Join, Prune, Join and we have not received an ACK for any. In Dino's proposal, the ACK means just replaying the JP message sent by D to U back to D with just the message type replaced. The problem with this is if a Join, Prune, Join sequence occurs, the downstream router cannot tell from an ACK whether the ACK is for the first Join or the second one. So Dino proposes that we not send the second Join until we see an ACK for the first Join or the Prune. My question is, is this not additional buffering? Dino says that this is damping. There are several things that can go wrong with this IMO. For example, the ACKs for both the first Join and Prune can get lost. Would we retransmit Prunes at this stage? Or the new Join? If we get an ACK for the Join now, can we be sure that it is for the new Join and not the old one (the receiver can be very very slow). If we retransmitted the Prune, what effect does it have on the convergence time, when we know that the new state is actually Join, not Prune? My point is, an ACK scheme is no good if we cannot say for sure what is being acked. While we are on the subject, I posted my proposal over a month back and it seems like not many have read it or if they have, have not wished to discuss it. Dino has been promising to read it :-) I dont mean to complain, but it would be a lot easier if everyone went over the existing proposals. Otherwise, we would all have to endure endless repetitions of the same stuff over and over again and achieving consensus may take longer than necessary. Suresh > Yakov. > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state > From venu.hemige@alcatel.com Tue Jan 18 14:04:55 2005 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0IJ4svW065504 for ; Tue, 18 Jan 2005 14:04:55 -0500 (EST) (envelope-from venu.hemige@alcatel.com) Received: from venuxp ([172.22.187.78] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Jan 2005 11:04:40 -0800 From: "Venu Hemige" To: "'Yakov Rekhter'" , "'Dino Farinacci'" Subject: RE: [Pim-state] Proposal Date: Tue, 18 Jan 2005 11:04:31 -0800 Message-ID: <054d01c4fd90$8bd5a950$4ebb16ac@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200501181245.j0ICjQe03846@merlot.juniper.net> X-OriginalArrivalTime: 18 Jan 2005 19:04:40.0693 (UTC) FILETIME=[900A5250:01C4FD90] Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: venu.hemige@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 18 Jan 2005 19:04:55 -0000 Yakov, > > I hope you do not imply in your last sentence above that TCP is > not a lightweight transport protocol. > I hope you are not suggesting we use TCP to eliminate refreshes. We cannot use TCP because that would mean PIM Snooping would stop working. -Venu From yakov@juniper.net Tue Jan 18 18:41:58 2005 Received: from colo-dns-ext1.juniper.net (colo-dns-ext1.juniper.net [207.17.137.57]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0INfwnc065923 for ; Tue, 18 Jan 2005 18:41:58 -0500 (EST) (envelope-from yakov@juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j0INfm916464; Tue, 18 Jan 2005 15:41:52 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j0INfge22328; Tue, 18 Jan 2005 15:41:43 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200501182341.j0INfge22328@merlot.juniper.net> To: venu.hemige@alcatel.com Subject: Re: [Pim-state] Proposal In-Reply-To: Your message of "Tue, 18 Jan 2005 11:04:31 PST." <054d01c4fd90$8bd5a950$4ebb16ac@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28761.1106091702.1@juniper.net> Date: Tue, 18 Jan 2005 15:41:42 -0800 From: Yakov Rekhter Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 18 Jan 2005 23:41:58 -0000 Venu, > > I hope you do not imply in your last sentence above that TCP is > > not a lightweight transport protocol. > > I hope you are not suggesting we use TCP to eliminate refreshes. We > cannot use TCP because that would mean PIM Snooping would stop working. No, I am not suggesting we use TCP. But the *only* reason against TCP that I can see so far is the one you brought up above - PIM snooping. Yakov. From suresh.boddapati@alcatel.com Tue Jan 18 18:53:05 2005 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0INr4uj065948 for ; Tue, 18 Jan 2005 18:53:05 -0500 (EST) (envelope-from suresh.boddapati@alcatel.com) Received: from alcatelxp ([172.22.187.74] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Jan 2005 15:52:55 -0800 From: "Suresh Boddapati" To: "'Yakov Rekhter'" , Subject: RE: [Pim-state] Proposal Date: Tue, 18 Jan 2005 15:53:26 -0800 Organization: Alcatel USA Message-ID: <01d501c4fdb8$e9c4b8d0$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <200501182341.j0INfge22328@merlot.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-OriginalArrivalTime: 18 Jan 2005 23:52:55.0907 (UTC) FILETIME=[D4CA8B30:01C4FDB8] Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: suresh.boddapati@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 18 Jan 2005 23:53:05 -0000 Using TCP also takes away Join suppression and can multiply the instantaneous amount of traffic received at the upstream router. If there are N downstream routers and they all want to join the same stream, the number of Joins potentially sent at the same time to the upstream would be n fold with TCP. Suresh > -----Original Message----- > From: pim-state-bounces@mountain2sea.com [mailto:pim-state- > bounces@mountain2sea.com] On Behalf Of Yakov Rekhter > Sent: Tuesday, January 18, 2005 3:42 PM > To: venu.hemige@alcatel.com > Cc: pim-state@mountain2sea.com > Subject: Re: [Pim-state] Proposal > > Venu, > > > > I hope you do not imply in your last sentence above that TCP is > > > not a lightweight transport protocol. > > > > I hope you are not suggesting we use TCP to eliminate refreshes. We > > cannot use TCP because that would mean PIM Snooping would stop working. > > No, I am not suggesting we use TCP. But the *only* reason against > TCP that I can see so far is the one you brought up above - PIM snooping. > > Yakov. > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state From dino@dino-lnx.cisco.com Wed Jan 19 13:10:41 2005 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0JIAfYM068242 for ; Wed, 19 Jan 2005 13:10:41 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2005 10:11:29 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0JIAX1M021279; Wed, 19 Jan 2005 10:10:34 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j0JIAXH2001168; Wed, 19 Jan 2005 10:10:33 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j0JIAXP0001164; Wed, 19 Jan 2005 10:10:33 -0800 Date: Wed, 19 Jan 2005 10:10:33 -0800 Message-Id: <200501191810.j0JIAXP0001164@dino-lnx.cisco.com> From: Dino Farinacci To: yakov@juniper.net In-reply-to: <200501181245.j0ICjQe03846@merlot.juniper.net> (message from Yakov Rekhter on Tue, 18 Jan 2005 04:45:25 -0800) Subject: Re: [Pim-state] Proposal References: <200501181245.j0ICjQe03846@merlot.juniper.net> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 19 Jan 2005 18:10:42 -0000 >> I hope you do not imply in your last sentence above that TCP is >> not a lightweight transport protocol. I meant we might want to create an even lighter weight protocol. Dino From dino@dino-lnx.cisco.com Tue Jan 25 04:09:23 2005 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0P99IaO087644 for ; Tue, 25 Jan 2005 04:09:22 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 25 Jan 2005 02:17:55 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j0P99ARO003763; Tue, 25 Jan 2005 01:09:11 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j0P99AuG028872; Tue, 25 Jan 2005 01:09:10 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j0P99AgE028868; Tue, 25 Jan 2005 01:09:10 -0800 Date: Tue, 25 Jan 2005 01:09:10 -0800 Message-Id: <200501250909.j0P99AgE028868@dino-lnx.cisco.com> From: Dino Farinacci To: sboddapa@yahoo.com In-reply-to: <20050118180527.96551.qmail@web81310.mail.yahoo.com> (message from Suresh Boddapati on Tue, 18 Jan 2005 10:05:26 -0800 (PST)) Subject: Re: [Pim-state] Proposal References: <20050118180527.96551.qmail@web81310.mail.yahoo.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 25 Jan 2005 09:09:26 -0000 >> the first Join or the second one. So Dino proposes >> that we not send the second Join until we see an ACK >> for the first Join or the Prune. My question is, is >> this not additional buffering? Dino says that this is It is not buffering a message, it is setting a timer for the entry for later transmission. When the tiem expires and if the Ack was received, the new state can be sent. Otherwise, you reset the timer. >> damping. There are several things that can go wrong >> with this IMO. For example, the ACKs for both the >> first Join and Prune can get lost. Would we retransmit >> Prunes at this stage? Or the new Join? If we get an You retransmit the current state you have and you wait for either a Join Ack or a Prune Ack to come back. You can tell in the message if the Ack was for a Join or a Prune. And you know the Ack cannot be for an older Join or an older Prune. >> Prunes at this stage? Or the new Join? If we get an >> ACK for the Join now, can we be sure that it is for >> the new Join and not the old one (the receiver can be You don't care about an old versus new Join, there is no more content in it other than it was a Join versus a Prune. It's binary state like I mentioned in previous emails. So if a downstream router sent J1,P1,J2 and an Join-Ack is received but was sent by the upstream router in response to receiving J1, you don't want the downstream router to think J2 was accepted where it could have been lost. That is why the downstream router does not send J2 until it gets the Prune-Ack for P1. >> My point is, an ACK scheme is no good if we cannot say >> for sure what is being acked. It does say what is acked. >> or if they have, have not wished to discuss it. Dino >> has been promising to read it :-) I dont mean to >> complain, but it would be a lot easier if everyone >> went over the existing proposals. Otherwise, we would >> all have to endure endless repetitions of the same >> stuff over and over again and achieving consensus may >> take longer than necessary. Sorry, I have been side-tracked with higher priority work. I will get to it and you can be sure I'll send comments to this list. Dino From sboddapa@yahoo.com Tue Jan 25 13:21:36 2005 Received: from web81308.mail.yahoo.com (web81308.mail.yahoo.com [206.190.37.83]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j0PILZkj088795 for ; Tue, 25 Jan 2005 13:21:35 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050125182130.60408.qmail@web81308.mail.yahoo.com> Received: from [64.160.52.175] by web81308.mail.yahoo.com via HTTP; Tue, 25 Jan 2005 10:21:30 PST Date: Tue, 25 Jan 2005 10:21:30 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] Proposal To: Dino Farinacci In-Reply-To: <200501250909.j0P99AgE028868@dino-lnx.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 25 Jan 2005 18:21:36 -0000 > You retransmit the current state you have and > you wait for either a Join > Ack or a Prune Ack to come back. You can tell in > the message if the Ack > was for a Join or a Prune. And you know the Ack > cannot be for an older > Join or an older Prune. > How do you know the ACK cannot be for an older Join or an older Prune unless you always have only one Join or Prune state outstanding to be Acked? If you send J1 and the state changes to P1, I presume you are going to send P1 and will not wait for J1 to be acked. Let's go with this assumption for a second. At the upstream router, say J1 and P1 are queued in the rx pkt queues somewhere. The upstream router is awfully busy and will not be able to get to those for a while. Now on the downstream router say the state changes to Join again. Since you have not heard back the acks for the Prune, would you now transmit the new Join or retransmit the old Prune? Let's consider the two cases: Case 1: You retransmit the Prune until the Prune is acked. I presume this is the solution you are propsoing. You are delaying convergence because you are not telling the upstream router of the latest state i.e. Join. Maybe the upstream router did ack the Prune but the Prune ack got lost. This could go on for a while where you could be retransmitting Prunes and the ACKs could be getting lost. The state will not be setup even though it can be (if you sent Joins and the ACKs got lost, it would still be ok since the state would get setup). Case 2: You transmit the latest state i.e. J2. Now suppose this Join gets lost AND the upstream router starts processing the queued J1 and P1, when the downstream router gets an ACK back, how can it tell whether the ACK was for J1 or J2? If it assumes that the ack is for J2, it is toast because the upstream router would prune the state when it processes P1 and sends the ACK back to the downstream router. Now if the ack for the Prune gets lost, the state is never setup at all!! This is the reason why you are saying that we should delay sending the second Join until we have heard the ACK back for the first Join, isnt it? > You don't care about an old versus new Join, > there is no more content > in it other than it was a Join versus a Prune. > It's binary state like > I mentioned in previous emails. > > So if a downstream router sent J1,P1,J2 and an > Join-Ack is received but > was sent by the upstream router in response to > receiving J1, you don't > want the downstream router to think J2 was > accepted where it could have > been lost. That is why the downstream router > does not send J2 until > it gets the Prune-Ack for P1. Exactly. So you are going to retransmit Prunes until you get an ACK back for the Prune even though what you have to send is a Join (case 1 above)? This is no longer binary state, because you are remembering the current state J, AND you are retransmitting Prunes because you have not heard the ACK back for them. Irrespective of whether we see it as binary state or not, this will delay convergence, which is not good IMO. > > >> My point is, an ACK scheme is no good if we > cannot say > >> for sure what is being acked. > > It does say what is acked. > No it doesn't, not from the received ACK packet. Otherwise, you would not delay sending the second Join, because if you did, you cannot distinguish between an ACK for J1 and that for J2. It will only work when you impose the additional restriction that you will not send any new Join if an ACK for an older Join and Prune are outstanding. Which means you have to distinguish between the case when you can send J2 (if J1 was acked but P1 was not) and the case when you cannot send J2 (if J1 and P1 both were not acked). This cannot be achieved with a retransmission timer alone. You would need to keep more state (in some form or the other) about the history of at most two unacked states for a given entry. Suresh From Yetik_Serbest@labs.sbc.com Tue Jan 25 13:26:56 2005 Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0PIQuab088812 for ; Tue, 25 Jan 2005 13:26:56 -0500 (EST) (envelope-from Yetik_Serbest@labs.sbc.com) Received: from sbctri.tri.sbc.com (mayhem-webdmz.tri.sbc.com [144.60.9.139]) by howler.tri.sbc.com (8.12.10/8.12.10) with ESMTP id j0PIQsRt002448; Tue, 25 Jan 2005 12:26:54 -0600 (CST) Received: from TSMAIL2.ad.tri.sbc.com (tsmail2.ad.tri.sbc.com [144.60.55.226]) by sbctri.tri.sbc.com (8.12.10/8.12.10) with ESMTP id j0PIQsEq023401; Tue, 25 Jan 2005 12:26:54 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Pim-state] Proposal Date: Tue, 25 Jan 2005 12:26:54 -0600 Message-ID: <0CED449E95A92A42991EB71B778C17BF18BED6@TSMAIL2.ad.tri.sbc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pim-state] Proposal Thread-Index: AcUCvdptFMh9wi05QB6yj7nbfBlMggATSRMw From: "Serbest, Yetik" To: "Dino Farinacci" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by rock.mountain2sea.com id j0PIQuab088812 Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 25 Jan 2005 18:26:56 -0000 > So if a downstream router sent J1,P1,J2 and an Join-Ack is received but > was sent by the upstream router in response to receiving J1, you don't > want the downstream router to think J2 was accepted where it could have > been lost. That is why the downstream router does not send J2 until > it gets the Prune-Ack for P1. Don't you think this will increase group join delay? Thanks, yetik From dino@dino-lnx.cisco.com Tue Jan 25 21:42:42 2005 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0Q2ggaM089561 for ; Tue, 25 Jan 2005 21:42:42 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 25 Jan 2005 18:48:27 -0800 Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0Q2gVl2025858; Tue, 25 Jan 2005 18:42:32 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j0Q2gYDo018531; Tue, 25 Jan 2005 18:42:34 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j0Q2gY8Z018522; Tue, 25 Jan 2005 18:42:34 -0800 Date: Tue, 25 Jan 2005 18:42:34 -0800 Message-Id: <200501260242.j0Q2gY8Z018522@dino-lnx.cisco.com> From: Dino Farinacci To: Yetik_Serbest@labs.sbc.com In-reply-to: <0CED449E95A92A42991EB71B778C17BF18BED6@TSMAIL2.ad.tri.sbc.com> (Yetik_Serbest@labs.sbc.com) Subject: Re: [Pim-state] Proposal References: <0CED449E95A92A42991EB71B778C17BF18BED6@TSMAIL2.ad.tri.sbc.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 26 Jan 2005 02:42:43 -0000 >> Don't you think this will increase group join delay? No, because a 3-step flap won't happen often IMO. Dino From dino@dino-lnx.cisco.com Tue Jan 25 21:49:08 2005 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0Q2n8rs089578 for ; Tue, 25 Jan 2005 21:49:08 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 25 Jan 2005 18:54:53 -0800 Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0Q2n0Nt014757; Tue, 25 Jan 2005 18:49:01 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j0Q2mtrP025387; Tue, 25 Jan 2005 18:48:55 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j0Q2mtbl025380; Tue, 25 Jan 2005 18:48:55 -0800 Date: Tue, 25 Jan 2005 18:48:55 -0800 Message-Id: <200501260248.j0Q2mtbl025380@dino-lnx.cisco.com> From: Dino Farinacci To: sboddapa@yahoo.com In-reply-to: <20050125182130.60408.qmail@web81308.mail.yahoo.com> (message from Suresh Boddapati on Tue, 25 Jan 2005 10:21:30 -0800 (PST)) Subject: Re: [Pim-state] Proposal References: <20050125182130.60408.qmail@web81308.mail.yahoo.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 26 Jan 2005 02:49:08 -0000 >> again. Since you have not heard back the acks for the >> Prune, would you now transmit the new Join or >> retransmit the old Prune? Let's consider the two You cannot send the new Join until the previous Prune is ACKed. >> Case 1: You retransmit the Prune until the Prune is >> acked. I presume this is the solution you are >> propsoing. You are delaying convergence because you >> are not telling the upstream router of the latest Only when the prune->join event transition time is less than the ack return time which is could be seldom. Yes, if a the Prune or Prune-ack gets lost the subsequent Join could happen if initial retransmission timers are long. >> Case 2: You transmit the latest state i.e. J2. Now >> suppose this Join gets lost AND the upstream router >> starts processing the queued J1 and P1, when the >> downstream router gets an ACK back, how can it tell >> whether the ACK was for J1 or J2? If it assumes that Right, I am not proposing this. >> No it doesn't, not from the received ACK packet. The JP-Ack contains the original contents of a JP. So you know if the ACK is applying to the Join versus a Prune and since only 1 of each can be outstanding, there is no confusion. >> This cannot be achieved with a retransmission timer >> alone. You would need to keep more state (in some form >> or the other) about the history of at most two unacked >> states for a given entry. I can do it with 1 extra bit per multicast route. Dino From Yetik_Serbest@labs.sbc.com Wed Jan 26 09:32:50 2005 Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0QEWoZp090954 for ; Wed, 26 Jan 2005 09:32:50 -0500 (EST) (envelope-from Yetik_Serbest@labs.sbc.com) Received: from sbctri.tri.sbc.com (mayhem-webdmz.tri.sbc.com [144.60.9.139]) by howler.tri.sbc.com (8.12.10/8.12.10) with ESMTP id j0QEWnRt022285; Wed, 26 Jan 2005 08:32:49 -0600 (CST) Received: from TSMAIL2.ad.tri.sbc.com (tsmail2.ad.tri.sbc.com [144.60.55.226]) by sbctri.tri.sbc.com (8.12.10/8.12.10) with ESMTP id j0QEWmEq009209; Wed, 26 Jan 2005 08:32:48 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Pim-state] Proposal Date: Wed, 26 Jan 2005 08:32:46 -0600 Message-ID: <0CED449E95A92A42991EB71B778C17BF18BED9@TSMAIL2.ad.tri.sbc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pim-state] Proposal Thread-Index: AcUDULPADSle7mA8SdOiiIEuV8+b4wAYxOGA From: "Serbest, Yetik" To: "Dino Farinacci" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by rock.mountain2sea.com id j0QEWoZp090954 Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 26 Jan 2005 14:32:50 -0000 I know an application that can happen often: People flipping around while watching TV. -----Original Message----- From: Dino Farinacci [mailto:dino@cisco.com] Sent: Tuesday, January 25, 2005 8:43 PM To: Serbest, Yetik Cc: sboddapa@yahoo.com; pim-state@mountain2sea.com Subject: Re: [Pim-state] Proposal >> Don't you think this will increase group join delay? No, because a 3-step flap won't happen often IMO. Dino From dino@dino-lnx.cisco.com Thu Jan 27 01:41:53 2005 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0R6frXo015054 for ; Thu, 27 Jan 2005 01:41:53 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 26 Jan 2005 22:43:32 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j0R6fjRO028929; Wed, 26 Jan 2005 22:41:45 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j0R6fj6W004869; Wed, 26 Jan 2005 22:41:45 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j0R6fjLx004865; Wed, 26 Jan 2005 22:41:45 -0800 Date: Wed, 26 Jan 2005 22:41:45 -0800 Message-Id: <200501270641.j0R6fjLx004865@dino-lnx.cisco.com> From: Dino Farinacci To: Yetik_Serbest@labs.sbc.com In-reply-to: <0CED449E95A92A42991EB71B778C17BF18BED9@TSMAIL2.ad.tri.sbc.com> (Yetik_Serbest@labs.sbc.com) Subject: Re: [Pim-state] Proposal References: <0CED449E95A92A42991EB71B778C17BF18BED9@TSMAIL2.ad.tri.sbc.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 27 Jan 2005 06:41:53 -0000 >> I know an application that can happen often: People flipping around >> while watching TV. There is a minimum of 3 seconds for IGMP leave processing. Remember the Leave is sent by the host and the IGMP queiring router sends a group- specific query then waits 3 seconds to remove the interface from the oif-list. Dino From pusateri@juniper.net Thu Jan 27 10:18:39 2005 Received: from colo-dns-ext2.juniper.net (colo-dns-ext2.juniper.net [207.17.137.64]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0RFIc1D016122 for ; Thu, 27 Jan 2005 10:18:39 -0500 (EST) (envelope-from pusateri@juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j0RFIMBm037449; Thu, 27 Jan 2005 07:18:22 -0800 (PST) (envelope-from pusateri@juniper.net) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j0RFIHe54046; Thu, 27 Jan 2005 07:18:17 -0800 (PST) (envelope-from pusateri@juniper.net) Message-Id: <200501271518.j0RFIHe54046@merlot.juniper.net> To: Dino Farinacci Subject: Re: [Pim-state] Proposal In-Reply-To: Message from Dino Farinacci of "Wed, 26 Jan 2005 22:41:45 PST." <200501270641.j0R6fjLx004865@dino-lnx.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21582.1106839097.1@juniper.net> Date: Thu, 27 Jan 2005 07:18:17 -0800 From: Tom Pusateri Cc: Yetik_Serbest@labs.sbc.com, pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 27 Jan 2005 15:18:39 -0000 In message <200501270641.j0R6fjLx004865@dino-lnx.cisco.com> you write: >>> I know an application that can happen often: People flipping around >>> while watching TV. > > There is a minimum of 3 seconds for IGMP leave processing. Remember the > Leave is sent by the host and the IGMP queiring router sends a group- > specific query then waits 3 seconds to remove the interface from the > oif-list. > >Dino Alternatively, you can do explicit tracking and fast leaves so you don't have to send group specific queries at all. Tom From Yetik_Serbest@labs.sbc.com Thu Jan 27 11:31:39 2005 Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0RGVcnw016266 for ; Thu, 27 Jan 2005 11:31:38 -0500 (EST) (envelope-from Yetik_Serbest@labs.sbc.com) Received: from sbctri.tri.sbc.com (mayhem-webdmz.tri.sbc.com [144.60.9.139]) by howler.tri.sbc.com (8.12.10/8.12.10) with ESMTP id j0RGVRRt019084; Thu, 27 Jan 2005 10:31:27 -0600 (CST) Received: from TSMAIL2.ad.tri.sbc.com (tsmail2.ad.tri.sbc.com [144.60.55.226]) by sbctri.tri.sbc.com (8.12.10/8.12.10) with ESMTP id j0RGVQEq013685; Thu, 27 Jan 2005 10:31:27 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Pim-state] Proposal Date: Thu, 27 Jan 2005 10:31:26 -0600 Message-ID: <0CED449E95A92A42991EB71B778C17BF18BEE1@TSMAIL2.ad.tri.sbc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pim-state] Proposal Thread-Index: AcUEO0f4JVgO3v5XQ/uqLjvjpUakngAUd8VA From: "Serbest, Yetik" To: "Dino Farinacci" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by rock.mountain2sea.com id j0RGVcnw016266 Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 27 Jan 2005 16:31:39 -0000 Dino, The point is different. You are proposing to not send the second join until the prune is acknowledged. You said J->P->J does not happen often, but it can. And also, there are some ways to overcome what you are saying as people can not wait 3 seconds for channel change. Thanks, yetik -----Original Message----- From: Dino Farinacci [mailto:dino@cisco.com] Sent: Thursday, January 27, 2005 12:42 AM To: Serbest, Yetik Cc: sboddapa@yahoo.com; pim-state@mountain2sea.com Subject: Re: [Pim-state] Proposal >> I know an application that can happen often: People flipping around >> while watching TV. There is a minimum of 3 seconds for IGMP leave processing. Remember the Leave is sent by the host and the IGMP queiring router sends a group- specific query then waits 3 seconds to remove the interface from the oif-list. Dino From dino@dino-lnx.cisco.com Thu Jan 27 11:48:58 2005 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0RGmwSi016299 for ; Thu, 27 Jan 2005 11:48:58 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 27 Jan 2005 08:48:59 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0RGmo1M004065; Thu, 27 Jan 2005 08:48:51 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j0RGmooB019671; Thu, 27 Jan 2005 08:48:50 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j0RGmoIt019667; Thu, 27 Jan 2005 08:48:50 -0800 Date: Thu, 27 Jan 2005 08:48:50 -0800 Message-Id: <200501271648.j0RGmoIt019667@dino-lnx.cisco.com> From: Dino Farinacci To: Yetik_Serbest@labs.sbc.com In-reply-to: <0CED449E95A92A42991EB71B778C17BF18BEE1@TSMAIL2.ad.tri.sbc.com> (Yetik_Serbest@labs.sbc.com) Subject: Re: [Pim-state] Proposal References: <0CED449E95A92A42991EB71B778C17BF18BEE1@TSMAIL2.ad.tri.sbc.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 27 Jan 2005 16:48:58 -0000 >> The point is different. You are proposing to not send the second join >> until the prune is acknowledged. You said J->P->J does not happen often, >> but it can. Understand, yes ET may be used (but not deployed everywhere yet). Are you saying this is a show-stopper? If necessary, there is space in the reserved field of the Soruce-Encoded- Address to put a sequence number if people feel sequencing, to a small degree, is needed. maybe a 3-bit sequence number so you can have 8 J->P transisions and then delay after that. Dino From Yetik_Serbest@labs.sbc.com Thu Jan 27 17:19:02 2005 Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0RMJ2MB016840 for ; Thu, 27 Jan 2005 17:19:02 -0500 (EST) (envelope-from Yetik_Serbest@labs.sbc.com) Received: from sbctri.tri.sbc.com (mayhem-webdmz.tri.sbc.com [144.60.9.139]) by howler.tri.sbc.com (8.12.10/8.12.10) with ESMTP id j0RMIlRt025458; Thu, 27 Jan 2005 16:18:47 -0600 (CST) Received: from TSMAIL2.ad.tri.sbc.com (tsmail2.ad.tri.sbc.com [144.60.55.226]) by sbctri.tri.sbc.com (8.12.10/8.12.10) with ESMTP id j0RMIkEq001566; Thu, 27 Jan 2005 16:18:47 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Pim-state] Proposal Date: Thu, 27 Jan 2005 16:18:46 -0600 Message-ID: <0CED449E95A92A42991EB71B778C17BF18BEE9@TSMAIL2.ad.tri.sbc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pim-state] Proposal Thread-Index: AcUEkBcYrBZ7rsiyQh+ocetvgSyG/wALaK7w From: "Serbest, Yetik" To: "Dino Farinacci" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by rock.mountain2sea.com id j0RMJ2MB016840 Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 27 Jan 2005 22:19:03 -0000 I would say that fast channel changing capability is important. Actually, Microsoft devised a method for that in IPTV, because that was annoying according to the customers. Hence, if you do not send new join because prune is not acked yet, you are also preventing Microsoft's scheme to kick in. Thanks, yetik -----Original Message----- From: Dino Farinacci [mailto:dino@cisco.com] Sent: Thursday, January 27, 2005 10:49 AM To: Serbest, Yetik Cc: sboddapa@yahoo.com; pim-state@mountain2sea.com Subject: Re: [Pim-state] Proposal >> The point is different. You are proposing to not send the second join >> until the prune is acknowledged. You said J->P->J does not happen often, >> but it can. Understand, yes ET may be used (but not deployed everywhere yet). Are you saying this is a show-stopper? If necessary, there is space in the reserved field of the Soruce-Encoded- Address to put a sequence number if people feel sequencing, to a small degree, is needed. maybe a 3-bit sequence number so you can have 8 J->P transisions and then delay after that. Dino From sboddapa@yahoo.com Thu Jan 27 22:41:51 2005 Received: from web81307.mail.yahoo.com (web81307.mail.yahoo.com [206.190.37.82]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j0S3fpuo017313 for ; Thu, 27 Jan 2005 22:41:51 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050128034146.38567.qmail@web81307.mail.yahoo.com> Received: from [64.169.160.207] by web81307.mail.yahoo.com via HTTP; Thu, 27 Jan 2005 19:41:46 PST Date: Thu, 27 Jan 2005 19:41:46 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] Proposal To: Dino Farinacci , Yetik_Serbest@labs.sbc.com In-Reply-To: <200501271648.j0RGmoIt019667@dino-lnx.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 28 Jan 2005 03:41:51 -0000 > If necessary, there is space in the reserved > field of the Soruce-Encoded- > Address to put a sequence number if people feel > sequencing, to a small > degree, is needed. maybe a 3-bit sequence number > so you can have 8 J->P > transisions and then delay after that. > Are you saying that there cannot be more than 8 back and forth channel changes and if there are, the user has to pay the consequences? My remote does not place that kind of a restriction. I would rather use a TLV like in my scheme, instead of hacking up the Source Encoded Address field. Suresh From dino@dino-lnx.cisco.com Fri Jan 28 00:32:11 2005 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0S5WBAV017489 for ; Fri, 28 Jan 2005 00:32:11 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 27 Jan 2005 22:41:22 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j0S5W2RO028113; Thu, 27 Jan 2005 21:32:03 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j0S5W24x015555; Thu, 27 Jan 2005 21:32:02 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j0S5W2qb015551; Thu, 27 Jan 2005 21:32:02 -0800 Date: Thu, 27 Jan 2005 21:32:02 -0800 Message-Id: <200501280532.j0S5W2qb015551@dino-lnx.cisco.com> From: Dino Farinacci To: sboddapa@yahoo.com In-reply-to: <20050128034146.38567.qmail@web81307.mail.yahoo.com> (message from Suresh Boddapati on Thu, 27 Jan 2005 19:41:46 -0800 (PST)) Subject: Re: [Pim-state] Proposal References: <20050128034146.38567.qmail@web81307.mail.yahoo.com> Cc: Yetik_Serbest@labs.sbc.com, pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 28 Jan 2005 05:32:11 -0000 >> Are you saying that there cannot be more than 8 back >> and forth channel changes and if there are, the user >> has to pay the consequences? My remote does not place Nope, there cannot be 8 back-and-forth changes while *no* JP-Ack has come back. >> that kind of a restriction. I would rather use a TLV >> like in my scheme, instead of hacking up the Source >> Encoded Address field. I am starting to believe you are splitting hairs here. We can use all of the reserved field if you want the sequence number range to be larger. Also, on most router CPUs, the RTT between JP and JP-Ack will be around a hundred milliseconds. And folks, look what we have today and how well it works. Let's not over-design. Dino From sboddapa@yahoo.com Fri Jan 28 01:27:11 2005 Received: from web81307.mail.yahoo.com (web81307.mail.yahoo.com [206.190.37.82]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j0S6RBb8017582 for ; Fri, 28 Jan 2005 01:27:11 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050128062706.68857.qmail@web81307.mail.yahoo.com> Received: from [64.169.160.207] by web81307.mail.yahoo.com via HTTP; Thu, 27 Jan 2005 22:27:06 PST Date: Thu, 27 Jan 2005 22:27:06 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] Proposal To: Dino Farinacci In-Reply-To: <200501280532.j0S5W2qb015551@dino-lnx.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Yetik_Serbest@labs.sbc.com, pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 28 Jan 2005 06:27:11 -0000 --- Dino Farinacci wrote: > >> Are you saying that there cannot be more than 8 > back > >> and forth channel changes and if there are, the > user > >> has to pay the consequences? My remote does not > place > > Nope, there cannot be 8 back-and-forth changes > while *no* JP-Ack has come > back. > Can you care to elaborate? All I care is after I go through 8 or 100 back and forth changes, if I send a Join, I should get my content. It should not matter if the first 8 exchanges did not get acked. If the 9th one is a Join, maybe it will get through and I will get the ack back. The point is, use the latest state, not the old one irrespective of whether the old one got acked or not. As long as you have your adjacency up, send the latest state. > >> that kind of a restriction. I would rather use a > TLV > >> like in my scheme, instead of hacking up the > Source > >> Encoded Address field. > > I am starting to believe you are splitting hairs > here. Am I? Or am I pointing out a possible limitation? > of the reserved field if you want the sequence > number range to be larger. Why should we use the reserved field? Because you want to replay the packet back as is? Why should it take an entire packet to ack the packet when a small packet with a TLV will do? How does this reduce refresh traffic when it is actually doubling it? > > Also, on most router CPUs, the RTT between JP > and JP-Ack will be > around a hundred milliseconds. > Of course, when you are talking about a few entries. When there are millions of entries, the routers are busy, the packets get lost/dropped, the RTT will not be in milliseconds. > And folks, look what we have today and how well > it works. Let's not > over-design. > Which part is being over designed here? Suresh From dino@dino-lnx.cisco.com Fri Jan 28 01:34:46 2005 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0S6YaXv017602 for ; Fri, 28 Jan 2005 01:34:46 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 27 Jan 2005 22:35:09 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0S6YS1M000872; Thu, 27 Jan 2005 22:34:28 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j0S6YR2M017287; Thu, 27 Jan 2005 22:34:27 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j0S6YQpu017283; Thu, 27 Jan 2005 22:34:26 -0800 Date: Thu, 27 Jan 2005 22:34:26 -0800 Message-Id: <200501280634.j0S6YQpu017283@dino-lnx.cisco.com> From: Dino Farinacci To: sboddapa@yahoo.com In-reply-to: <20050128062706.68857.qmail@web81307.mail.yahoo.com> (message from Suresh Boddapati on Thu, 27 Jan 2005 22:27:06 -0800 (PST)) Subject: Re: [Pim-state] Proposal References: <20050128062706.68857.qmail@web81307.mail.yahoo.com> Cc: Yetik_Serbest@labs.sbc.com, pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 28 Jan 2005 06:34:46 -0000 >> Can you care to elaborate? All I care is after I go >> through 8 or 100 back and forth changes, if I send a >> Join, I should get my content. It should not matter if If you are going back and forth on your remote to different channels, they are *different* multicast routes, that is different (S,G)s or (*,G)s. There is *no* problem here. >> Why should we use the reserved field? Because you want >> to replay the packet back as is? Why should it take an >> entire packet to ack the packet when a small packet >> with a TLV will do? How does this reduce refresh >> traffic when it is actually doubling it? Because you don't need to make from TLV ID for each route. We've been over this. >> Of course, when you are talking about a few entries. >> When there are millions of entries, the routers are >> busy, the packets get lost/dropped, the RTT will not >> be in milliseconds. Only during transients. Processing an MTU-sized JP-Ack is simply running through the packet, looking up the route, and clearing bits in the route. >> Which part is being over designed here? We want to make as few changes as possible. We want to keep the design simple. I believe the approach we put forward with JP-Ack can achieve that. In fact, I want to simplify it more becaus the RPF change logic and the neighbor going down refresh simplification. Dino From sboddapa@yahoo.com Fri Jan 28 02:20:25 2005 Received: from web81305.mail.yahoo.com (web81305.mail.yahoo.com [206.190.37.80]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j0S7KOP0017691 for ; Fri, 28 Jan 2005 02:20:25 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050128072019.12607.qmail@web81305.mail.yahoo.com> Received: from [64.169.160.207] by web81305.mail.yahoo.com via HTTP; Thu, 27 Jan 2005 23:20:19 PST Date: Thu, 27 Jan 2005 23:20:19 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] Proposal To: Dino Farinacci In-Reply-To: <200501280634.j0S6YQpu017283@dino-lnx.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Yetik_Serbest@labs.sbc.com, pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 28 Jan 2005 07:20:25 -0000 --- Dino Farinacci wrote: > > If you are going back and forth on your remote > to different channels, they > are *different* multicast routes, that is > different (S,G)s or (*,G)s. > > There is *no* problem here. > The problem is this. I send Join for (S1,G1), then I skip to the next channel, i.e. Leave for (S1,G1), Join for (S2, G2). Then I come back to (S1,G1), i.e. Leave for (S2,G2), and Join for (S1,G1). The Joins and Prunes for (S1,G1) are not acked yet. I could go on doing this effecting the same (S1,G1). Do you see the problem? > >> Why should we use the reserved field? Because you > want > >> to replay the packet back as is? Why should it > take an > >> entire packet to ack the packet when a small > packet > >> with a TLV will do? How does this reduce refresh > >> traffic when it is actually doubling it? > > Because you don't need to make from TLV ID for > each route. We've been > over this. And still you are not seeing that The Message ID TLV is not for each route, it is for a set of routes, the JP PDU. That is what gets Acked, and that is what gets refreshed. This reduces the processing overhead as well. The timers need to run only for the Message IDs, not for each state the Message ID represents. > > >> Of course, when you are talking about a few > entries. > >> When there are millions of entries, the routers > are > >> busy, the packets get lost/dropped, the RTT will > not > >> be in milliseconds. > > Only during transients. > Processing an MTU-sized > JP-Ack is simply running > through the packet, looking up the route, and > clearing bits in the route. But the traffic on the wire is more. Plus the CPU cycles do not reduce one bit. You still have to run timers for all downstream states. Plus, now ACK processing per route entry is an extra overhead which could be significantly reduced if the ACK was for a PDU, not a route. > > >> Which part is being over designed here? > > We want to make as few changes as possible. We > want to keep the design > simple. I believe the approach we put forward > with JP-Ack can achieve > that. In fact, I want to simplify it more becaus > the RPF change logic > and the neighbor going down refresh > simplification. > Yes, and we have been over this as well. We want to make few changes as possible to achieve two things: 1)Reduce refresh traffic: We do not want to mandate elimination of refresh traffic. If the users choose to refresh, we want to reduce the refresh traffic. 2)Reduce refresh processing cycles: Whenever there is refresh, we want to make sure it does not take too much CPU time. In your proposal, the refresh traffic and the refresh processing cycles both actually increase. The refresh traffic doubles because the ACK is of the same size as the JP. The processing cycles increase because the whole JP ACK has to be processed again by every downstream router, going through each entry. Plus, the upstream router's processing does not reduce in any way. What we want is less bytes on the wire and less time spent on processing refreshes. If a little complexity and a little more bookkeeping achieve it, it's worth it IMO. Suresh From dino@dino-lnx.cisco.com Fri Jan 28 02:59:41 2005 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0S7xeLN017751 for ; Fri, 28 Jan 2005 02:59:41 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 27 Jan 2005 23:59:44 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j0S7xWRO026530; Thu, 27 Jan 2005 23:59:33 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j0S7xWoq019947; Thu, 27 Jan 2005 23:59:32 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j0S7xW9C019943; Thu, 27 Jan 2005 23:59:32 -0800 Date: Thu, 27 Jan 2005 23:59:32 -0800 Message-Id: <200501280759.j0S7xW9C019943@dino-lnx.cisco.com> From: Dino Farinacci To: sboddapa@yahoo.com In-reply-to: <20050128072019.12607.qmail@web81305.mail.yahoo.com> (message from Suresh Boddapati on Thu, 27 Jan 2005 23:20:19 -0800 (PST)) Subject: Re: [Pim-state] Proposal References: <20050128072019.12607.qmail@web81305.mail.yahoo.com> Cc: Yetik_Serbest@labs.sbc.com, pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 28 Jan 2005 07:59:41 -0000 >> The problem is this. I send Join for (S1,G1), then I >> skip to the next channel, i.e. Leave for (S1,G1), Join >> for (S2, G2). Then I come back to (S1,G1), i.e. Leave >> for (S2,G2), and Join for (S1,G1). The Joins and >> Prunes for (S1,G1) are not acked yet. I could go on >> doing this effecting the same (S1,G1). Do you see the >> problem? If you are doing this manually, the human delay is much more than the Ack delay. And if the leave is accepted and data stops for the first route while you get data for the next route, that means the Leave and Join was processed by the upstream router. So the Ack is probably coming back as quick. >> And still you are not seeing that The Message ID TLV >> is not for each route, it is for a set of routes, the Yes, I know that. Why do you think I don't know that? I did read your draft weeks ago, I just haven't sent comments to you. So I do know what your design does. >> JP PDU. That is what gets Acked, and that is what gets >> refreshed. This reduces the processing overhead as >> well. The timers need to run only for the Message IDs, >> not for each state the Message ID represents. Yes, and that's the extra machinery outside of the multicast routing table I was telling you about. I don't want to repeat myself and I don't want you to repeat yourself. >> But the traffic on the wire is more. Plus the CPU >> cycles do not reduce one bit. You still have to run >> timers for all downstream states. Plus, now ACK >> processing per route entry is an extra overhead which >> could be significantly reduced if the ACK was for a >> PDU, not a route. I am eliminating refreshes. I want this to work for VPNs. You are still keeping periodic messages. >> Yes, and we have been over this as well. We want to >> make few changes as possible to achieve two things: You have the RPF change problem too. >> 1)Reduce refresh traffic: We do not want to mandate >> elimination of refresh traffic. If the users choose to >> refresh, we want to reduce the refresh traffic. I do. >> In your proposal, the refresh traffic and the refresh >> processing cycles both actually increase. The refresh I do not do refreshes. When a Join or Prune is triggered a JP-Ack is returned and the link goes silent until the next triggered event, period. Plus triggered packets will have small messages, so the processing is not as bad as you make it out to be. >> What we want is less bytes on the wire and less time >> spent on processing refreshes. If a little complexity >> and a little more bookkeeping achieve it, it's worth >> it IMO. And over the course of 1 hour, my scheme produces less packets then yours. And when you throw VPNs into the mix, you have a duplication problem, I don't. Dino From Yetik_Serbest@labs.sbc.com Fri Jan 28 10:45:23 2005 Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0SFjMgC018737 for ; Fri, 28 Jan 2005 10:45:23 -0500 (EST) (envelope-from Yetik_Serbest@labs.sbc.com) Received: from sbctri.tri.sbc.com (mayhem-webdmz.tri.sbc.com [144.60.9.139]) by howler.tri.sbc.com (8.12.10/8.12.10) with ESMTP id j0SFiLRt012792; Fri, 28 Jan 2005 09:44:21 -0600 (CST) Received: from TSMAIL2.ad.tri.sbc.com (tsmail2.ad.tri.sbc.com [144.60.55.226]) by sbctri.tri.sbc.com (8.12.10/8.12.10) with ESMTP id j0SFiLEq008501; Fri, 28 Jan 2005 09:44:21 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Pim-state] Proposal Date: Fri, 28 Jan 2005 09:44:21 -0600 Message-ID: <0CED449E95A92A42991EB71B778C17BF18BEEB@TSMAIL2.ad.tri.sbc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pim-state] Proposal Thread-Index: AcUFD1DngASqkV2XSJSiQrWKikk4GAAQEOYg From: "Serbest, Yetik" To: "Dino Farinacci" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by rock.mountain2sea.com id j0SFjMgC018737 Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 28 Jan 2005 15:45:23 -0000 Dino, If you are eliminating refreshes, then let's call it PIM refresh-elimination not PIM refresh-reduction. With what you are proposing: - PIM snooping will not work - There is no safety net: if something goes terribly wrong, downstream router may end up waiting and waiting and waiting ... for the ack. Thanks, yetik -----Original Message----- From: Dino Farinacci [mailto:dino@cisco.com] Sent: Friday, January 28, 2005 2:00 AM To: sboddapa@yahoo.com Cc: Serbest, Yetik; sboddapa@yahoo.com; pim-state@mountain2sea.com Subject: Re: [Pim-state] Proposal >> The problem is this. I send Join for (S1,G1), then I >> skip to the next channel, i.e. Leave for (S1,G1), Join >> for (S2, G2). Then I come back to (S1,G1), i.e. Leave >> for (S2,G2), and Join for (S1,G1). The Joins and >> Prunes for (S1,G1) are not acked yet. I could go on >> doing this effecting the same (S1,G1). Do you see the >> problem? If you are doing this manually, the human delay is much more than the Ack delay. And if the leave is accepted and data stops for the first route while you get data for the next route, that means the Leave and Join was processed by the upstream router. So the Ack is probably coming back as quick. >> And still you are not seeing that The Message ID TLV >> is not for each route, it is for a set of routes, the Yes, I know that. Why do you think I don't know that? I did read your draft weeks ago, I just haven't sent comments to you. So I do know what your design does. >> JP PDU. That is what gets Acked, and that is what gets >> refreshed. This reduces the processing overhead as >> well. The timers need to run only for the Message IDs, >> not for each state the Message ID represents. Yes, and that's the extra machinery outside of the multicast routing table I was telling you about. I don't want to repeat myself and I don't want you to repeat yourself. >> But the traffic on the wire is more. Plus the CPU >> cycles do not reduce one bit. You still have to run >> timers for all downstream states. Plus, now ACK >> processing per route entry is an extra overhead which >> could be significantly reduced if the ACK was for a >> PDU, not a route. I am eliminating refreshes. I want this to work for VPNs. You are still keeping periodic messages. >> Yes, and we have been over this as well. We want to >> make few changes as possible to achieve two things: You have the RPF change problem too. >> 1)Reduce refresh traffic: We do not want to mandate >> elimination of refresh traffic. If the users choose to >> refresh, we want to reduce the refresh traffic. I do. >> In your proposal, the refresh traffic and the refresh >> processing cycles both actually increase. The refresh I do not do refreshes. When a Join or Prune is triggered a JP-Ack is returned and the link goes silent until the next triggered event, period. Plus triggered packets will have small messages, so the processing is not as bad as you make it out to be. >> What we want is less bytes on the wire and less time >> spent on processing refreshes. If a little complexity >> and a little more bookkeeping achieve it, it's worth >> it IMO. And over the course of 1 hour, my scheme produces less packets then yours. And when you throw VPNs into the mix, you have a duplication problem, I don't. Dino From sboddapa@yahoo.com Fri Jan 28 11:27:50 2005 Received: from web81306.mail.yahoo.com (web81306.mail.yahoo.com [206.190.37.81]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j0SGRoeo018836 for ; Fri, 28 Jan 2005 11:27:50 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050128162745.26882.qmail@web81306.mail.yahoo.com> Received: from [64.169.160.207] by web81306.mail.yahoo.com via HTTP; Fri, 28 Jan 2005 08:27:45 PST Date: Fri, 28 Jan 2005 08:27:45 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] Proposal To: Dino Farinacci In-Reply-To: <200501280759.j0S7xW9C019943@dino-lnx.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Yetik_Serbest@labs.sbc.com, pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 28 Jan 2005 16:27:50 -0000 --- Dino Farinacci wrote: > > I do not do refreshes. When a Join or Prune is > triggered a JP-Ack is > returned and the link goes silent until the next > triggered event, period. > Sorry, you are forcing me to repeat myself. We have already discussed what could go wrong if we totally eliminate refreshes. Plus my scheme accomodates elimination, it does not mandate it. > Plus triggered packets will have small messages, > so the processing is > not as bad as you make it out to be. > > >> What we want is less bytes on the wire and less > time > >> spent on processing refreshes. If a little > complexity > >> and a little more bookkeeping achieve it, it's > worth > >> it IMO. > > And over the course of 1 hour, my scheme > produces less packets then yours. This is plain wrong. If we refresh, it's your scheme that will produce more than mine. If we do not, even then my scheme will have less number of bytes on the wire than yours since the Acks in my scheme are smaller for triggered events as well. > And when you throw VPNs into the mix, you have a > duplication problem, I > don't. > What is the duplication problem? It seems like instead of figuring out what is the best solution, it's turning out to be a "your solution vs my solution" battle, which I have no interest in; nor do I presume you have any interest in. I think we have reached a point where your solution has been discussed in great detail, mine has not been, but it's out there for anybody to go through. Instead of us bashing each other's solution and going on with endless repetitions (we both seem to agree on this), making it seem like we are trying to push our solutions simply because they are ours, I think it's high time that others got into the discussion. Some of those who have, I think we know where they stand. This is a group of only about 19-20 people, and of those, other than yours and mine, which are undisputedly the loudest, the voices we have heard on the topic are maybe 3 or 4. Maybe our daily exchange of emails is putting off people from getting into the discussion. Either way, if there is not going to be enough constructive participation, we are probably better off moving to a larger forum IMO, maybe the PIM mailing list. Suresh From dino@dino-lnx.cisco.com Fri Jan 28 14:34:07 2005 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0SJXvGu019134 for ; Fri, 28 Jan 2005 14:34:07 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 28 Jan 2005 11:35:00 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0SJXn1M025196; Fri, 28 Jan 2005 11:33:49 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j0SJXnnt005072; Fri, 28 Jan 2005 11:33:49 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j0SJXn18005068; Fri, 28 Jan 2005 11:33:49 -0800 Date: Fri, 28 Jan 2005 11:33:49 -0800 Message-Id: <200501281933.j0SJXn18005068@dino-lnx.cisco.com> From: Dino Farinacci To: Yetik_Serbest@labs.sbc.com In-reply-to: <0CED449E95A92A42991EB71B778C17BF18BEEB@TSMAIL2.ad.tri.sbc.com> (Yetik_Serbest@labs.sbc.com) Subject: Re: [Pim-state] Proposal References: <0CED449E95A92A42991EB71B778C17BF18BEEB@TSMAIL2.ad.tri.sbc.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 28 Jan 2005 19:34:11 -0000 >> If you are eliminating refreshes, then let's call it PIM >> refresh-elimination not PIM refresh-reduction. With what you are >> proposing: Fine, you can call it anything you want but eliminating refreshes is reducing to 0 in my opinion. >> - PIM snooping will not work We indicated that the switches *could* request refreshes, just like a new router coming up on an ethernet could. >> - There is no safety net: if something goes terribly wrong, downstream >> router may end up waiting and waiting and waiting ... for the ack. If a downstream router doesn't get an ack, it should retransmit, if it never gets an ack, there is a bug. Dino From rkebler@avici.com Fri Jan 28 15:15:57 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0SKFulg019212 for ; Fri, 28 Jan 2005 15:15:56 -0500 (EST) (envelope-from rkebler@avici.com) Received: from rkebler-pc (rkebler-pc.avici.com [10.2.20.48]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id j0SKFm7l003990; Fri, 28 Jan 2005 15:15:48 -0500 Message-Id: <4.2.0.58.20050128151540.00d4f220@mailhost.avici.com> X-Sender: rkebler@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 28 Jan 2005 15:24:30 -0500 To: Suresh Boddapati , pim-state@mountain2sea.com From: Robert Kebler Subject: Re: [Pim-state] Proposal In-Reply-To: <20050128162745.26882.qmail@web81306.mail.yahoo.com> References: <200501280759.j0S7xW9C019943@dino-lnx.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 28 Jan 2005 20:15:57 -0000 Suresh, I had a look at your proposal today. I have a few comments on it, but there is one very fundamental piece that I am missing. The Message ID TLV will be encoded inside the JP message, but I don't see any details on how exactly this will be done. This is a very basic piece that should be explained. Also, how is a legacy PIM router (implementing the base spec) going to parse a JP message that now has a TLV stuck inside of it? If we are modifying the format of a JP message, then this will not be backwards compatible with a legacy router. Thanks, Bob From sboddapa@yahoo.com Fri Jan 28 15:54:00 2005 Received: from web81305.mail.yahoo.com (web81305.mail.yahoo.com [206.190.37.80]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j0SKs0xG019280 for ; Fri, 28 Jan 2005 15:54:00 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050128205355.64185.qmail@web81305.mail.yahoo.com> Received: from [64.169.160.207] by web81305.mail.yahoo.com via HTTP; Fri, 28 Jan 2005 12:53:55 PST Date: Fri, 28 Jan 2005 12:53:55 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] Proposal To: Robert Kebler , pim-state@mountain2sea.com In-Reply-To: <4.2.0.58.20050128151540.00d4f220@mailhost.avici.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 28 Jan 2005 20:54:00 -0000 Robert, I agree it should be explained in more detail as it is not quite intuitive. But it works as follows: >From the IP packet, you know the message of the JP PDU. There is the numgroups field in the JP PDU that tells you how many groups are encoded. Then there is the number of Joined Sources and the number of Pruned Sources per group. A legacy router will not go beyond the part where the number of groups is exhausted. There is nothing in the PIM spec that says that if the length of the PDU is greater than what the number of groups (and the joined and pruned sources corresponding to each of them) amounts to, it should drop the PDU. This is a good thing, because you could always add other things like authentication etc. A router that implements PIM refresh will understand it and parse it. So it is backwards compatible. I can add something along these lines. Suresh --- Robert Kebler wrote: > Suresh, > I had a look at your proposal today. I have a few > comments on it, but > there is one very > fundamental piece that I am missing. The Message ID > TLV will be encoded inside > the JP message, but I don't see any details on how > exactly this will be > done. This is a > very basic piece that should be explained. Also, > how is a legacy PIM router > (implementing the base spec) going to parse a JP > message that now has a > TLV stuck inside of it? If we are modifying the > format of a JP message, > then this > will not be backwards compatible with a legacy > router. > > Thanks, > Bob > From rkebler@avici.com Mon Jan 31 12:01:21 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0VH1DkG026344 for ; Mon, 31 Jan 2005 12:01:21 -0500 (EST) (envelope-from rkebler@avici.com) Received: from rkebler-pc (rkebler-pc.avici.com [10.2.20.48]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id j0VH147l015611; Mon, 31 Jan 2005 12:01:04 -0500 Message-Id: <4.2.0.58.20050131112936.00d58660@mailhost.avici.com> X-Sender: rkebler@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 31 Jan 2005 12:09:47 -0500 To: pim-state@mountain2sea.com, Suresh Boddapati From: Robert Kebler Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: Subject: [Pim-state] comments X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 31 Jan 2005 17:01:22 -0000 Suresh, here are some comments: Since you are proposing a TLV at the end, it might be better to have a separate spec would gives a generic method of including a TLV in a JP message that is backwards compatible with legacy PIM routers. Then the refresh spec would be one application of that. It is not clear to me what happens when new groups are joined and left. Do we send the entire JP message with the message ID, or do we send only the changed groups with the existing message ID? We should probably specify the way to remove the association between the JP state and the message ID. You mention "the largest value of the holdtime encoded in the Join/Prune Message". There is only one holdtime in a JP message. If an upstream router receives a JP message with the I bit set, and it has no state for that message ID, you say to discard without further action? Isn't this an error condition that should not happen. This should be logged as such. I think it would help in manageability if we specified what the error conditions are. The second to last sentence in 6.1 reads "if there is one or more Message IDs associated with the downstream state... no action is taken". Would a downstream router be sending Joins for the same group with more than one message ID? Sequence Number wrap needs to be addressed. You say that implementations can bring down the adjacency if a message is not being ACKed. How helpful is this? It is not clear from your example in section 8.0 if you are doing "Explicit Tracking". It seems that some of you bullets say you are doing explicit tracking but bullet 6 says "D2 is interested in (S1,G1) but it sees D1's Join". This behavior regarding Join Suppression should be explained and not just inferred from an example. I think refreshing complete state every 15 minutes is too much. I think every hour is fine. Also, there should be a way to request complete Join/Prune state. My opinion on you background writeup is we should avoid the L2/L3 VPN discussion as much as possible. This idea is simply making PIM more scalable and I think we should leave it at that. For example, what if L2/L3 VPNs decide to go another direction? That would not invalidate this work. This work is useful for making PIM more scalable. -Bob From suresh.boddapati@alcatel.com Mon Jan 31 17:40:07 2005 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j0VMe7Y9026865 for ; Mon, 31 Jan 2005 17:40:07 -0500 (EST) (envelope-from suresh.boddapati@alcatel.com) Received: from alcatelxp ([172.22.187.74] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 31 Jan 2005 14:39:54 -0800 From: "Suresh Boddapati" To: "'Robert Kebler'" , , "'Suresh Boddapati'" Subject: RE: [Pim-state] comments Date: Mon, 31 Jan 2005 14:38:19 -0800 Organization: Alcatel USA Message-ID: <061d01c507e5$914dd6f0$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <4.2.0.58.20050131112936.00d58660@mailhost.avici.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-OriginalArrivalTime: 31 Jan 2005 22:39:54.0779 (UTC) FILETIME=[C8CE36B0:01C507E5] Cc: X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: suresh.boddapati@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 31 Jan 2005 22:40:07 -0000 Hi Bob, Thank you for your comments. Responses inline. > > Since you are proposing a TLV at the end, it might be better to have a > separate spec would > gives a generic method of including a TLV in a JP message that is > backwards > compatible > with legacy PIM routers. Then the refresh spec would be one application > of > that. > I agree. > It is not clear to me what happens when new groups are joined and left. > Do we > send the entire JP message with the message ID, or do we send only the > changed > groups with the existing message ID? > The I bit takes care of this. When new groups Join and if there is room in an existing Message ID, we simply send the Joins with the Message ID TLV (higher seq no.) and the I bit set. That indicates that there is an incremental addition to the existing state. If existing states are removed, only those Prunes are sent again with the I bit set indicating that the incremental change is a deletion. > We should probably specify the way to remove the association between the > JP > state and > the message ID. > As explained above, a Prune takes away the association between a JP state sent by a downstream router and its Message ID. The Message ID itself should not be removed (need to specify this in the doc) even if there are no more states associated with it. It should be aged out using the holdtime unless explicitly removed by the downstream router. The downstream router can reuse the Message ID in the interim if there are any new states to be encoded. A downstream router can also remove it explicitly by sending a holdtime value of zero in the Message ID TLV. While a Message M1 with zero holdtime is waiting to be Acked, if there are new states, the downstream router should not use M1 for those states because the upstream router may already have taken out the association. Note the upstream router will discard any updates received for a Message ID with I bit set, if it does not have the Message ID. > You mention "the largest value of the holdtime encoded in the Join/Prune > Message". There > is only one holdtime in a JP message. > You are right. This should be removed. I added a holdtime field to the Message ID TLV which should be used (need this for message refreshes as well). > If an upstream router receives a JP message with the I bit set, and it has > no state for that > message ID, you say to discard without further action? Isn't this an > error > condition that > should not happen. This should be logged as such. I think it would help > in manageability > if we specified what the error conditions are. > Ok. > The second to last sentence in 6.1 reads "if there is one or more Message > IDs associated > with the downstream state... no action is taken". Would a downstream > router be sending > Joins for the same group with more than one message ID? > It is possible. The reason why a downstream router could do this is to compact Message IDs. For example, if there are three Message IDs M1, M2 and M3, all of them full with Join states for various entries. After a series of Prunes, if M1, M2 and M3 are left with a few entries which could all fit in one Message, then the downstream router can choose to associate all of them with one Message, say M1. In this case, it would first associate all the states with the compact Message ID TLV by sending a Join for those states with M1 and then disassociate the old state by sending a Prune for the states with M2 and M3 (after getting an ACK back for the Joins for the new Message ID). As long as there is at least one association, the upstream state will stay alive. This way of compacting sparse messages is optional, not mandatory, but I left room for such mechanism. > Sequence Number wrap needs to be addressed. > Agreed. > You say that implementations can bring down the adjacency if a message is > not being > ACKed. How helpful is this? > The point is after a certain number of retransmissions (whatever value you choose, but this would be a reasonably large value hopefully), if you are not getting ACKS, that means there is something seriously wrong. It's upto the operator whether he wants the adjacency to be brought down or not, using possibly a configuration knob. Traps could be generated instead when a message stays unacked after n retransmissions. > It is not clear from your example in section 8.0 if you are doing > "Explicit > Tracking". It seems > that some of you bullets say you are doing explicit tracking but bullet 6 > says "D2 is > interested in (S1,G1) but it sees D1's Join". This behavior regarding > Join > Suppression > should be explained and not just inferred from an example. I can expand on this. Basically the idea is that explicit tracking at the upstream router occurs when it receives a Message ID TLV in a JP PDU. Here we track every downstream nbr for a JP state using the nbr's IP and Message ID TLV, (in the example, M1D1). And if there are multiple such associations for a state, losing one association amounts to no action on the part of both the upstream and other downstream routers. A downstream router does not have to override the Prune sent by another downstream router as long as it has registered its association with the upstream nbr. As for Join suppression, it comes into picture only when a downstream router has not registered its association with the upstream router. If D2 sees D1's Join to U1 and D2 has not associated the state with any Message ID, D2 will not send its Join immediately and thereby does not associate the state with any Message ID TLV. The Join refresh timer will be running at D2 for the state. That timer will expire at D2, because D1 will not refresh the state with a Join again (it will simply refresh M1). At that point, D2 will send out the Join with its Message ID TLV M1 and U1 will create another association between the state and M1D2. > > I think refreshing complete state every 15 minutes is too much. I think > every hour is fine. Fine with me. The constant can be picked once there is consensus. > Also, there should be a way to request complete Join/Prune state. > Originally, my thought was to send complete updates periodically (Section 10). But so far there seems to be more inclination towards doing this on demand. I can change the text to reflect this. > My opinion on you background writeup is we should avoid the L2/L3 VPN > discussion as > much as possible. This idea is simply making PIM more scalable and I > think > we should > leave it at that. For example, what if L2/L3 VPNs decide to go another > direction? That > would not invalidate this work. This work is useful for making PIM more > scalable. > Ok with me. Suresh From rkebler@avici.com Thu Feb 3 18:09:16 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j13N95B7035368 for ; Thu, 3 Feb 2005 18:09:16 -0500 (EST) (envelope-from rkebler@avici.com) Received: from rkebler-pc (rkebler-pc.avici.com [10.2.20.48]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id j13N8v7l006596; Thu, 3 Feb 2005 18:08:57 -0500 Message-Id: <4.2.0.58.20050203172224.00daeb40@mailhost.avici.com> X-Sender: rkebler@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 03 Feb 2005 18:17:41 -0500 To: , "'Suresh Boddapati'" From: Robert Kebler Subject: RE: [Pim-state] comments In-Reply-To: <061d01c507e5$914dd6f0$4abb16ac@alcatelxp> References: <4.2.0.58.20050131112936.00d58660@mailhost.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 03 Feb 2005 23:09:17 -0000 Hi Suresh, Now some general comments: I don't think we need these "Join/Prune Refresh Messages" because I'm not sure that they do anything useful. I feel that if we are going to have refreshes, then we should resend the JP messages. Resending only the message IDs is a shortcut, but are you really accomplishing anything? Why are refreshes even needed? In some protocols they are needed to remove stale advertisements for dead routers. These JP messages don't have that same problem because they are sent one hop. I would say that they are good to safeguard against inconsistencies. By leaving the holdtime in the JP message we are leaving it to the user to decide for himself. If refreshing state doesn't make sense, then the JP messages can be sent with MAX holdtime. There are other ways of ensuring database consistency if that is the only reason why we are resending the database. Maybe your method could be extended to include a "checksum" for each Message ID to verify that the upstream router does in fact have consistent state for that Message ID. If the checksum doesn't match, then the upstream router will request the JP state to be sent. If the checksum matches, then we just wait for the next refresh. -Bob At 02:38 PM 1/31/05 -0800, Suresh Boddapati wrote: >Hi Bob, > >Thank you for your comments. Responses inline. > > > > > Since you are proposing a TLV at the end, it might be better to have a > > separate spec would > > gives a generic method of including a TLV in a JP message that is > > backwards > > compatible > > with legacy PIM routers. Then the refresh spec would be one >application > > of > > that. > > >I agree. > > > It is not clear to me what happens when new groups are joined and >left. > > Do we > > send the entire JP message with the message ID, or do we send only the > > changed > > groups with the existing message ID? > > >The I bit takes care of this. When new groups Join and if there is room >in an existing Message ID, we simply send the Joins with the Message ID >TLV (higher seq no.) and the I bit set. That indicates that there is an >incremental addition to the existing state. If existing states are >removed, only those Prunes are sent again with the I bit set indicating >that the incremental change is a deletion. > > > We should probably specify the way to remove the association between >the > > JP > > state and > > the message ID. > > >As explained above, a Prune takes away the association between a JP >state sent by a downstream router and its Message ID. The Message ID >itself should not be removed (need to specify this in the doc) even if >there are no more states associated with it. It should be aged out using >the holdtime unless explicitly removed by the downstream router. The >downstream router can reuse the Message ID in the interim if there are >any new states to be encoded. A downstream router can also remove it >explicitly by sending a holdtime value of zero in the Message ID TLV. >While a Message M1 with zero holdtime is waiting to be Acked, if there >are new states, the downstream router should not use M1 for those states >because the upstream router may already have taken out the association. >Note the upstream router will discard any updates received for a Message >ID with I bit set, if it does not have the Message ID. > > > You mention "the largest value of the holdtime encoded in the >Join/Prune > > Message". There > > is only one holdtime in a JP message. > > >You are right. This should be removed. I added a holdtime field to the >Message ID TLV which should be used (need this for message refreshes as >well). > > > If an upstream router receives a JP message with the I bit set, and it >has > > no state for that > > message ID, you say to discard without further action? Isn't this an > > error > > condition that > > should not happen. This should be logged as such. I think it would >help > > in manageability > > if we specified what the error conditions are. > > >Ok. > > > The second to last sentence in 6.1 reads "if there is one or more >Message > > IDs associated > > with the downstream state... no action is taken". Would a downstream > > router be sending > > Joins for the same group with more than one message ID? > > >It is possible. The reason why a downstream router could do this is to >compact Message IDs. For example, if there are three Message IDs M1, M2 >and M3, all of them full with Join states for various entries. After a >series of Prunes, if M1, M2 and M3 are left with a few entries which >could all fit in one Message, then the downstream router can choose to >associate all of them with one Message, say M1. In this case, it would >first associate all the states with the compact Message ID TLV by >sending a Join for those states with M1 and then disassociate the old >state by sending a Prune for the states with M2 and M3 (after getting an >ACK back for the Joins for the new Message ID). As long as there is at >least one association, the upstream state will stay alive. This way of >compacting sparse messages is optional, not mandatory, but I left room >for such mechanism. > > > Sequence Number wrap needs to be addressed. > > >Agreed. > > > You say that implementations can bring down the adjacency if a message >is > > not being > > ACKed. How helpful is this? > > >The point is after a certain number of retransmissions (whatever value >you choose, but this would be a reasonably large value hopefully), if >you are not getting ACKS, that means there is something seriously wrong. >It's upto the operator whether he wants the adjacency to be brought down >or not, using possibly a configuration knob. Traps could be generated >instead when a message stays unacked after n retransmissions. > > > It is not clear from your example in section 8.0 if you are doing > > "Explicit > > Tracking". It seems > > that some of you bullets say you are doing explicit tracking but >bullet 6 > > says "D2 is > > interested in (S1,G1) but it sees D1's Join". This behavior regarding > > Join > > Suppression > > should be explained and not just inferred from an example. >I can expand on this. Basically the idea is that explicit tracking at >the upstream router occurs when it receives a Message ID TLV in a JP >PDU. Here we track every downstream nbr for a JP state using the nbr's >IP and Message ID TLV, (in the example, M1D1). And if there are multiple >such associations for a state, losing one association amounts to no >action on the part of both the upstream and other downstream routers. A >downstream router does not have to override the Prune sent by another >downstream router as long as it has registered its association with the >upstream nbr. >As for Join suppression, it comes into picture only when a downstream >router has not registered its association with the upstream router. If >D2 sees D1's Join to U1 and D2 has not associated the state with any >Message ID, D2 will not send its Join immediately and thereby does not >associate the state with any Message ID TLV. The Join refresh timer will >be running at D2 for the state. That timer will expire at D2, because D1 >will not refresh the state with a Join again (it will simply refresh >M1). At that point, D2 will send out the Join with its Message ID TLV M1 >and U1 will create another association between the state and M1D2. > > > > > I think refreshing complete state every 15 minutes is too much. I >think > > every hour is fine. > >Fine with me. The constant can be picked once there is consensus. > > > Also, there should be a way to request complete Join/Prune state. > > >Originally, my thought was to send complete updates periodically >(Section 10). But so far there seems to be more inclination towards >doing this on demand. I can change the text to reflect this. > > > My opinion on you background writeup is we should avoid the L2/L3 VPN > > discussion as > > much as possible. This idea is simply making PIM more scalable and I > > think > > we should > > leave it at that. For example, what if L2/L3 VPNs decide to go >another > > direction? That > > would not invalidate this work. This work is useful for making PIM >more > > scalable. > > >Ok with me. > >Suresh From dino@dino-lnx.cisco.com Thu Feb 3 20:47:11 2005 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j141lBHn035605 for ; Thu, 3 Feb 2005 20:47:11 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 03 Feb 2005 17:48:19 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j141kxPA002691; Thu, 3 Feb 2005 17:47:01 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j141kxrO016386; Thu, 3 Feb 2005 17:46:59 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j141kwNX016382; Thu, 3 Feb 2005 17:46:58 -0800 Date: Thu, 3 Feb 2005 17:46:58 -0800 Message-Id: <200502040146.j141kwNX016382@dino-lnx.cisco.com> From: Dino Farinacci To: rkebler@avici.com In-reply-to: <4.2.0.58.20050203172224.00daeb40@mailhost.avici.com> (message from Robert Kebler on Thu, 03 Feb 2005 18:17:41 -0500) Subject: Re: [Pim-state] comments References: <4.2.0.58.20050131112936.00d58660@mailhost.avici.com> <4.2.0.58.20050203172224.00daeb40@mailhost.avici.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 04 Feb 2005 01:47:11 -0000 >> I would say that they are good to safeguard against inconsistencies. By >> leaving the >> holdtime in the JP message we are leaving it to the user to decide for >> himself. If >> refreshing state doesn't make sense, then the JP messages can be sent with >> MAX holdtime. Ya know, considering all the issues we see with the various designs, this might be an acceptable solution. One could alwasy override a Max holdtime JP with one could timeout quicker. Just exploring tradeoffs. >> There are other ways of ensuring database consistency if that is the only >> reason >> why we are resending the database. >> Maybe your method could be extended to include a "checksum" for each Message ID >> to verify that the upstream router does in fact have consistent state for that >> Message ID. If the checksum doesn't match, then the upstream router will >> request the >> JP state to be sent. If the checksum matches, then we just wait for the >> next refresh. Yes, that was one of the solution outlined when this list was started. Dino From sboddapa@yahoo.com Fri Feb 4 02:03:46 2005 Received: from web81307.mail.yahoo.com (web81307.mail.yahoo.com [206.190.37.82]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j1473k86036160 for ; Fri, 4 Feb 2005 02:03:46 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050204070340.18955.qmail@web81307.mail.yahoo.com> Received: from [64.160.54.224] by web81307.mail.yahoo.com via HTTP; Thu, 03 Feb 2005 23:03:40 PST Date: Thu, 3 Feb 2005 23:03:40 -0800 (PST) From: Suresh Boddapati Subject: RE: [Pim-state] comments To: Robert Kebler , pim-state@mountain2sea.com In-Reply-To: <4.2.0.58.20050203172224.00daeb40@mailhost.avici.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 04 Feb 2005 07:03:46 -0000 > I don't think we need these "Join/Prune Refresh > Messages" because I'm not sure > that they do anything useful. I feel that if we are > going to have > refreshes, then we > should resend the JP messages. Resending only the > message IDs is a shortcut, > but are you really accomplishing anything? > Goes back to whether refreshes make sense or not, and how often you want to refresh. If you assume periodic refreshes are better, there are two benefits I see here because of the shortcut; we can debate if they are worth it. 1) The messages are much shorter. Note you can refresh multiple Message IDs in one message. So the reduction in the number of messages required to refresh is significant. 2) Processing overhead for refreshes: Timers need to be run only for Messages, not for each state. State can be refreshed collectively. > Why are refreshes even needed? > In some protocols they are needed to remove stale > advertisements for dead > routers. > These JP messages don't have that same problem > because they are sent one hop. Let's consider OSPF or ISIS for example. OSPF refreshes its LSAs even if nothing changes. ISIS refreshes its LSPs even if nothing changes. If you were to change OSPF or ISIS, would you take away the refreshes? As long as the adjacency is there and the topology remains the same, would you say that Hellos are sufficient to conclude that existing state is valid? Note this has nothing to do with whether the message goes one hop or multi hop. If I sync up my state with my adjacency, that state need not be refreshed with my adjacency. My nbr can sync it up with its nbr and not refresh it again and so on. What do you think? Let's assume for a second that we want to refresh. If you add reliability to the existing scheme, there is no need to refresh as often as a minute like we do today. If you increase the holdtime to large values (in minutes, say 60 minutes or greater), and add appropriate jitter to your refresh timers (now you have a large room for jittering multiple states to refresh at different intervals), then can we say that adding reliability alone will take care of refresh reduction and the refresh scheme can continue to exist as is? If yes, then we need not have separate JP Refresh messages. We could just use the JP messages as is like you are saying. The requirement for Message ID association with JP states can also be relaxed. The upstream router need not keep the association at all. The Message ID in a JP PDU sent by a downstream router needs to live only as long as the latest version of the Message is not acknowledged. So if D sends a set of states in a JP PDU with an associated Message ID to U, once the Message ID is acked, the Message ID no longer has any meaning to U or D, and can be gotten rid of. But while a Message ID is pending ack, if the contained state changes, the sequence number in the Message ID will still help in differentiating the latest info from the old. > I would say that they are good to safeguard against > inconsistencies. I agree. By > leaving the > holdtime in the JP message we are leaving it to the > user to decide for > himself. If > refreshing state doesn't make sense, then the JP > messages can be sent with > MAX holdtime. > Sure. It gives the user the flexibility to decide whether he wants to refresh at the expense of more control traffic or not refresh at the expense of possible states that persist longer than they have to. It's like OSPF, with the doNotAge bit. Allow for both in the protocol, leave the decision to the user. > There are other ways of ensuring database > consistency if that is the only > reason > why we are resending the database. > Maybe your method could be extended to include a > "checksum" for each Message ID > to verify that the upstream router does in fact have > consistent state for that > Message ID. If the checksum doesn't match, then the > upstream router will > request the > JP state to be sent. If the checksum matches, then > we just wait for the > next refresh. > The only problem with checksum I see is that it imposes additional ordering requirements. If I just compare the checksum for a Message ID, then my nbr has to keep the JP PDU in exactly the same way it sent last time (instead of keeping exactly the same states no matter what their order is) in order for the checksum to be the same. In other words, instead of semantically remembering which states map to which Message ID, you also have to remember what order they were encoded in. Plus, how do you deal with incremental changes to a Message ID? In OSPF, you dont send incremental changes to an LSA, you just send the LSA as is with the new checksum. In protocols like OSPF, you actually store the LSA as is. In PIM, we dont (have to) really store the PDU. Suresh From yakov@juniper.net Fri Feb 4 09:55:33 2005 Received: from colo-dns-ext1.juniper.net (colo-dns-ext1.juniper.net [207.17.137.57]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j14EtWHr037161 for ; Fri, 4 Feb 2005 09:55:33 -0500 (EST) (envelope-from yakov@juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j14EtR931118; Fri, 4 Feb 2005 06:55:27 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j14EtEe35093; Fri, 4 Feb 2005 06:55:14 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200502041455.j14EtEe35093@merlot.juniper.net> To: Suresh Boddapati Subject: Re: [Pim-state] comments In-Reply-To: Your message of "Thu, 03 Feb 2005 23:03:40 PST." <20050204070340.18955.qmail@web81307.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <68058.1107528914.1@juniper.net> Date: Fri, 04 Feb 2005 06:55:14 -0800 From: Yakov Rekhter Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 04 Feb 2005 14:55:33 -0000 Suresh, [clipped...] > > Why are refreshes even needed? > > In some protocols they are needed to remove stale > > advertisements for dead > > routers. > > These JP messages don't have that same problem > > because they are sent one hop. > > Let's consider OSPF or ISIS for example. OSPF > refreshes its LSAs even if nothing changes. ISIS > refreshes its LSPs even if nothing changes. If you > were to change OSPF or ISIS, would you take away the > refreshes? As long as the adjacency is there and the > topology remains the same, would you say that Hellos > are sufficient to conclude that existing state is > valid? Note this has nothing to do with whether the > message goes one hop or multi hop. If I sync up my > state with my adjacency, that state need not be > refreshed with my adjacency. My nbr can sync it up > with its nbr and not refresh it again and so on. What > do you think? Let's also consider BGP for example. "vanilla" BGP has no refreshes at all. The BGP refresh mechanism is optional, and is intended to handle the situation where a router due to the inbound filtering discards some of information received from the neighbor. If the inbound filtering changes, to recover the discarded information the router requests the neighbor to refresh the information the neighbor sent to the router. Yakov. From rkebler@avici.com Fri Feb 4 10:07:07 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j14F77TA037199 for ; Fri, 4 Feb 2005 10:07:07 -0500 (EST) (envelope-from rkebler@avici.com) Received: from rkebler-pc (rkebler-pc.avici.com [10.2.20.48]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id j14F717l031219; Fri, 4 Feb 2005 10:07:01 -0500 Message-Id: <4.2.0.58.20050204095819.00d31170@mailhost.avici.com> X-Sender: rkebler@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 04 Feb 2005 10:15:46 -0500 To: Suresh Boddapati , Robert Kebler , pim-state@mountain2sea.com From: Robert Kebler Subject: RE: [Pim-state] comments In-Reply-To: <20050204070340.18955.qmail@web81307.mail.yahoo.com> References: <4.2.0.58.20050203172224.00daeb40@mailhost.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 04 Feb 2005 15:07:08 -0000 At 11:03 PM 2/3/05 -0800, Suresh Boddapati wrote: > > I don't think we need these "Join/Prune Refresh > > Messages" because I'm not sure > > that they do anything useful. I feel that if we are > > going to have > > refreshes, then we > > should resend the JP messages. Resending only the > > message IDs is a shortcut, > > but are you really accomplishing anything? > > >Goes back to whether refreshes make sense or not, and >how often you want to refresh. If you assume periodic >refreshes are better, there are two benefits I see >here because of the shortcut; we can debate if they >are worth it. >1) The messages are much shorter. Note you can refresh >multiple Message IDs in one message. So the reduction >in the number of messages required to refresh is >significant. >2) Processing overhead for refreshes: Timers need to >be run only for Messages, not for each state. State >can be refreshed collectively. I agree with both these points but I'm wondering if these refreshes accomplish anything? Sending the entire JP state would at least safeguard against inconsistent state. I don't think this method would be as successful at cleaning up inconsistent state. > > Why are refreshes even needed? > > In some protocols they are needed to remove stale > > advertisements for dead > > routers. > > These JP messages don't have that same problem > > because they are sent one hop. > >Let's consider OSPF or ISIS for example. OSPF >refreshes its LSAs even if nothing changes. ISIS >refreshes its LSPs even if nothing changes. If you >were to change OSPF or ISIS, would you take away the >refreshes? As long as the adjacency is there and the >topology remains the same, would you say that Hellos >are sufficient to conclude that existing state is >valid? Note this has nothing to do with whether the >message goes one hop or multi hop. If I sync up my >state with my adjacency, that state need not be >refreshed with my adjacency. My nbr can sync it up >with its nbr and not refresh it again and so on. What >do you think? The OSPF LSAs are flooded throughout the network. If one node goes down then all the nodes will know to route around that node due to the bidirectional checks. But nothing is going to flush those LSAs from the network. Without refreshes, those LSAs would stay in the network indefinitely. PIM JP messages are different. These messages are sent from one node to its neighbor. It does not have this same problem that link-state protocols have. >Let's assume for a second that we want to refresh. >If you add reliability to the existing scheme, there >is no need to refresh as often as a minute like we do >today. If you increase the holdtime to large values >(in minutes, say 60 minutes or greater), and add >appropriate jitter to your refresh timers (now you >have a large room for jittering multiple states to >refresh at different intervals), then can we say that >adding reliability alone will take care of refresh >reduction and the refresh scheme can continue to exist >as is? This would be simplified way of going about it which I like. >If yes, then we need not have separate JP Refresh >messages. We could just use the JP messages as is like >you are saying. The requirement for Message ID >association with JP states can also be relaxed. The >upstream router need not keep the association at all. >The Message ID in a JP PDU sent by a downstream router >needs to live only as long as the latest version of >the Message is not acknowledged. So if D sends a set >of states in a JP PDU with an associated Message ID to >U, once the Message ID is acked, the Message ID no >longer has any meaning to U or D, and can be gotten >rid of. But while a Message ID is pending ack, if the >contained state changes, the sequence number in the >Message ID will still help in differentiating the >latest info from the old. > > > I would say that they are good to safeguard against > > inconsistencies. >I agree. > > By > > leaving the > > holdtime in the JP message we are leaving it to the > > user to decide for > > himself. If > > refreshing state doesn't make sense, then the JP > > messages can be sent with > > MAX holdtime. > > >Sure. It gives the user the flexibility to decide >whether he wants to refresh at the expense of more >control traffic or not refresh at the expense of >possible states that persist longer than they have to. >It's like OSPF, with the doNotAge bit. Allow for both >in the protocol, leave the decision to the user. > > > There are other ways of ensuring database > > consistency if that is the only > > reason > > why we are resending the database. > > Maybe your method could be extended to include a > > "checksum" for each Message ID > > to verify that the upstream router does in fact have > > consistent state for that > > Message ID. If the checksum doesn't match, then the > > upstream router will > > request the > > JP state to be sent. If the checksum matches, then > > we just wait for the > > next refresh. > > >The only problem with checksum I see is that it >imposes additional ordering requirements. If I just >compare the checksum for a Message ID, then my nbr has >to keep the JP PDU in exactly the same way it sent >last time (instead of keeping exactly the same states >no matter what their order is) in order for the >checksum to be the same. In other words, instead of >semantically remembering which states map to which >Message ID, you also have to remember what order they >were encoded in. Plus, how do you deal with >incremental changes to a Message ID? In OSPF, you dont >send incremental changes to an LSA, you just send the >LSA as is with the new checksum. In protocols like >OSPF, you actually store the LSA as is. In PIM, we >dont (have to) really store the PDU. I meant this to be a general concept that I didn't really think out. I would be fine with not doing this because it may overcomplicate things unnecessarily. My main point was that I don't think refreshing the message IDs really does anything. If we could add an additional piece to these messages which could verify database integrity then this method would be more attractive. But I like the idea of using the message IDs simply for ACKs. >Suresh From sboddapa@yahoo.com Fri Feb 4 10:35:33 2005 Received: from web81302.mail.yahoo.com (web81302.mail.yahoo.com [206.190.37.77]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j14FZX9d037248 for ; Fri, 4 Feb 2005 10:35:33 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050204153528.80165.qmail@web81302.mail.yahoo.com> Received: from [64.160.54.224] by web81302.mail.yahoo.com via HTTP; Fri, 04 Feb 2005 07:35:27 PST Date: Fri, 4 Feb 2005 07:35:27 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] comments To: Yakov Rekhter In-Reply-To: <200502041455.j14EtEe35093@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 04 Feb 2005 15:35:33 -0000 --- Yakov Rekhter wrote: > > Let's also consider BGP for example. "vanilla" BGP > has no refreshes > at all. > Yakov, a general comment on the way protocols were designed. It seems like most protocols built on TCP do not refresh their states, while protocols that do not have a "connection" seem to. Take LDP vs RSVP. LDP does not refresh, while RSVP does. BGP does not, while OSPF does. My question is, why? What would have been the fundamental assumption here? OSPF has LSACKs, so if you sent your nbr something and it acked it, you know it has the latest info. As long as your nbr is alive and in the absence of any changes in the topology, why do you have to refresh the state? Why were holdtime/age like fields created in PDUs for these protocols? Was it the case that there were bugs that caused states to persist when they did not have to? Refreshes and aging out states in the absence of refreshes may have seemed the right way to solve it? Were they wary of packets that update existing states getting lost, despite the protocols having mechanisms for retransmission? I don't know, I am just asking. Suresh From sboddapa@yahoo.com Fri Feb 4 10:45:07 2005 Received: from web81304.mail.yahoo.com (web81304.mail.yahoo.com [206.190.37.79]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j14Fj7Th037273 for ; Fri, 4 Feb 2005 10:45:07 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050204154502.89130.qmail@web81304.mail.yahoo.com> Received: from [64.160.54.224] by web81304.mail.yahoo.com via HTTP; Fri, 04 Feb 2005 07:45:02 PST Date: Fri, 4 Feb 2005 07:45:02 -0800 (PST) From: Suresh Boddapati Subject: RE: [Pim-state] comments To: Robert Kebler , pim-state@mountain2sea.com In-Reply-To: <4.2.0.58.20050204095819.00d31170@mailhost.avici.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 04 Feb 2005 15:45:07 -0000 --- Robert Kebler wrote: > > The OSPF LSAs are flooded throughout the network. > If > one node goes down then all the nodes will know to > route > around that node due to the bidirectional checks. > But nothing > is going to flush those LSAs from the network. Ah... of course. That's the part that I was missing. Thank you for clarifying that. Suresh From sboddapa@yahoo.com Fri Feb 4 18:14:16 2005 Received: from web81306.mail.yahoo.com (web81306.mail.yahoo.com [206.190.37.81]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j14NEGF7037964 for ; Fri, 4 Feb 2005 18:14:16 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050204231411.11068.qmail@web81306.mail.yahoo.com> Received: from [64.47.51.130] by web81306.mail.yahoo.com via HTTP; Fri, 04 Feb 2005 15:14:11 PST Date: Fri, 4 Feb 2005 15:14:11 -0800 (PST) From: Suresh Boddapati To: pim-state@mountain2sea.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Pim-state] Summary X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 04 Feb 2005 23:14:16 -0000 Trying to summarize the discussions that we had so far on the list: 1) To refresh or not: It seems like it is acceptable to most of us to live with refreshes if refreshes are done at a large interval (an hour or more). Adding reliability gives the flexibility to do refreshes at large intervals (assuming the intervals are jittered so that all states do not refresh at the same time). Using the existing JP messages to refresh instead of using a new PDU Type seems to be acceptable as well. Users can tweak the holdtime to get the refresh behavior they desire. 2) How to achieve reliability: Everyone agrees there should be an ACK mechanism. There are two schemes here: a) Dino's scheme: Have a bit per state, the intended recipient turns back the JP PDU into a new PDU type and does the Acking. Back to back changes to a state was pointed out as an issue. Dino's take is we could use the Reserved field in the JP PDU and use it as seq num. b) Use a Message ID TLV for Acking. The TLV has a sequence number, and is sent along with the JP PDU. The intended recipient acks using the Message ID TLV in a new PDU type. Back to back changes to states corresponding to a Message ID while it is pending ack causes the seq. num to bump up and the union of the old and new states is sent out. Once the latest Message ID is acked, the Message ID can be deleted. (Note this is a deviation from my original proposal. Now Message ID is being used only for acking). 3)Snooping: On demand request for states was mentioned. But if we are going to refresh at sometime, even if it is an hour, we dont need this. Is there anything else I have missed? Comments? Suresh From dino@dino-lnx.cisco.com Fri Feb 4 20:19:35 2005 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j151JZgA038151 for ; Fri, 4 Feb 2005 20:19:35 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 04 Feb 2005 17:19:50 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j151JRPA028891; Fri, 4 Feb 2005 17:19:27 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j151JRqa026295; Fri, 4 Feb 2005 17:19:27 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j151JRSv026291; Fri, 4 Feb 2005 17:19:27 -0800 Date: Fri, 4 Feb 2005 17:19:27 -0800 Message-Id: <200502050119.j151JRSv026291@dino-lnx.cisco.com> From: Dino Farinacci To: sboddapa@yahoo.com In-reply-to: <20050204231411.11068.qmail@web81306.mail.yahoo.com> (message from Suresh Boddapati on Fri, 4 Feb 2005 15:14:11 -0800 (PST)) Subject: Re: [Pim-state] Summary References: <20050204231411.11068.qmail@web81306.mail.yahoo.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 05 Feb 2005 01:19:35 -0000 >> Is there anything else I have missed? Comments? Good summary Suresh. One comment on PIM-snooping. I've been checking around at cisco and with customers to see how much PIM-snooping is deployed. The general comment is that it is not deployed a lot but some feel it will start increasing. There is no data to prove that the increase will actually happen so I believe the claim is speculative. So the question is, does this solution have to interop with PIM-snooping switches of today or with a change to support "request for refresh". So it could be a question of deploying the new code in switches. I am researching how people would feel about this. I can report when I have more concrete data. Dino From rkebler@avici.com Mon Feb 7 13:58:50 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j17IwlMw045197 for ; Mon, 7 Feb 2005 13:58:48 -0500 (EST) (envelope-from rkebler@avici.com) Received: from rkebler-pc (rkebler-pc.avici.com [10.2.20.48]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id j17IwX7l019383; Mon, 7 Feb 2005 13:58:33 -0500 Message-Id: <4.2.0.58.20050207112711.00d879c0@mailhost.avici.com> X-Sender: rkebler@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 07 Feb 2005 14:07:19 -0500 To: Suresh Boddapati , pim-state@mountain2sea.com From: Robert Kebler Subject: Re: [Pim-state] Summary In-Reply-To: <20050204231411.11068.qmail@web81306.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 07 Feb 2005 18:58:50 -0000 Here are my opinions on the topics which have been discussed: I think we should use the existing JP messages to refresh the state. I think it is really up to the implementation what to use as a default holdtime (no inter-operability issues) and the user to decide what to configure. If we really want to give a default, then I would say MAX_HOLDTIME. I like the idea of having some sort of "Sequence Number" or "Message ID" to Acknowledge. I think the best idea is to have a separate spec that gives a generic method of encoding a TLV at the end of a JP message. The first application of this will be to encode a "Message ID" in the JP message. I don't see the need to have both a Message ID and Sequence Number. All we really need is one 32-bit number. I think we need a method to request JP state. If we are going to allow no refreshes at all, I think it makes sense that we have some way of requesting JP State. I like Explicit Tracking. If we do Explicit Tracking then a downstream router does not always need to parse the JP messages intended for another router. -Bob At 03:14 PM 2/4/05 -0800, Suresh Boddapati wrote: >Trying to summarize the discussions that we had so far >on the list: > >1) To refresh or not: It seems like it is acceptable >to most of us to live with refreshes if refreshes are >done at a large interval (an hour or more). Adding >reliability gives the flexibility to do refreshes at >large intervals (assuming the intervals are jittered >so that all states do not refresh at the same time). >Using the existing JP messages to refresh instead of >using a new PDU Type seems to be acceptable as well. >Users can tweak the holdtime to get the refresh >behavior they desire. > >2) How to achieve reliability: Everyone agrees there >should be an ACK mechanism. There are two schemes >here: >a) Dino's scheme: Have a bit per state, the intended >recipient turns back the JP PDU into a new PDU type >and does the Acking. Back to back changes to a state >was pointed out as an issue. Dino's take is we could >use the Reserved field in the JP PDU and use it as seq >num. >b) Use a Message ID TLV for Acking. The TLV has a >sequence number, and is sent along with the JP PDU. >The intended recipient acks using the Message ID TLV >in a new PDU type. Back to back changes to states >corresponding to a Message ID while it is pending ack >causes the seq. num to bump up and the union of the >old and new states is sent out. Once the latest >Message ID is acked, the Message ID can be deleted. >(Note this is a deviation from my original proposal. >Now Message ID is being used only for acking). > >3)Snooping: On demand request for states was >mentioned. But if we are going to refresh at sometime, >even if it is an hour, we dont need this. > >Is there anything else I have missed? Comments? > >Suresh > >_______________________________________________ >Pim-state mailing list >Pim-state@mountain2sea.com >http://www.mountain2sea.com/mailman/listinfo/pim-state From rkebler@avici.com Fri Feb 25 14:03:03 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j1PJ30Se091580 for ; Fri, 25 Feb 2005 14:03:01 -0500 (EST) (envelope-from rkebler@avici.com) Received: from rkebler-pc (rkebler-pc.avici.com [10.2.20.48]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id j1PJ2h7l029769 for ; Fri, 25 Feb 2005 14:02:45 -0500 Message-Id: <4.2.0.58.20050225140719.00d98710@mailhost.avici.com> X-Sender: rkebler@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 25 Feb 2005 14:11:41 -0500 To: pim-state@mountain2sea.com From: Robert Kebler Subject: Re: [Pim-state] Summary Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 25 Feb 2005 19:03:03 -0000 Is there any interest to meet together in person in Minnesota to try to resolve any issues we have? I think this would be very productive. -Bob >Date: Mon, 07 Feb 2005 14:07:19 -0500 >To: pim-state@mountain2sea.com >From: Robert Kebler >Subject: Re: [Pim-state] Summary > >Here are my opinions on the topics which have been discussed: > >I think we should use the existing JP messages to refresh the state. >I think it is really up to the implementation what to use as a default >holdtime (no inter-operability issues) and the user to decide what to >configure. If we really want to give a default, then I would say >MAX_HOLDTIME. > >I like the idea of having some sort of "Sequence Number" or >"Message ID" to Acknowledge. I think the best idea is to have >a separate spec that gives a generic method of encoding a TLV >at the end of a JP message. The first application of this will be >to encode a "Message ID" in the JP message. I don't see the >need to have both a Message ID and Sequence Number. All >we really need is one 32-bit number. > >I think we need a method to request JP state. If we are going to allow >no refreshes at all, I think it makes sense that we have some way of >requesting JP State. > >I like Explicit Tracking. If we do Explicit Tracking then a downstream router >does not always need to parse the JP messages intended for another router. > >-Bob > > >At 03:14 PM 2/4/05 -0800, Suresh Boddapati wrote: >>Trying to summarize the discussions that we had so far >>on the list: >> >>1) To refresh or not: It seems like it is acceptable >>to most of us to live with refreshes if refreshes are >>done at a large interval (an hour or more). Adding >>reliability gives the flexibility to do refreshes at >>large intervals (assuming the intervals are jittered >>so that all states do not refresh at the same time). >>Using the existing JP messages to refresh instead of >>using a new PDU Type seems to be acceptable as well. >>Users can tweak the holdtime to get the refresh >>behavior they desire. >> >>2) How to achieve reliability: Everyone agrees there >>should be an ACK mechanism. There are two schemes >>here: >>a) Dino's scheme: Have a bit per state, the intended >>recipient turns back the JP PDU into a new PDU type >>and does the Acking. Back to back changes to a state >>was pointed out as an issue. Dino's take is we could >>use the Reserved field in the JP PDU and use it as seq >>num. >>b) Use a Message ID TLV for Acking. The TLV has a >>sequence number, and is sent along with the JP PDU. >>The intended recipient acks using the Message ID TLV >>in a new PDU type. Back to back changes to states >>corresponding to a Message ID while it is pending ack >>causes the seq. num to bump up and the union of the >>old and new states is sent out. Once the latest >>Message ID is acked, the Message ID can be deleted. >>(Note this is a deviation from my original proposal. >>Now Message ID is being used only for acking). >> >>3)Snooping: On demand request for states was >>mentioned. But if we are going to refresh at sometime, >>even if it is an hour, we dont need this. >> >>Is there anything else I have missed? Comments? >> >>Suresh >> >>_______________________________________________ >>Pim-state mailing list >>Pim-state@mountain2sea.com >>http://www.mountain2sea.com/mailman/listinfo/pim-state From pusateri@juniper.net Fri Feb 25 16:52:18 2005 Received: from colo-dns-ext2.juniper.net (colo-dns-ext2.juniper.net [207.17.137.64]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j1PLqH8n091836 for ; Fri, 25 Feb 2005 16:52:18 -0500 (EST) (envelope-from pusateri@juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j1PLq1Bm040115; Fri, 25 Feb 2005 13:52:01 -0800 (PST) (envelope-from pusateri@juniper.net) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j1PLpte80165; Fri, 25 Feb 2005 13:51:55 -0800 (PST) (envelope-from pusateri@juniper.net) Message-Id: <200502252151.j1PLpte80165@merlot.juniper.net> To: Robert Kebler Subject: Re: [Pim-state] Summary In-Reply-To: Message from Robert Kebler of "Fri, 25 Feb 2005 14:11:41 EST." <4.2.0.58.20050225140719.00d98710@mailhost.avici.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <89758.1109368314.1@juniper.net> Date: Fri, 25 Feb 2005 13:51:54 -0800 From: Tom Pusateri Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 25 Feb 2005 21:52:18 -0000 Yes. This is a good idea. Is anyone willing to summarize the current state of things (pun intended) with a few slides to the working group? Tom In message <4.2.0.58.20050225140719.00d98710@mailhost.avici.com> you write: >Is there any interest to meet together in person in Minnesota to try >to resolve any issues we have? I think this would be very productive. > >-Bob > > > >>Date: Mon, 07 Feb 2005 14:07:19 -0500 >>To: pim-state@mountain2sea.com >>From: Robert Kebler >>Subject: Re: [Pim-state] Summary >> >>Here are my opinions on the topics which have been discussed: >> >>I think we should use the existing JP messages to refresh the state. >>I think it is really up to the implementation what to use as a default >>holdtime (no inter-operability issues) and the user to decide what to >>configure. If we really want to give a default, then I would say >>MAX_HOLDTIME. >> >>I like the idea of having some sort of "Sequence Number" or >>"Message ID" to Acknowledge. I think the best idea is to have >>a separate spec that gives a generic method of encoding a TLV >>at the end of a JP message. The first application of this will be >>to encode a "Message ID" in the JP message. I don't see the >>need to have both a Message ID and Sequence Number. All >>we really need is one 32-bit number. >> >>I think we need a method to request JP state. If we are going to allow >>no refreshes at all, I think it makes sense that we have some way of >>requesting JP State. >> >>I like Explicit Tracking. If we do Explicit Tracking then a downstream route >r >>does not always need to parse the JP messages intended for another router. >> >>-Bob >> >> >>At 03:14 PM 2/4/05 -0800, Suresh Boddapati wrote: >>>Trying to summarize the discussions that we had so far >>>on the list: >>> >>>1) To refresh or not: It seems like it is acceptable >>>to most of us to live with refreshes if refreshes are >>>done at a large interval (an hour or more). Adding >>>reliability gives the flexibility to do refreshes at >>>large intervals (assuming the intervals are jittered >>>so that all states do not refresh at the same time). >>>Using the existing JP messages to refresh instead of >>>using a new PDU Type seems to be acceptable as well. >>>Users can tweak the holdtime to get the refresh >>>behavior they desire. >>> >>>2) How to achieve reliability: Everyone agrees there >>>should be an ACK mechanism. There are two schemes >>>here: >>>a) Dino's scheme: Have a bit per state, the intended >>>recipient turns back the JP PDU into a new PDU type >>>and does the Acking. Back to back changes to a state >>>was pointed out as an issue. Dino's take is we could >>>use the Reserved field in the JP PDU and use it as seq >>>num. >>>b) Use a Message ID TLV for Acking. The TLV has a >>>sequence number, and is sent along with the JP PDU. >>>The intended recipient acks using the Message ID TLV >>>in a new PDU type. Back to back changes to states >>>corresponding to a Message ID while it is pending ack >>>causes the seq. num to bump up and the union of the >>>old and new states is sent out. Once the latest >>>Message ID is acked, the Message ID can be deleted. >>>(Note this is a deviation from my original proposal. >>>Now Message ID is being used only for acking). >>> >>>3)Snooping: On demand request for states was >>>mentioned. But if we are going to refresh at sometime, >>>even if it is an hour, we dont need this. >>> >>>Is there anything else I have missed? Comments? >>> >>>Suresh >>> >>>_______________________________________________ >>>Pim-state mailing list >>>Pim-state@mountain2sea.com >>>http://www.mountain2sea.com/mailman/listinfo/pim-state > >_______________________________________________ >Pim-state mailing list >Pim-state@mountain2sea.com >http://www.mountain2sea.com/mailman/listinfo/pim-state From dino@dino-lnx.cisco.com Fri Feb 25 17:29:10 2005 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j1PMTAcr091904 for ; Fri, 25 Feb 2005 17:29:10 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 25 Feb 2005 14:29:54 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,118,1107763200"; d="scan'208"; a="163838100:sNHT16277602" Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1PMT2YO016238; Fri, 25 Feb 2005 14:29:03 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j1PMT2wb011636; Fri, 25 Feb 2005 14:29:02 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j1PMT2sn011632; Fri, 25 Feb 2005 14:29:02 -0800 Date: Fri, 25 Feb 2005 14:29:02 -0800 Message-Id: <200502252229.j1PMT2sn011632@dino-lnx.cisco.com> From: Dino Farinacci To: pusateri@juniper.net In-reply-to: <200502252151.j1PLpte80165@merlot.juniper.net> (message from Tom Pusateri on Fri, 25 Feb 2005 13:51:54 -0800) Subject: Re: [Pim-state] Summary References: <200502252151.j1PLpte80165@merlot.juniper.net> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 25 Feb 2005 22:29:14 -0000 >> Yes. This is a good idea. Is anyone willing to summarize the current >> state of things (pun intended) with a few slides to the working group? Since I won't be ablt to attend the IETF, I will brief some of the cisco guys. I think Mike (and you) were suppose to present that. Dino From suresh.boddapati@alcatel.com Fri Feb 25 17:54:51 2005 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j1PMspM2091947 for ; Fri, 25 Feb 2005 17:54:51 -0500 (EST) (envelope-from suresh.boddapati@alcatel.com) Received: from alcatelxp ([172.22.187.74] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 25 Feb 2005 14:54:38 -0800 From: "Suresh Boddapati" To: "'Tom Pusateri'" , "'Robert Kebler'" Subject: RE: [Pim-state] Summary Date: Fri, 25 Feb 2005 14:54:51 -0800 Organization: Alcatel USA Message-ID: <027101c51b8d$0656d5e0$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <200502252151.j1PLpte80165@merlot.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 25 Feb 2005 22:54:38.0590 (UTC) FILETIME=[FBECD1E0:01C51B8C] Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: suresh.boddapati@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Fri, 25 Feb 2005 22:54:52 -0000 I will try to make some slides with the summary and send it out to the list. I am not sure if I am going to Minnesota yet. Either way, there will be some Alcatel representation. Is this meeting separate from the design team progress presentation that Tom/Mike are making? I will try to get the slides out to the group sometime next week. Suresh > -----Original Message----- > From: pim-state-bounces@mountain2sea.com [mailto:pim-state- > bounces@mountain2sea.com] On Behalf Of Tom Pusateri > Sent: Friday, February 25, 2005 1:52 PM > To: Robert Kebler > Cc: pim-state@mountain2sea.com > Subject: Re: [Pim-state] Summary > > Yes. This is a good idea. Is anyone willing to summarize the current > state of things (pun intended) with a few slides to the working group? > > Tom > > In message <4.2.0.58.20050225140719.00d98710@mailhost.avici.com> you > write: > >Is there any interest to meet together in person in Minnesota to try > >to resolve any issues we have? I think this would be very productive. > > > >-Bob > > > > > > > >>Date: Mon, 07 Feb 2005 14:07:19 -0500 > >>To: pim-state@mountain2sea.com > >>From: Robert Kebler > >>Subject: Re: [Pim-state] Summary > >> > >>Here are my opinions on the topics which have been discussed: > >> > >>I think we should use the existing JP messages to refresh the state. > >>I think it is really up to the implementation what to use as a default > >>holdtime (no inter-operability issues) and the user to decide what to > >>configure. If we really want to give a default, then I would say > >>MAX_HOLDTIME. > >> > >>I like the idea of having some sort of "Sequence Number" or > >>"Message ID" to Acknowledge. I think the best idea is to have > >>a separate spec that gives a generic method of encoding a TLV > >>at the end of a JP message. The first application of this will be > >>to encode a "Message ID" in the JP message. I don't see the > >>need to have both a Message ID and Sequence Number. All > >>we really need is one 32-bit number. > >> > >>I think we need a method to request JP state. If we are going to allow > >>no refreshes at all, I think it makes sense that we have some way of > >>requesting JP State. > >> > >>I like Explicit Tracking. If we do Explicit Tracking then a downstream > route > >r > >>does not always need to parse the JP messages intended for another > router. > >> > >>-Bob > >> > >> > >>At 03:14 PM 2/4/05 -0800, Suresh Boddapati wrote: > >>>Trying to summarize the discussions that we had so far > >>>on the list: > >>> > >>>1) To refresh or not: It seems like it is acceptable > >>>to most of us to live with refreshes if refreshes are > >>>done at a large interval (an hour or more). Adding > >>>reliability gives the flexibility to do refreshes at > >>>large intervals (assuming the intervals are jittered > >>>so that all states do not refresh at the same time). > >>>Using the existing JP messages to refresh instead of > >>>using a new PDU Type seems to be acceptable as well. > >>>Users can tweak the holdtime to get the refresh > >>>behavior they desire. > >>> > >>>2) How to achieve reliability: Everyone agrees there > >>>should be an ACK mechanism. There are two schemes > >>>here: > >>>a) Dino's scheme: Have a bit per state, the intended > >>>recipient turns back the JP PDU into a new PDU type > >>>and does the Acking. Back to back changes to a state > >>>was pointed out as an issue. Dino's take is we could > >>>use the Reserved field in the JP PDU and use it as seq > >>>num. > >>>b) Use a Message ID TLV for Acking. The TLV has a > >>>sequence number, and is sent along with the JP PDU. > >>>The intended recipient acks using the Message ID TLV > >>>in a new PDU type. Back to back changes to states > >>>corresponding to a Message ID while it is pending ack > >>>causes the seq. num to bump up and the union of the > >>>old and new states is sent out. Once the latest > >>>Message ID is acked, the Message ID can be deleted. > >>>(Note this is a deviation from my original proposal. > >>>Now Message ID is being used only for acking). > >>> > >>>3)Snooping: On demand request for states was > >>>mentioned. But if we are going to refresh at sometime, > >>>even if it is an hour, we dont need this. > >>> > >>>Is there anything else I have missed? Comments? > >>> > >>>Suresh > >>> > >>>_______________________________________________ > >>>Pim-state mailing list > >>>Pim-state@mountain2sea.com > >>>http://www.mountain2sea.com/mailman/listinfo/pim-state > > > >_______________________________________________ > >Pim-state mailing list > >Pim-state@mountain2sea.com > >http://www.mountain2sea.com/mailman/listinfo/pim-state > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state From mmcbride@cisco.com Sat Feb 26 01:27:36 2005 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j1Q6RZWV092643 for ; Sat, 26 Feb 2005 01:27:35 -0500 (EST) (envelope-from mmcbride@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 25 Feb 2005 23:42:31 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,118,1107734400"; d="scan'208"; a="229491054:sNHT22534076" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1Q6RIq8017368; Fri, 25 Feb 2005 22:27:19 -0800 (PST) Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BCF06086; Fri, 25 Feb 2005 22:27:24 -0800 (PST) Date: Fri, 25 Feb 2005 22:27:24 -0800 (PST) From: Mike McBride To: Suresh Boddapati Subject: RE: [Pim-state] Summary In-Reply-To: <027101c51b8d$0656d5e0$4abb16ac@alcatelxp> Message-ID: References: <027101c51b8d$0656d5e0$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Sat, 26 Feb 2005 06:27:36 -0000 A few slides would be appreciated. You've already come up with a good summary of the brainstorming you've done on this list. I think we can say we've done due diligence to come up with a few solutions to pim refresh reduction if its deemed necessary. Tom and I can give an update during the pim wg. But at this point we should probably keep this between the wg chairs. After emails from Tom and I to the l3vpn wg chairs, we still haven't heard back from them on what exactly they want us to accomplish with refresh reduction. They need to give us clear requirements, rather than simply state pim wg needs to solve the pim refresh problem. What problem? Once we understand the requirements, we can decide if we should start submitting drafts (if an ACK mechanism is the way to go, if we need a more robust TCP solution, etc) or if pimv2 is fine as is. thanks, mike On Fri, 25 Feb 2005, Suresh Boddapati wrote: > I will try to make some slides with the summary and send it out to the > list. > I am not sure if I am going to Minnesota yet. Either way, there will be > some Alcatel representation. Is this meeting separate from the design > team progress presentation that Tom/Mike are making? > > I will try to get the slides out to the group sometime next week. > > Suresh > > > -----Original Message----- > > From: pim-state-bounces@mountain2sea.com [mailto:pim-state- > > bounces@mountain2sea.com] On Behalf Of Tom Pusateri > > Sent: Friday, February 25, 2005 1:52 PM > > To: Robert Kebler > > Cc: pim-state@mountain2sea.com > > Subject: Re: [Pim-state] Summary > > > > Yes. This is a good idea. Is anyone willing to summarize the current > > state of things (pun intended) with a few slides to the working group? > > > > Tom > > > > In message <4.2.0.58.20050225140719.00d98710@mailhost.avici.com> you > > write: > > >Is there any interest to meet together in person in Minnesota to try > > >to resolve any issues we have? I think this would be very > productive. > > > > > >-Bob > > > > > > > > > > > >>Date: Mon, 07 Feb 2005 14:07:19 -0500 > > >>To: pim-state@mountain2sea.com > > >>From: Robert Kebler > > >>Subject: Re: [Pim-state] Summary > > >> > > >>Here are my opinions on the topics which have been discussed: > > >> > > >>I think we should use the existing JP messages to refresh the state. > > >>I think it is really up to the implementation what to use as a > default > > >>holdtime (no inter-operability issues) and the user to decide what > to > > >>configure. If we really want to give a default, then I would say > > >>MAX_HOLDTIME. > > >> > > >>I like the idea of having some sort of "Sequence Number" or > > >>"Message ID" to Acknowledge. I think the best idea is to have > > >>a separate spec that gives a generic method of encoding a TLV > > >>at the end of a JP message. The first application of this will be > > >>to encode a "Message ID" in the JP message. I don't see the > > >>need to have both a Message ID and Sequence Number. All > > >>we really need is one 32-bit number. > > >> > > >>I think we need a method to request JP state. If we are going to > allow > > >>no refreshes at all, I think it makes sense that we have some way of > > >>requesting JP State. > > >> > > >>I like Explicit Tracking. If we do Explicit Tracking then a > downstream > > route > > >r > > >>does not always need to parse the JP messages intended for another > > router. > > >> > > >>-Bob > > >> > > >> > > >>At 03:14 PM 2/4/05 -0800, Suresh Boddapati wrote: > > >>>Trying to summarize the discussions that we had so far > > >>>on the list: > > >>> > > >>>1) To refresh or not: It seems like it is acceptable > > >>>to most of us to live with refreshes if refreshes are > > >>>done at a large interval (an hour or more). Adding > > >>>reliability gives the flexibility to do refreshes at > > >>>large intervals (assuming the intervals are jittered > > >>>so that all states do not refresh at the same time). > > >>>Using the existing JP messages to refresh instead of > > >>>using a new PDU Type seems to be acceptable as well. > > >>>Users can tweak the holdtime to get the refresh > > >>>behavior they desire. > > >>> > > >>>2) How to achieve reliability: Everyone agrees there > > >>>should be an ACK mechanism. There are two schemes > > >>>here: > > >>>a) Dino's scheme: Have a bit per state, the intended > > >>>recipient turns back the JP PDU into a new PDU type > > >>>and does the Acking. Back to back changes to a state > > >>>was pointed out as an issue. Dino's take is we could > > >>>use the Reserved field in the JP PDU and use it as seq > > >>>num. > > >>>b) Use a Message ID TLV for Acking. The TLV has a > > >>>sequence number, and is sent along with the JP PDU. > > >>>The intended recipient acks using the Message ID TLV > > >>>in a new PDU type. Back to back changes to states > > >>>corresponding to a Message ID while it is pending ack > > >>>causes the seq. num to bump up and the union of the > > >>>old and new states is sent out. Once the latest > > >>>Message ID is acked, the Message ID can be deleted. > > >>>(Note this is a deviation from my original proposal. > > >>>Now Message ID is being used only for acking). > > >>> > > >>>3)Snooping: On demand request for states was > > >>>mentioned. But if we are going to refresh at sometime, > > >>>even if it is an hour, we dont need this. > > >>> > > >>>Is there anything else I have missed? Comments? > > >>> > > >>>Suresh > > >>> > > >>>_______________________________________________ > > >>>Pim-state mailing list > > >>>Pim-state@mountain2sea.com > > >>>http://www.mountain2sea.com/mailman/listinfo/pim-state > > > > > >_______________________________________________ > > >Pim-state mailing list > > >Pim-state@mountain2sea.com > > >http://www.mountain2sea.com/mailman/listinfo/pim-state > > _______________________________________________ > > Pim-state mailing list > > Pim-state@mountain2sea.com > > http://www.mountain2sea.com/mailman/listinfo/pim-state > > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state > From suresh.boddapati@alcatel.com Mon Feb 28 18:16:41 2005 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j1SNGexR099511 for ; Mon, 28 Feb 2005 18:16:40 -0500 (EST) (envelope-from suresh.boddapati@alcatel.com) Received: from alcatelxp ([172.22.187.74] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 28 Feb 2005 15:16:29 -0800 From: "Suresh Boddapati" To: "'Mike McBride'" Subject: RE: [Pim-state] Summary Date: Mon, 28 Feb 2005 15:16:54 -0800 Organization: Alcatel USA Message-ID: <02cc01c51deb$988bb560$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_02CD_01C51DA8.8A687560" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 28 Feb 2005 23:16:29.0899 (UTC) FILETIME=[88C3F1B0:01C51DEB] Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: suresh.boddapati@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 28 Feb 2005 23:16:48 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02CD_01C51DA8.8A687560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Here are the slides I promised. I have summarized the progress made so far. Please feel free to make any edits as you deem necessary. I wont be attending the IETF meet this time. I look forward to the minutes. Suresh > -----Original Message----- > From: Mike McBride [mailto:mmcbride@cisco.com] > Sent: Friday, February 25, 2005 10:27 PM > To: Suresh Boddapati > Cc: 'Tom Pusateri'; 'Robert Kebler'; pim-state@mountain2sea.com > Subject: RE: [Pim-state] Summary > > A few slides would be appreciated. You've already come up with a good > summary of the brainstorming you've done on this list. I think we can say > we've done due diligence to come up with a few solutions to pim refresh > reduction if its deemed necessary. Tom and I can give an update during the > pim wg. But at this point we should probably keep this between the wg > chairs. After emails from Tom and I to the l3vpn wg chairs, we still > haven't heard back from them on what exactly they want us to accomplish > with refresh reduction. They need to give us clear requirements, rather > than simply state pim wg needs to solve the pim refresh problem. What > problem? Once we understand the requirements, we can decide if we should > start submitting drafts (if an ACK mechanism is the way to go, if we need > a more robust TCP solution, etc) or if pimv2 is fine as is. > > thanks, > mike > > On Fri, 25 Feb 2005, Suresh Boddapati wrote: > > > I will try to make some slides with the summary and send it out to the > > list. > > I am not sure if I am going to Minnesota yet. Either way, there will be > > some Alcatel representation. Is this meeting separate from the design > > team progress presentation that Tom/Mike are making? > > > > I will try to get the slides out to the group sometime next week. > > > > Suresh > > > > > -----Original Message----- > > > From: pim-state-bounces@mountain2sea.com [mailto:pim-state- > > > bounces@mountain2sea.com] On Behalf Of Tom Pusateri > > > Sent: Friday, February 25, 2005 1:52 PM > > > To: Robert Kebler > > > Cc: pim-state@mountain2sea.com > > > Subject: Re: [Pim-state] Summary > > > > > > Yes. This is a good idea. Is anyone willing to summarize the current > > > state of things (pun intended) with a few slides to the working group? > > > > > > Tom > > > > > > In message <4.2.0.58.20050225140719.00d98710@mailhost.avici.com> you > > > write: > > > >Is there any interest to meet together in person in Minnesota to try > > > >to resolve any issues we have? I think this would be very > > productive. > > > > > > > >-Bob > > > > > > > > > > > > > > > >>Date: Mon, 07 Feb 2005 14:07:19 -0500 > > > >>To: pim-state@mountain2sea.com > > > >>From: Robert Kebler > > > >>Subject: Re: [Pim-state] Summary > > > >> > > > >>Here are my opinions on the topics which have been discussed: > > > >> > > > >>I think we should use the existing JP messages to refresh the state. > > > >>I think it is really up to the implementation what to use as a > > default > > > >>holdtime (no inter-operability issues) and the user to decide what > > to > > > >>configure. If we really want to give a default, then I would say > > > >>MAX_HOLDTIME. > > > >> > > > >>I like the idea of having some sort of "Sequence Number" or > > > >>"Message ID" to Acknowledge. I think the best idea is to have > > > >>a separate spec that gives a generic method of encoding a TLV > > > >>at the end of a JP message. The first application of this will be > > > >>to encode a "Message ID" in the JP message. I don't see the > > > >>need to have both a Message ID and Sequence Number. All > > > >>we really need is one 32-bit number. > > > >> > > > >>I think we need a method to request JP state. If we are going to > > allow > > > >>no refreshes at all, I think it makes sense that we have some way of > > > >>requesting JP State. > > > >> > > > >>I like Explicit Tracking. If we do Explicit Tracking then a > > downstream > > > route > > > >r > > > >>does not always need to parse the JP messages intended for another > > > router. > > > >> > > > >>-Bob > > > >> > > > >> > > > >>At 03:14 PM 2/4/05 -0800, Suresh Boddapati wrote: > > > >>>Trying to summarize the discussions that we had so far > > > >>>on the list: > > > >>> > > > >>>1) To refresh or not: It seems like it is acceptable > > > >>>to most of us to live with refreshes if refreshes are > > > >>>done at a large interval (an hour or more). Adding > > > >>>reliability gives the flexibility to do refreshes at > > > >>>large intervals (assuming the intervals are jittered > > > >>>so that all states do not refresh at the same time). > > > >>>Using the existing JP messages to refresh instead of > > > >>>using a new PDU Type seems to be acceptable as well. > > > >>>Users can tweak the holdtime to get the refresh > > > >>>behavior they desire. > > > >>> > > > >>>2) How to achieve reliability: Everyone agrees there > > > >>>should be an ACK mechanism. There are two schemes > > > >>>here: > > > >>>a) Dino's scheme: Have a bit per state, the intended > > > >>>recipient turns back the JP PDU into a new PDU type > > > >>>and does the Acking. Back to back changes to a state > > > >>>was pointed out as an issue. Dino's take is we could > > > >>>use the Reserved field in the JP PDU and use it as seq > > > >>>num. > > > >>>b) Use a Message ID TLV for Acking. The TLV has a > > > >>>sequence number, and is sent along with the JP PDU. > > > >>>The intended recipient acks using the Message ID TLV > > > >>>in a new PDU type. Back to back changes to states > > > >>>corresponding to a Message ID while it is pending ack > > > >>>causes the seq. num to bump up and the union of the > > > >>>old and new states is sent out. Once the latest > > > >>>Message ID is acked, the Message ID can be deleted. > > > >>>(Note this is a deviation from my original proposal. > > > >>>Now Message ID is being used only for acking). > > > >>> > > > >>>3)Snooping: On demand request for states was > > > >>>mentioned. But if we are going to refresh at sometime, > > > >>>even if it is an hour, we dont need this. > > > >>> > > > >>>Is there anything else I have missed? Comments? > > > >>> > > > >>>Suresh > > > >>> > > > >>>_______________________________________________ > > > >>>Pim-state mailing list > > > >>>Pim-state@mountain2sea.com > > > >>>http://www.mountain2sea.com/mailman/listinfo/pim-state > > > > > > > >_______________________________________________ > > > >Pim-state mailing list > > > >Pim-state@mountain2sea.com > > > >http://www.mountain2sea.com/mailman/listinfo/pim-state > > > _______________________________________________ > > > Pim-state mailing list > > > Pim-state@mountain2sea.com > > > http://www.mountain2sea.com/mailman/listinfo/pim-state > > > > _______________________________________________ > > Pim-state mailing list > > Pim-state@mountain2sea.com > > http://www.mountain2sea.com/mailman/listinfo/pim-state > > ------=_NextPart_000_02CD_01C51DA8.8A687560 Content-Type: application/vnd.ms-powerpoint; name="RefreshReduction.ppt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="RefreshReduction.ppt" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAARAAAAAAAAAAA EAAARgAAAAEAAAD+////AAAAAEUAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8P AOgDwRMAAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAAAAAAAAAAAAABAAAAAAAAAQ8A 8gMWAQAALwDIDwwAAAAwANIPBAAAAAEAAAAPANUHTAAAAAAAtw9EAAAAVABpAG0AZQBzACAATgBl AHcAIABSAG8AbQBhAG4AAABIJ9EAtNUTAJzVEwB2xwswCAAAAAAAAAC01RMAKN0NMAAABAAAAKQP CgAAAIAAYAAAAP////8AAKUPDAAAAAAAAAguAAAABwAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9u AAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAABwAAAP//7wAAAAAA//////// GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAP AAsErAAAAA8AAPCkAAAAAAAG8FgAAAACKAAACgAAABsAAAAIAAAAAQAAAAcAAAADAAAABAAAAAQA AAAEAAAABQAAAAQAAAAGAAAABAAAAAAAAAAEAAAABwAAAAQAAAAIAAAABAAAAAIAAAAEAAAAYwAL 8CQAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAhAAB7xEAAAAAQAAAgBAAAI AgAACPcAABAfAPAPHAAAAAAA8wMUAAAAAgAAAAAAAAAAAAAAAAAAgAAAAAAPANAHNwEAAB8AFAQc AAAAAAAVBBQAAAC6HXXsAMqaOzJOzckAypo7AQEAAQ8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAA AEMAAABkAAAAQwAAAGQAAAB2xwswCAAAAAAAAACo1RMAAAAAAAAAAACs////Lv///wEAAABwAPsD CAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8ABwQ8AAAAAAD9AzQAAAAhAAAAZAAAACEAAABk AAAAYPMNMGTZEwAAAAAANCjRAAAAAAAAAAAAAAAAAAAAAAAAARMAHwATBDwAAAAAAP0DNAAAAGQA AABkAAAAZAAAAGQAAABg8w0wZNkTAAAAAAA0KNEAAAAAAAAAAAAAAAAAAAAAAAABEwAfAP8DFAAA AAIAAAQMAAAAAAAAAAAAAAACAAAADwDwD0wQAAAAAPMDFAAAAAMAAAAAAAAAAgAAAAABAAAAAAAA AACfDwQAAAAAAAAAAACoDwgAAABQcm9ibGVtIBAAnw8EAAAAAQAAAAAAqA90AQAAUElNIEpvaW5z IGFyZSByZWZyZXNoZWQgZXZlcnkgNjAgc2Vjb25kcyBieSBhIGRvd25zdHJlYW0gcm91dGVyIHRv IGtlZXAgbXVsdGljYXN0IHN0YXRlIGFsaXZlIGF0IHRoZSB1cHN0cmVhbSByb3V0ZXIuDVRoZSBt b3JlIHRoZSBudW1iZXIgb2Ygc3RhdGVzLCB0aGUgbW9yZSB0aGUgY29udHJvbCB0cmFmZmljIHJl cXVpcmVkIGZvciByZWZyZXNoLiANU2NhbGluZyBiZWNvbWVzIGFuIGlzc3VlIGVzcGVjaWFsbHkg d2l0aCBWUE5zIChlLmcuIDEwMDAgVlBOcyB3aXRoIDEwMCBlbnRyaWVzIGVhY2ggYW5kIDEwIGRv d25zdHJlYW0gaW50ZXJmYWNlcyA9IDFtaWxsaW9uIHN0YXRlIHJlZnJlc2hlcyBldmVyeSBtaW51 dGUgaW4gc3RlYWR5IHN0YXRlKS4NAAChDxQAAAB1AQAAAAAAAAAAdQEAAAAAAgAcAAAAqg8sAAAA 8gAAAAAAAAAFAAAAAQAAAAMACwAAAAAAAAAFAAAAAQAAAAMAbgAAAAAAAAAAAPMDFAAAAAQAAAAA AAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDxAAAABQcm9ibGVtIChjb250ZC4pEACfDwQA AAABAAAAAACoD08BAABSb3V0ZSBjaGFuZ2VzIGNhdXNlIEpvaW5zIHRvIGJlIHNlbnQgdG8gdGhl IG5ldyBSUEYgbmJyLiBJZiB0aGUgSm9pbiBnZXRzIGxvc3QsIHRoZSBkaXNydXB0aW9uIG9mIHRy YWZmaWMgaXMgZm9yIGF0IGxlYXN0IGEgbWludXRlLg1ObyByZWxpYWJpbGl0eSBpbiB0aGUgSm9p bi9QcnVuZSBFeGNoYW5nZSBiZXR3ZWVuIGRvd25zdHJlYW0gYW5kIHVwc3RyZWFtIHJvdXRlcnMu DUxhcmdlciB2YWx1ZXMgb2YgaG9sZHRpbWUgaW4gdGhlIEpQIFBEVSB3aWxsIHJlZHVjZSB0aGUg ZnJlcXVlbmN5IG9mIHJlZnJlc2hlcywgYnV0IGNhbiBjYXVzZSBsYXJnZXIgY29udmVyZ2VuY2Ug ZGVsYXlzLgAAoQ8UAAAAUAEAAAAAABAAAFoAUAEAAAAAAAAAAKoPLAAAADQAAAAAAAAAAwAAAAEA AAADALAAAAAAAAAACQAAAAEAAAADAGAAAAAAAAAAAADzAxQAAAAFAAAAAAAAAAIAAAACAQAAAAAA AAAAnw8EAAAAAAAAAAAAqA8gAAAAV2h5IG5vdCB1c2UgVENQIGZvciByZWxpYWJpbGl0eT8QAJ8P BAAAAAEAAAAAAKAP9AEAAEMAYQBuAG4AbwB0ACAAaABhAHYAZQAgAEoAbwBpAG4AIABzAHUAcABw AHIAZQBzAHMAaQBvAG4ALAAgAG0AYQBrAGkAbgBnACAAdABoAGUAIABwAHIAbwBiAGwAZQBtACAA cABvAHQAZQBuAHQAaQBhAGwAbAB5ACAAdwBvAHIAcwBlACAAKABhAGwAbAAgAGQAbwB3AG4AcwB0 AHIAZQBhAG0AIAByAG8AdQB0AGUAcgBzACAAYwBvAHUAbABkACAAcwBlAG4AZAAgAHQAaABlAGkA cgAgAEoAbwBpAG4AcwAgAGEAdAAgAGEAYgBvAHUAdAAgAHQAaABlACAAcwBhAG0AZQAgAHQAaQBt AGUALAAgAG0AdQBsAHQAaQBwAGwAeQBpAG4AZwAgAHQAaABlACAAdABvAHQAYQBsACAAYQBtAG8A dQBuAHQAIABvAGYAIAB0AHIAYQBmAGYAaQBjACAAcgBlAGMAZQBpAHYAZQBkACAAYQB0ACAAdABo AGUAIAB1AHAAcwB0AHIAZQBhAG0AIAByAG8AdQB0AGUAcgApAC4ADQBTAG4AbwBvAHAAaQBuAGcA IAAoAGIAeQAgAEwAMgAgAHMAdwBpAHQAYwBoAGUAcwApACAAdwBvAG4AGSB0ACAAdwBvAHIAawAu AA0AAADzAxQAAAAHAAAAAAAAAAIAAAADAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8IAAAAU29sdXRp b24QAJ8PBAAAAAEAAAAAAKgPlQEAAElmIEpQIEV4Y2hhbmdlIGlzIG1hZGUgcmVsaWFibGUsIHRo ZSByZWZyZXNoIGludGVydmFsIGNhbiBiZSBtYWRlIGxhcmdlciAoNjAgbWludXRlcykuDVVzZSBh IG5ldyBKUCBBY2sgUERVLCB3aGljaCBhbiB1cHN0cmVhbSByb3V0ZXIgd2lsbCBzZW5kIHRvIHRo ZSBkb3duc3RyZWFtIHJvdXRlciwgdG8gYWNrbm93bGVkZ2UgcmVjZWlwdCBvZiBhIEpQIFBEVS4N RG93bnN0cmVhbSByb3V0ZXJzIHdpbGwgcmV0cmFuc21pdCBKUCBQRFVzIHVudGlsIHRoZXkgYXJl IGFja2VkLg1SZXRyYW5zbWlzc2lvbnMgYXJlIGV4cG9uZW50aWFsbHkgYmFja2VkIG9mZiBhbmQg Y2FwcGVkIGF0IHRoZSByZWd1bGFyIHJlZnJlc2ggaW50ZXJ2YWwuDVN0YXRlIHVwZGF0ZXMgYWxs b3dlZCB3aGlsZSBBQ0tzIGFyZSBwZW5kaW5nLgAAoQ8WAAAAlgEAAAAAABAAAFoAlgEAAAAAAgAc AAAAqg9QAAAAZAAAAAAAAAAEAAAAAQAAAAMAjAAAAAAAAAAFAAAAAQAAAAMADwAAAAAAAAAFAAAA AQAAAAMAdwAAAAAAAAAFAAAAAQAAAAMADQAAAAAAAAAAAPMDFAAAAAgAAAAAAAAAAgAAAAQBAAAA AAAAAACfDwQAAAAAAAAAAACoDxcAAABBY2tub3dsZWRnZW1lbnQgc2NoZW1lcxAAnw8EAAAAAQAA AAAAoA8gAgAARABpAG4AbwAZIHMAIABzAGMAaABlAG0AZQA6AA0AVABoAGUAIAB1AHAAcwB0AHIA ZQBhAG0AIAByAG8AdQB0AGUAcgAgAG0AbwBkAGkAZgBpAGUAcwAgAHQAaABlACAAdAB5AHAAZQAg AG8AZgAgAHQAaABlACAAcgBlAGMAZQBpAHYAZQBkACAASgBQACAAUABEAFUAIAB0AG8AIABKAFAA IABBAEMASwAgAGEAbgBkACAAbQB1AGwAdABpAGMAYQBzAHQAcwAgAHQAaABlACAAUABEAFUAIABi AGEAYwBrACAAbwBuACAAdABoAGUAIABsAGkAbgBrACAAaQB0ACAAYQByAHIAaQB2AGUAZAAgAG8A bgAuAA0AUgBlAHMAZQByAHYAZQBkACAAZgBpAGUAbABkACAAaQBuACAAdABoAGUAIABKAFAAIABQ AEQAVQAgAHUAcwBlAGQAIABhAHMAIABhACAAcwBlAHEAdQBlAG4AYwBlACAAbgB1AG0AYgBlAHIA LAAgAHcAaABpAGMAaAAgAHQAaABlACAAZABvAHcAbgBzAHQAcgBlAGEAbQAgAHIAbwB1AHQAZQBy ACAAdQBzAGUAcwAgAHQAbwAgAGQAaQBzAHQAaQBuAGcAdQBpAHMAaAAgAGIAZQB0AHcAZQBlAG4A IABBAEMASwBzACAAZgBvAHIAIABhACAASgBQACAAUABEAFUALgANAAAAoQ84AAAADwAAAAAAAAAA AAEBAAABAAAAAAABAAAAAAAAAAAADwAAAAAAAAABAQAAAAAAAAEAAAAAAAIAGAAAAKoPGgAAAP0A AAAAAAAABQAAAAEAAAADAA8AAAAAAAAAAADzAxQAAAAJAAAAAAAAAAIAAAAFAQAAAAAAAAAAnw8E AAAAAAAAAAAAqA8XAAAAQWNrbm93bGVkZ2VtZW50IFNjaGVtZXMQAJ8PBAAAAAEAAAAAAKAP2AEA AFMAdQByAGUAcwBoABkgcwAgAHMAYwBoAGUAbQBlADoADQBUAGgAZQAgAGQAbwB3AG4AcwB0AHIA ZQBhAG0AIAByAG8AdQB0AGUAcgAgAGEAcABwAGUAbgBkAHMAIABhACAAVABMAFYAIABhAHQAIAB0 AGgAZQAgAGUAbgBkACAAbwBmACAASgBQACAAUABEAFUAIAB3AGgAaQBjAGgAIABoAGEAcwAgAGEA IAAzADIAIABiAGkAdAAgAG0AZQBzAHMAYQBnAGUAIABJAEQAIAB0AGgAYQB0ACAAaQBkAGUAbgB0 AGkAZgBpAGUAcwAgAGUAdgBlAHIAeQAgAEoAUAAgAG0AZQBzAHMAYQBnAGUAIABzAGUAbgB0ACAA YgB5ACAAaQB0AC4ADQBUAGgAZQAgAHUAcABzAHQAcgBlAGEAbQAgAHIAbwB1AHQAZQByACAAYwBv AHAAaQBlAHMAIAB0AGgAZQAgAFQATABWACAAaQBuAHQAbwAgAHQAaABlACAAQQBDAEsAIABQAEQA VQAgAGEAbgBkACAAdQBuAGkAYwBhAHMAdABzACAAaQB0ACAAYgBhAGMAawAgAHQAbwAgAHQAaABl ACAAcwBlAG4AZABlAHIALgAAAKEPJgAAABEAAAAAAAAAAADcAAAAAQAAAAAAEQAAAAAAAADcAAAA AAQAAAAEAACqDxoAAADNAAAAAAAAAAkAAAABAAAAAwAXAAAAAAAAAAAA8wMUAAAACgAAAAAAAAAC AAAABgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFwAAAFNub29waW5nIGNvbnNpZGVyYXRpb25zEACf DwQAAAABAAAAAACoD3kBAABMMiBzd2l0Y2hlcyBzbm9vcCBvbiBQSU0gSlAgUERVcyB0byBjcmVh dGUgTDIgbXVsdGljYXN0IGZvcndhcmRpbmcgc3RhdGUuDVRoZSBsYXJnZXIgdGhlIHJlZnJlc2gg aW50ZXJ2YWwsIHRoZSBsb25nZXIgaXQgd2lsbCB0YWtlIGZvciBMMiBzd2l0Y2hlcyB0byBidWls ZCBzdGF0ZS4NTDIgc3dpdGNoZXMgY291bGQgcmVxdWVzdCBkb3duc3RyZWFtIHJvdXRlcnMgdG8g cmVmcmVzaCB0aGVpciBzdGF0ZSBieSBlaXRoZXINU2VuZGluZyBvdXQgYSBQSU0gUERVIChuZXcg UERVIHR5cGUpDVNldHRpbmcgR2VuSUQgdG8gemVybyBiZWZvcmUgZm9yd2FyZGluZyBhbnkgSGVs bG8gc2VlbiBmb3IgdGhlIGZpcnN0IHRpbWUgZnJvbSBhIHJvdXRlciBvbiB0aGUgTEFOLgAAoQ8q AAAA8QAAAAAAAAAAAIkAAAABAAAAAADxAAAAAAACABwAiQAAAAAEAgAABBgAAACqDywAAAAcAAAA AAAAAAUAAAABAAAAAwD9AAAAAAAAAAYAAAABAAAAAwBWAAAAAAAAAAAA6gMAAAAADwD4A5wIAAAC AO8DGAAAAAEAAAABAgcJCAAAAAAAAAAAAAAAAAAAAGAA8AcgAAAAAAD/AP///wAAAAAA//8AAP+Z AAAA//8A/wAAAJaWlgBgAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIAYADw ByAAAAD///8AAAAAADMzMwAAAAAA3d3dAICAgABNTU0A6urqAGAA8AcgAAAA///MAAAAAABmZjMA gIAAADOZMwCAAAAAADPMAP/MZgBgAPAHIAAAAP///wAAAAAAgICAAAAAAAD/zGYAAAD/AMwAzADA wMAAYADwByAAAAD///8AAAAAAICAgAAAAAAAwMDAAABm/wD/AAAAAJkAAGAA8AcgAAAA////AAAA AACAgIAAAAAAADOZ/wCZ/8wAzADMALKysgAAAKMPPgAAAAEA//0/AAAAIiAAAGQAAAAAAAEAZAAA AAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAP///////ywAAAAAAwAAEACjD3wAAAAFAP/9PwABACIg AABkAAAAAAAAAGQAFAAAANgAAABAAgAAAAAHAAAA///vAAAAAAD///////8gAAAAAAEAAIAFAAAT INQBIAEAAAIAHACABQAAIiDQAkACAAACABgAgAUAABMg8ANgAwAAAgAUAIAFAAC7ABAFgAQAAAAA IACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAHgAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD/ //////8MAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAE AAAAAFAAow9SAAAABQAAAAEJAAAAAAEAAAAAAAAAAQABCQAAAAABACABAAAAAAIAAQkAAAAAAQBA AgAAAAADAAEJAAAAAAEAYAMAAAAABAABCQAAAAABAIAEAAAAAGAAow8MAAAAAQAAAAAAAAAAAAAA cACjDz4AAAAFAAAAAAAAAAAAAgAcAAEAAAAAAAAAAgAYAAIAAAAAAAAAAgAUAAMAAAAAAAAAAgAS AAQAAAAAAAAAAgASAIAAow8+AAAABQAAAAAAAAAAAAIAGAABAAAAAAAAAAIAFAACAAAAAAAAAAIA EgADAAAAAAAAAAIAEAAEAAAAAAAAAAIAEAAPAAwE1gQAAA8AAvDOBAAAEAAI8AgAAAAGAAAABgQA AA8AA/BmBAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAA DwAE8NIAAAASAArwCAAAAAIEAAAACgAAkwAL8DYAAAB/AAEABQCAAIhb0QCHAAEAAACBAQQAAAiD AQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMML CAAAAAAAAAABANEADwAN8FQAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFz dGVyIHRpdGxlIHN0eWxlAACiDwYAAAAhAAAAAAAAAKoPCgAAACEAAAABAAAAAAAPAATwFgEAABIA CvAIAAAAAwQAAAAKAACDAAvwMAAAAH8AAQAFAIAAOF7RAIEBBAAACIMBAAAACL8BAQARAMABAQAA CP8BAQAJAAECAgAACAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAAIA0QAPAA3w ngAAAAAAnw8EAAAAAQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMN U2Vjb25kIGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAA IQAAAAAADQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoAAABTAAAAAQAAAAAADwAE8LYAAAAS AArwCAAAAAQEAAAACgAAgwAL8DAAAAB/AAEABQCAABRj0QCBAQQAAAiDAQAAAAi/AQEAEQDAAQEA AAj/AQEACQABAgIAAAgAABDwCAAAAGAPsAFgBoAQDwAR8BAAAAAAAMMLCAAAAAIAAAAHAdEADwAN 8D4AAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAgAOAAAA +A8EAAAAAAAAAA8ABPC4AAAAEgAK8AgAAAAFBAAAAAoAAIMAC/AwAAAAfwABAAUAgACIaNEAgQEE AAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABgD7AH0A6AEA8AEfAQAAAA AADDCwgAAAADAAAACQLRAA8ADfBAAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8WAAAAAgAA AAAAAAgAAAEAAgAAAAAAAgAOAAAA+g8EAAAAAAAAAA8ABPC4AAAAEgAK8AgAAAAGBAAAAAoAAIMA C/AwAAAAfwABAAUAgABcbdEAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ 8AgAAABgDyAQ0BSAEA8AEfAQAAAAAADDCwgAAAAEAAAACALRAA8ADfBAAAAAAACfDwQAAAAEAAAA AACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgAAAIAAgAAAAAAAgAOAAAA2A8EAAAAAAAAAA8ABPBI AAAAEgAK8AgAAAABBAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA /wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKy ACAAug8cAAAARABlAGYAYQB1AGwAdAAgAEQAZQBzAGkAZwBuAA8A7gPkAQAAAgDvAxgAAAABAAAA DQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwElAEAAA8AAvCMAQAAMAAI8AgAAAADAAAAAwgAAA8AA/Ak AQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAIAAAFAAAADwAE8HIA AAASAArwCAAAAAIIAAAgAgAAUwAL8B4AAAB/AAAABACAANTd0QC/AQAAAQD/AQAAAQABAwIEAAAA ABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANANEADwAN8AwAAAAAAJ4PBAAAAAAA AAAPAATwcgAAABIACvAIAAAAAwgAACACAABTAAvwHgAAAH8AAAAEAIAAkN7RAL8BAAABAP8BAAAB AAEDAwQAAAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4A0QAPAA3wDAAAAAAA ng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABCAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGO n4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAA AMyZADMzzADMzP8AsrKyAA8A7gPkAQAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAAAAP AAwElAEAAA8AAvCMAQAAQAAI8AgAAAADAAAAAwwAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAA AAAAAAAAAAAAAAAAAAACAArwCAAAAAAMAAAFAAAADwAE8HIAAAASAArwCAAAAAIMAAAgAgAAUwAL 8B4AAAB/AAAABACAAIBsYgG/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIABsAHQFFAEDwAR8BAA AAAAAMMLCAAAAAAAAAANAGIBDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAwwA ACACAABTAAvwHgAAAH8AAAAEAIAAPG1iAb8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA4ASwAdAU AA8PABHwEAAAAAAAwwsIAAAAAQAAAA4AYgEPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK 8AgAAAABDAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgA BAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPk AQAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwElAEAAA8AAvCMAQAAUAAI8AgA AAADAAAAAxAAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAA AAAQAAAFAAAADwAE8HIAAAASAArwCAAAAAIQAAAgAgAAUwAL8B4AAAB/AAAABACAACRlYgG/AQAA AQD/AQAAAQABAwIEAAAAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAGIBDwAN 8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAxAAACACAABTAAvwHgAAAH8AAAAEAIAA zGViAb8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAA AA4AYgEPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABEAAAAAwAAIMAC/AwAAAA gQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD/ //8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPkAQAAAgDvAxgAAAABAAAADQ4AAAAA AAAAAACAAAAAAAcAAAAPAAwElAEAAA8AAvCMAQAAYAAI8AgAAAADAAAAAxQAAA8AA/AkAQAADwAE 8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAUAAAFAAAADwAE8HIAAAASAArw CAAAAAIUAAAgAgAAUwAL8B4AAAB/AAAABACAAIgsYgG/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAA AIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAGIBDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATw cgAAABIACvAIAAAAAxQAACACAABTAAvwHgAAAH8AAAAEAIAAcJNiAb8BAAABAP8BAAABAAEDAwQA AAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4AYgEPAA3wDAAAAAAAng8EAAAA AQAAAA8ABPBIAAAAEgAK8AgAAAABFAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHe vWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMz zADMzP8AsrKyAA8A7gPkAQAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwElAEA AA8AAvCMAQAAcAAI8AgAAAADAAAAAxwAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAA AAAAAAAAAAACAArwCAAAAAAcAAAFAAAADwAE8HIAAAASAArwCAAAAAIcAAAgAgAAUwAL8B4AAAB/ AAAABACAAGQyYgG/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMML CAAAAAAAAAANAGIBDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAxwAACACAABT AAvwHgAAAH8AAAAEAIAACCpiAb8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA4ASwAdAUAA8PABHw EAAAAAAAwwsIAAAAAQAAAA4AYgEPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAAB HAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAA PwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPkAQAAAgDv AxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwElAEAAA8AAvCMAQAAgAAI8AgAAAADAAAA AyAAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAgAAAF AAAADwAE8HIAAAASAArwCAAAAAIgAAAgAgAAUwAL8B4AAAB/AAAABACAAMidYgG/AQAAAQD/AQAA AQABAwIEAAAAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAGIBDwAN8AwAAAAA AJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAyAAACACAABTAAvwHgAAAH8AAAAEAIAAGJ5iAb8B AAABAP8BAAABAAEDAwQAAAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4AYgEP AA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABIAAAAAwAAIMAC/AwAAAAgQEAAAAI gwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAA AICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPkAQAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACA AAAAAAcAAAAPAAwElAEAAA8AAvCMAQAAIAAI8AgAAAADAAAAAyQAAA8AA/AkAQAADwAE8CgAAAAB AAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAkAAAFAAAADwAE8HIAAAASAArwCAAAAAIk AAAgAgAAUwAL8B4AAAB/AAAABACAAAjL0QC/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIABsAHQ FFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANANEADwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIA CvAIAAAAAyQAACACAABTAAvwHgAAAH8AAAAEAIAAxMDRAL8BAAABAP8BAAABAAEDAwQAAAAAEPAI AAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4A0QAPAA3wDAAAAAAAng8EAAAAAQAAAA8A BPBIAAAAEgAK8AgAAAABJAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwES ABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8A srKyAAAAchcsAAAAAQBQAAAAAADJEwAAbRwAAFkeAABFIAAABwBAADEiAAAdJAAACSYAAPUnAAAA APUPHAAAAAUBAACcCgADAAAAAOEpAAABAAAACgAAAAEAQwAPAOgDwRMAAAEA6QMoAAAAgBYAAOAQ AADgEAAAgBYAAAUAAAAKAAAAAAAAAAAAAAABAAAAAAAAAQ8A8gMWAQAALwDIDwwAAAAwANIPBAAA AAEAAAAPANUHTAAAAAAAtw9EAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABIJ9EA tNUTAJzVEwB2xwswCAAAAAAAAAC01RMAKN0NMAAABAAAAKQPCgAAAIAAYAAAAP////8AAKUPDAAA AAAAAAguAAAABwAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAA AABkAAAAAAAAAAAAQAIAAAAABwAAAP//7wAAAAAA////////GAAAAAABAAAABQAAIAEgAQAAAAAA BQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsErAAAAA8AAPCkAAAAAAAG8FgA AAACKAAACgAAABsAAAAIAAAAAQAAAAcAAAADAAAABAAAAAQAAAAEAAAABQAAAAQAAAAGAAAABAAA AAAAAAAEAAAABwAAAAQAAAAIAAAABAAAAAIAAAAEAAAAY2VkdWN0aW9uIFN1cmVzaCBCb2RkYXBh dGksIEFsY2F0ZWwACAAAAFByb2JsZW0AEQAAAFByb2JsZW0gKGNvbnRkLikAIQAAAFdoeSBub3Qg dXNlIFRDUCBmb3IgcmVsaWFiaWxpdHk/AAkAAABTb2x1dGlvbgAYAAAAQWNrbm93bGVkZ2VtZW50 IHNjaGVtZXMAGAAAAEFja25vd2xlZGdlbWVudCBTY2hlbWVzABgAAABTbm9vcGluZyBjb25zaWRl cmF0aW9ucwAMEAAABgAAAB4AAAALAAAARm9udHMgVXNlZAADAAAAAQAAAB4AAAAQAAAARGVzaWdu IFRlbXAAAPYPGwAAABQAAABfwJHjD1IAAAMA9AMDANEAd3d3CAAAAHcAdwB3AAAAAAgAiRBnDAAA AQAJAAADjQYAAAYAVAAAAAAAEQAAACYGDwAYAP////8AABAAAAAAAAAAAADAAwAA0AIAAAkAAAAm Bg8ACAD/////AgAAABcAAAAmBg8AIwD/////BAAbAFROUFAUADAB0QAyAAAA//9PABQAAABNAGkA AAAKAAAAJgYPAAoAVE5QUAAAAgD0AwkAAAAmBg8ACAD/////AwAAAA8AAAAmBg8AFABUTlBQBAAM AAEAAAABAAAAAAAAAAUAAAALAgAAAAAFAAAADALQAsADJAAAAIEBBAAACIMBAAAACL8BEAAQAMAB AQAACP8BCAAIAAECAgAACEAAHvEQAAAABAAACAEAAAgCAAAI9wAAEB8A8A8cAAAAAADzAxQAAAAC AAAAAAAAAAAAAAAAAACAAAAAAA8A0Ac3AQAAHwAUBBwAAAAAABUEFAAAALoddewAypo7Mk7NyQDK mjsBAQABDwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAAQwAAAGQAAABDAAAAZAAAAHbHCzAIAAAA AAAAAKjVEwAAAAAAAAAAAKz///8u////AQAAAHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAABA CwAAHwAHBDwAAAAAAP0DNAAAACEAAABkAAAAIQAAAGQAAABg8w0wZNkTAAAAAAA0KNEAAAAAAAAA AAAAAAAAAAAAAAABEwAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAAGDzDTBk2RMAAAAA ADQo0QAAAAAAAAAAAAAAAAAAAAAAAAETAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAPAPAP TBAAAAAA8wMUAAAAAwAAAAAAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPCAAAAFByb2Js ZW0gEACfDwQAAAABAAAAAACoD3QBAABQSU0gSm9pbnMgYXJlIHJlZnJlc2hlZCBldmVyeSA2MCBz ZWNvbmRzIGJ5IGEgZG93bnN0cmVhbSByb3V0ZXIgdG8ga2VlcCBtdWx0aWNhc3Qgc3RhdGUgYWxp dmUgYXQgdGhlIHVwc3RyZWFtIHJvdXRlci4NVGhlIG1vcmUgdGhlIG51bWJlciBvZiBzdGF0ZXMs IHRoZSBtb3JlIHRoZSBjb250cm9sIHRyYWZmaWMgcmVxdWlyZWQgZm9yIHJlZnJlc2guIA1TY2Fs aW5nIGJlY29tZXMgYW4gaXNzdWUgZXNwZWNpYWxseSB3aXRoIFZQTnMgKGUuZy4gMTAwMCBWUE5z IHdpdGggMTAwIGVudHJpZXMgZWFjaCBhbmQgMTAgZG93bnN0cmVhbSBpbnRlcmZhY2VzID0gMW1p bGxpb24gc3RhdGUgcmVmcmVzaGVzIGV2ZXJ5IG1pbnV0ZSBpbiBzdGVhZHkgc3RhdGUpLg0AAKEP FAAAAHUBAAAAAAAAAAB1AQAAAAACABwAAACqDywAAADyAAAAAAAAAAUAAAABAAAAAwALAAAAAAAA AAUAAAABAAAAAwBuAAAAAAAAAAAA8wMUAAAABAAAAAAAAAACAAAAAQEAAAAAAAAAAJ8PBAAAAAAA AAAAAKgPEAAAAFByb2JsZW0gKGNvbnRkLikQAJ8PBAAAAAEAAAAAAKgPTwEAAFJvdXRlIGNoYW5n ZXMgY2F1c2UgSm9pbnMgdG8gYmUgc2VudCB0byB0aGUgbmV3IFJQRiBuYnIuIElmIHRoZSBKb2lu IGdldHMgbG9zdCwgdGhlIGRpc3J1cHRpb24gb2YgdHJhZmZpYyBpcyBmb3IgYXQgbGVhc3QgYSBt aW51dGUuDU5vIHJlbGlhYmlsaXR5IGluIHRoZSBKb2luL1BydW5lIEV4Y2hhbmdlIGJldHdlZW4g ZG93bnN0cmVhbSBhbmQgdXBzdHJlYW0gcm91dGVycy4NTGFyZ2VyIHZhbHVlcyBvZiBob2xkdGlt ZSBpbiB0aGUgSlAgUERVIHdpbGwgcmVkdWNlIHRoZSBmcmVxdWVuY3kgb2YgcmVmcmVzaGVzLCBi dXQgY2FuIGNhdXNlIGxhcmdlciBjb252ZXJnZW5jZSBkZWxheXMuAAChDxQAAABQAQAAAAAAEAAA WgBQAQAAAAAAAAAAqg8sAAAANAAAAAAAAAADAAAAAQAAAAMAsAAAAAAAAAAJAAAAAQAAAAMAYAAA AAAAAAAAAPMDFAAAAAUAAAAAAAAAAgAAAAIBAAAAAAAAAACfDwQAAAAAAAAAAACoDyAAAABXaHkg bm90IHVzZSBUQ1AgZm9yIHJlbGlhYmlsaXR5PxAAnw8EAAAAAQAAAAAAoA/0AQAAQwBhAG4AbgBv AHQAIABoAGEAdgBlACAASgBvAGkAbgAgAHMAdQBwAHAAcgBlAHMAcwBpAG8AbgAsACAAbQBhAGsA aQBuAGcAIAB0AGgAZQAgAHAAcgBvAGIAbABlAG0AIABwAG8AdABlAG4AdABpAGEAbABsAHkAIAB3 AG8AcgBzAGUAIAAoAGEAbABsACAAZABvAHcAbgBzAHQAcgBlAGEAbQAgAHIAbwB1AHQAZQByAHMA IABjAG8AdQBsAGQAIABzAGUAbgBkACAAdABoAGUAaQByACAASgBvAGkAbgBzACAAYQB0ACAAYQBi AG8AdQB0ACAAdABoAGUAIABzAGEAbQBlACAAdABpAG0AZQAsACAAbQB1AGwAdABpAHAAbAB5AGkA bgBnACAAdABoAGUAIAB0AG8AdABhAGwAIABhAG0AbwB1AG4AdAAgAG8AZgAgAHQAcgBhAGYAZgBp AGMAIAByAGUAYwBlAGkAdgBlAGQAIABhAHQAIAB0AGgAZQAgAHUAcABzAHQAcgBlAGEAbQAgAHIA bwB1AHQAZQByACkALgANAFMAbgBvAG8AcABpAG4AZwAgACgAYgB5ACAATAAyACAAcwB3AGkAdABj AGgAZQBzACkAIAB3AG8AbgAZIHQAIAB3AG8AcgBrAC4ADQAAAPMDFAAAAAcAAAAAAAAAAgAAAAMB AAAAAAAAAACfDwQAAAAAAAAAAACoDwgAAABTb2x1dGlvbhAAnw8EAAAAAQAAAAAAqA+VAQAASWYg SlAgRXhjaGFuZ2UgaXMgbWFkZSByZWxpYWJsZSwgdGhlIHJlZnJlc2ggaW50ZXJ2YWwgY2FuIGJl IG1hZGUgbGFyZ2VyICg2MCBtaW51dGVzKS4NVXNlIGEgbmV3IEpQIEFjayBQRFUsIHdoaWNoIGFu IHVwc3RyZWFtIHJvdXRlciB3aWxsIHNlbmQgdG8gdGhlIGRvd25zdHJlYW0gcm91dGVyLCB0byBh Y2tub3dsZWRnZSByZWNlaXB0IG9mIGEgSlAgUERVLg1Eb3duc3RyZWFtIHJvdXRlcnMgd2lsbCBy ZXRyYW5zbWl0IEpQIFBEVXMgdW50aWwgdGhleSBhcmUgYWNrZWQuDVJldHJhbnNtaXNzaW9ucyBh cmUgZXhwb25lbnRpYWxseSBiYWNrZWQgb2ZmIGFuZCBjYXBwZWQgYXQgdGhlIHJlZ3VsYXIgcmVm cmVzaCBpbnRlcnZhbC4NU3RhdGUgdXBkYXRlcyBhbGxvd2VkIHdoaWxlIEFDS3MgYXJlIHBlbmRp bmcuAAChDxYAAACWAQAAAAAAEAAAWgCWAQAAAAACABwAAACqD1AAAABkAAAAAAAAAAQAAAABAAAA AwCMAAAAAAAAAAUAAAABAAAAAwAPAAAAAAAAAAUAAAABAAAAAwB3AAAAAAAAAAUAAAABAAAAAwAN AAAAAAAAAAAA8wMUAAAACAAAAAAAAAACAAAABAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFwAAAEFj a25vd2xlZGdlbWVudCBzY2hlbWVzEACfDwQAAAABAAAAAACgDyACAABEAGkAbgBvABkgcwAgAHMA YwBoAGUAbQBlADoADQBUAGgAZQAgAHUAcABzAHQAcgBlAGEAbQAgAHIAbwB1AHQAZQByACAAbQBv AGQAaQBmAGkAZQBzACAAdABoAGUAIAB0AHkAcABlACAAbwBmACAAdABoAGUAIAByAGUAYwBlAGkA dgBlAGQAIABKAFAAIABQAEQAVQAgAHQAbwAgAEoAUAAgAEEAQwBLACAAYQBuAGQAIABtAHUAbAB0 AGkAYwBhAHMAdABzACAAdABoAGUAIABQAEQAVQAgAGIAYQBjAGsAIABvAG4AIAB0AGgAZQAgAGwA aQBuAGsAIABpAHQAIABhAHIAcgBpAHYAZQBkACAAbwBuAC4ADQBSAGUAcwBlAHIAdgBlAGQAIABm AGkAZQBsAGQAIABpAG4AIAB0AGgAZQAgAEoAUAAgAFAARABVACAAdQBzAGUAZAAgAGEAcwAgAGEA IABzAGUAcQB1AGUAbgBjAGUAIABuAHUAbQBiAGUAcgAsACAAdwBoAGkAYwBoACAAdABoAGUAIABk AG8AdwBuAHMAdAByAGUAYQBtACAAcgBvAHUAdABlAHIAIAB1AHMAZQBzACAAdABvACAAZABpAHMA dABpAG4AZwB1AGkAcwBoACAAYgBlAHQAdwBlAGUAbgAgAEEAQwBLAHMAIABmAG8AcgAgAGEAIABK AFAAIABQAEQAVQAuAA0AAAChDzgAAAAPAAAAAAAAAAAAAQEAAAEAAAAAAAEAAAAAAAAAAAAPAAAA AAAAAAEBAAAAAAAAAQAAAAAAAgAYAAAAqg8aAAAA/QAAAAAAAAAFAAAAAQAAAAMADwAAAAAAAAAA APMDFAAAAAkAAAAAAAAAAgAAAAUBAAAAAAAAAACfDwQAAAAAAAAAAACoDxcAAABBY2tub3dsZWRn ZW1lbnQgU2NoZW1lcxAAnw8EAAAAAQAAAAAAoA/YAQAAUwB1AHIAZQBzAGgAGSBzACAAcwBjAGgA ZQBtAGUAOgANAFQAaABlACAAZABvAHcAbgBzAHQAcgBlAGEAbQAgAHIAbwB1AHQAZQByACAAYQBw AHAAZQBuAGQAcwAgAGEAIABUAEwAVgAgAGEAdAAgAHQAaABlACAAZQBuAGQAIABvAGYAIABKAFAA IABQAEQAVQAgAHcAaABpAGMAaAAgAGgAYQBzACAAYQAgADMAMgAgAGIAaQB0ACAAbQBlAHMAcwBh AGcAZQAgAEkARAAgAHQAaABhAHQAIABpAGQAZQBuAHQAaQBmAGkAZQBzACAAZQB2AGUAcgB5ACAA SgBQACAAbQBlAHMAcwBhAGcAZQAgAHMAZQBuAHQAIABiAHkAIABpAHQALgANAFQAaABlACAAdQBw AHMAdAByAGUAYQBtACAAcgBvAHUAdABlAHIAIABjAG8AcABpAGUAcwAgAHQAaABlACAAVABMAFYA IABpAG4AdABvACAAdABoAGUAIABBAEMASwAgAFAARABVACAAYQBuAGQAIAB1AG4AaQBjAGEAcwB0 AHMAIABpAHQAIABiAGEAYwBrACAAdABvACAAdABoAGUAIABzAGUAbgBkAGUAcgAuAAAAoQ8mAAAA EQAAAAAAAAAAANwAAAABAAAAAAARAAAAAAAAANwAAAAABAAAAAQAAKoPGgAAAM0AAAAAAAAACQAA AAEAAAADABcAAAAAAAAAAADzAxQAAAAKAAAAAAAAAAIAAAAGAQAAAAAAAAAAnw8EAAAAAAAAAAAA qA8XAAAAU25vb3BpbmcgY29uc2lkZXJhdGlvbnMQAJ8PBAAAAAEAAAAAAKgPeQEAAEwyIHN3aXRj aGVzIHNub29wIG9uIFBJTSBKUCBQRFVzIHRvIGNyZWF0ZSBMMiBtdWx0aWNhc3QgZm9yd2FyZGlu ZyBzdGF0ZS4NVGhlIGxhcmdlciB0aGUgcmVmcmVzaCBpbnRlcnZhbCwgdGhlIGxvbmdlciBpdCB3 aWxsIHRha2UgZm9yIEwyIHN3aXRjaGVzIHRvIGJ1aWxkIHN0YXRlLg1MMiBzd2l0Y2hlcyBjb3Vs ZCByZXF1ZXN0IGRvd25zdHJlYW0gcm91dGVycyB0byByZWZyZXNoIHRoZWlyIHN0YXRlIGJ5IGVp dGhlcg1TZW5kaW5nIG91dCBhIFBJTSBQRFUgKG5ldyBQRFUgdHlwZSkNU2V0dGluZyBHZW5JRCB0 byB6ZXJvIGJlZm9yZSBmb3J3YXJkaW5nIGFueSBIZWxsbyBzZWVuIGZvciB0aGUgZmlyc3QgdGlt ZSBmcm9tIGEgcm91dGVyIG9uIHRoZSBMQU4uAAChDyoAAADxAAAAAAAAAAAAiQAAAAEAAAAAAPEA AAAAAAIAHACJAAAAAAQCAAAEGAAAAKoPLAAAABwAAAAAAAAABQAAAAEAAAADAP0AAAAAAAAABgAA AAEAAAADAFYAAAAAAAAAAADqAwAAAAAAAHIXCAAAAAEAEAA2PgAAAAD1DxwAAAAGAQAAnAoAAxI+ AAD/UQAAAQAAAAoAAAABAEMADwDoA8YUAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAA AAAAAAAAAAAAAQAAAAAAAAEPAPIDFgEAAC8AyA8MAAAAMADSDwQAAAABAAAADwDVB0wAAAAAALcP RAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAASCfRALTVEwCc1RMAdscLMAgAAAAA AAAAtNUTACjdDTAAFAYSAACkDwoAAACAAGAAAAD/////AAClDwwAAAAAAAAILgAAAAcAAAAAAKkP CgAAAAcAAAACAAkEAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAA AAcAAAD//+8AAAAAAP///////xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGAD YAMAAAAAAAUAAIAEgAQAAAAADwALBMwAAAAPAADwxAAAAAAABvB4AAAAAjgAAA4AAAAeAAAACQAA AAEAAAAHAAAAAwAAAAQAAAAFAAAABAAAAAkAAAAEAAAACgAAAAQAAAAAAAAABAAAAAsAAAAEAAAA DAAAAAQAAAACAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAHAAAABAAAAAAAAAAGAAAAYwAL8CQAAACB AQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAhAAB7xEAAAAAQAAAgBAAAIAgAACPcA ABAfAPAPHAAAAAAA8wMUAAAAAgAAAAAAAAAAAAAAAAAAgAAAAAAPANAHNwEAAB8AFAQcAAAAAAAV BBQAAAC6HXXsAMqaOzJOzckAypo7AQEAAQ8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAAEMAAABk AAAAQwAAAGQAAAB2xwswCAAAAAAAAACo1RMAAAAAAAAAAACs////Lv///wEAAABwAPsDCAAAAAAA AABwCAAAcAD7AwgAAAABAAAAQAsAAB8ABwQ8AAAAAAD9AzQAAAAhAAAAZAAAACEAAABkAAAAYPMN MGTZEwAAAAAANCjRAAAAAAAAAAAAAAAAAAAAAAAAARMAHwATBDwAAAAAAP0DNAAAAGQAAABkAAAA ZAAAAGQAAABg8w0wZNkTAAAAAAA0KNEAAAAAAAAAAAAAAAAAAAAAAAABEwAfAP8DFAAAAAIAAAQM AAAAAAAAAAAAAAACAAAADwDwDzERAAAAAPMDFAAAAAMAAAAAAAAAAgAAAAABAAAAAAAAAACfDwQA AAAGAAAAAACoDy8AAABQSU0gUmVmcmVzaCBSZWR1Y3Rpb24LU3VyZXNoIEJvZGRhcGF0aSwgQWxj YXRlbAAAoQ8cAAAAMAAAAAAAAAAAABYAAAAAAAAAGgAAAAAAAgAgAAAAqg8sAAAAHQAAAAAAAAAJ AAAAAQAAAAMAAQAAAAAAAAAIAAAAAQAAAAMAAQAAAAAAAAAQAJ8PBAAAAAUAAAAAAKgPAQAAAA0A APMDFAAAAAsAAAAAAAAAAgAAAAcBAAAAAAAAAACfDwQAAAAAAAAAAACoDwcAAABQcm9ibGVtAACq DxIAAAAHAAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgPdAEAAFBJTSBKb2lucyBhcmUg cmVmcmVzaGVkIGV2ZXJ5IDYwIHNlY29uZHMgYnkgYSBkb3duc3RyZWFtIHJvdXRlciB0byBrZWVw IG11bHRpY2FzdCBzdGF0ZSBhbGl2ZSBhdCB0aGUgdXBzdHJlYW0gcm91dGVyLg1UaGUgbW9yZSB0 aGUgbnVtYmVyIG9mIHN0YXRlcywgdGhlIG1vcmUgdGhlIGNvbnRyb2wgdHJhZmZpYyByZXF1aXJl ZCBmb3IgcmVmcmVzaC4gDVNjYWxpbmcgYmVjb21lcyBhbiBpc3N1ZSBlc3BlY2lhbGx5IHdpdGgg VlBOcyAoZS5nLiAxMDAwIFZQTnMgd2l0aCAxMDAgZW50cmllcyBlYWNoIGFuZCAxMCBkb3duc3Ry ZWFtIGludGVyZmFjZXMgPSAxbWlsbGlvbiBzdGF0ZSByZWZyZXNoZXMgZXZlcnkgbWludXRlIGlu IHN0ZWFkeSBzdGF0ZSkuDQAAoQ8UAAAAdQEAAAAAAAAAAHUBAAAAAAIAHAAAAKoPLAAAAPIAAAAA AAAABQAAAAEAAAADAAsAAAAAAAAABQAAAAEAAAADAG4AAAAAAAAAAADzAxQAAAAEAAAAAAAAAAIA AAABAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8QAAAAUHJvYmxlbSAoY29udGQuKRAAnw8EAAAAAQAA AAAAqA9PAQAAUm91dGUgY2hhbmdlcyBjYXVzZSBKb2lucyB0byBiZSBzZW50IHRvIHRoZSBuZXcg UlBGIG5ici4gSWYgdGhlIEpvaW4gZ2V0cyBsb3N0LCB0aGUgZGlzcnVwdGlvbiBvZiB0cmFmZmlj IGlzIGZvciBhdCBsZWFzdCBhIG1pbnV0ZS4NTm8gcmVsaWFiaWxpdHkgaW4gdGhlIEpvaW4vUHJ1 bmUgRXhjaGFuZ2UgYmV0d2VlbiBkb3duc3RyZWFtIGFuZCB1cHN0cmVhbSByb3V0ZXJzLg1MYXJn ZXIgdmFsdWVzIG9mIGhvbGR0aW1lIGluIHRoZSBKUCBQRFUgd2lsbCByZWR1Y2UgdGhlIGZyZXF1 ZW5jeSBvZiByZWZyZXNoZXMsIGJ1dCBjYW4gY2F1c2UgbGFyZ2VyIGNvbnZlcmdlbmNlIGRlbGF5 cy4AAKEPFAAAAFABAAAAAAAQAABaAFABAAAAAAAAAACqDywAAAA0AAAAAAAAAAMAAAABAAAAAwCw AAAAAAAAAAkAAAABAAAAAwBgAAAAAAAAAAAA8wMUAAAABQAAAAAAAAACAAAAAgEAAAAAAAAAAJ8P BAAAAAAAAAAAAKgPIAAAAFdoeSBub3QgdXNlIFRDUCBmb3IgcmVsaWFiaWxpdHk/EACfDwQAAAAB AAAAAACgD/QBAABDAGEAbgBuAG8AdAAgAGgAYQB2AGUAIABKAG8AaQBuACAAcwB1AHAAcAByAGUA cwBzAGkAbwBuACwAIABtAGEAawBpAG4AZwAgAHQAaABlACAAcAByAG8AYgBsAGUAbQAgAHAAbwB0 AGUAbgB0AGkAYQBsAGwAeQAgAHcAbwByAHMAZQAgACgAYQBsAGwAIABkAG8AdwBuAHMAdAByAGUA YQBtACAAcgBvAHUAdABlAHIAcwAgAGMAbwB1AGwAZAAgAHMAZQBuAGQAIAB0AGgAZQBpAHIAIABK AG8AaQBuAHMAIABhAHQAIABhAGIAbwB1AHQAIAB0AGgAZQAgAHMAYQBtAGUAIAB0AGkAbQBlACwA IABtAHUAbAB0AGkAcABsAHkAaQBuAGcAIAB0AGgAZQAgAHQAbwB0AGEAbAAgAGEAbQBvAHUAbgB0 ACAAbwBmACAAdAByAGEAZgBmAGkAYwAgAHIAZQBjAGUAaQB2AGUAZAAgAGEAdAAgAHQAaABlACAA dQBwAHMAdAByAGUAYQBtACAAcgBvAHUAdABlAHIAKQAuAA0AUwBuAG8AbwBwAGkAbgBnACAAKABi AHkAIABMADIAIABzAHcAaQB0AGMAaABlAHMAKQAgAHcAbwBuABkgdAAgAHcAbwByAGsALgANAAAA 8wMUAAAABwAAAAAAAAACAAAAAwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPCAAAAFNvbHV0aW9uEACf DwQAAAABAAAAAACoD5UBAABJZiBKUCBFeGNoYW5nZSBpcyBtYWRlIHJlbGlhYmxlLCB0aGUgcmVm cmVzaCBpbnRlcnZhbCBjYW4gYmUgbWFkZSBsYXJnZXIgKDYwIG1pbnV0ZXMpLg1Vc2UgYSBuZXcg SlAgQWNrIFBEVSwgd2hpY2ggYW4gdXBzdHJlYW0gcm91dGVyIHdpbGwgc2VuZCB0byB0aGUgZG93 bnN0cmVhbSByb3V0ZXIsIHRvIGFja25vd2xlZGdlIHJlY2VpcHQgb2YgYSBKUCBQRFUuDURvd25z dHJlYW0gcm91dGVycyB3aWxsIHJldHJhbnNtaXQgSlAgUERVcyB1bnRpbCB0aGV5IGFyZSBhY2tl ZC4NUmV0cmFuc21pc3Npb25zIGFyZSBleHBvbmVudGlhbGx5IGJhY2tlZCBvZmYgYW5kIGNhcHBl ZCBhdCB0aGUgcmVndWxhciByZWZyZXNoIGludGVydmFsLg1TdGF0ZSB1cGRhdGVzIGFsbG93ZWQg d2hpbGUgQUNLcyBhcmUgcGVuZGluZy4AAKEPFgAAAJYBAAAAAAAQAABaAJYBAAAAAAIAHAAAAKoP UAAAAGQAAAAAAAAABAAAAAEAAAADAIwAAAAAAAAABQAAAAEAAAADAA8AAAAAAAAABQAAAAEAAAAD AHcAAAAAAAAABAAAAAEAAAADAA4AAAAAAAAAAADzAxQAAAAIAAAAAAAAAAIAAAAEAQAAAAAAAAAA nw8EAAAAAAAAAAAAqA8XAAAAQWNrbm93bGVkZ2VtZW50IHNjaGVtZXMQAJ8PBAAAAAEAAAAAAKAP IAIAAEQAaQBuAG8AGSBzACAAcwBjAGgAZQBtAGUAOgANAFQAaABlACAAdQBwAHMAdAByAGUAYQBt ACAAcgBvAHUAdABlAHIAIABtAG8AZABpAGYAaQBlAHMAIAB0AGgAZQAgAHQAeQBwAGUAIABvAGYA IAB0AGgAZQAgAHIAZQBjAGUAaQB2AGUAZAAgAEoAUAAgAFAARABVACAAdABvACAASgBQACAAQQBD AEsAIABhAG4AZAAgAG0AdQBsAHQAaQBjAGEAcwB0AHMAIAB0AGgAZQAgAFAARABVACAAYgBhAGMA awAgAG8AbgAgAHQAaABlACAAbABpAG4AawAgAGkAdAAgAGEAcgByAGkAdgBlAGQAIABvAG4ALgAN AFIAZQBzAGUAcgB2AGUAZAAgAGYAaQBlAGwAZAAgAGkAbgAgAHQAaABlACAASgBQACAAUABEAFUA IAB1AHMAZQBkACAAYQBzACAAYQAgAHMAZQBxAHUAZQBuAGMAZQAgAG4AdQBtAGIAZQByACwAIAB3 AGgAaQBjAGgAIAB0AGgAZQAgAGQAbwB3AG4AcwB0AHIAZQBhAG0AIAByAG8AdQB0AGUAcgAgAHUA cwBlAHMAIAB0AG8AIABkAGkAcwB0AGkAbgBnAHUAaQBzAGgAIABiAGUAdAB3AGUAZQBuACAAQQBD AEsAcwAgAGYAbwByACAAYQAgAEoAUAAgAFAARABVAC4ADQAAAKEPOAAAAA8AAAAAAAAAAAABAQAA AQAAAAAAAQAAAAAAAAAAAA8AAAAAAAAAAQEAAAAAAAABAAAAAAACABgAAACqDxoAAAD9AAAAAAAA AAUAAAABAAAAAwAPAAAAAAAAAAAA8wMUAAAACQAAAAAAAAACAAAABQEAAAAAAAAAAJ8PBAAAAAAA AAAAAKgPFwAAAEFja25vd2xlZGdlbWVudCBTY2hlbWVzEACfDwQAAAABAAAAAACgD9gBAABTAHUA cgBlAHMAaAAZIHMAIABzAGMAaABlAG0AZQA6AA0AVABoAGUAIABkAG8AdwBuAHMAdAByAGUAYQBt ACAAcgBvAHUAdABlAHIAIABhAHAAcABlAG4AZABzACAAYQAgAFQATABWACAAYQB0ACAAdABoAGUA IABlAG4AZAAgAG8AZgAgAEoAUAAgAFAARABVACAAdwBoAGkAYwBoACAAaABhAHMAIABhACAAMwAy ACAAYgBpAHQAIABtAGUAcwBzAGEAZwBlACAASQBEACAAdABoAGEAdAAgAGkAZABlAG4AdABpAGYA aQBlAHMAIABlAHYAZQByAHkAIABKAFAAIABtAGUAcwBzAGEAZwBlACAAcwBlAG4AdAAgAGIAeQAg AGkAdAAuAA0AVABoAGUAIAB1AHAAcwB0AHIAZQBhAG0AIAByAG8AdQB0AGUAcgAgAGMAbwBwAGkA ZQBzACAAdABoAGUAIABUAEwAVgAgAGkAbgB0AG8AIAB0AGgAZQAgAEEAQwBLACAAUABEAFUAIABh AG4AZAAgAHUAbgBpAGMAYQBzAHQAcwAgAGkAdAAgAGIAYQBjAGsAIAB0AG8AIAB0AGgAZQAgAHMA ZQBuAGQAZQByAC4AAAChDyYAAAARAAAAAAAAAAAA3AAAAAEAAAAAABEAAAAAAAAA3AAAAAAEAAAA BAAAqg8aAAAAzQAAAAAAAAAJAAAAAQAAAAMAFwAAAAAAAAAAAPMDFAAAAAoAAAAAAAAAAgAAAAYB AAAAAAAAAACfDwQAAAAAAAAAAACoDxcAAABTbm9vcGluZyBjb25zaWRlcmF0aW9ucxAAnw8EAAAA AQAAAAAAqA95AQAATDIgc3dpdGNoZXMgc25vb3Agb24gUElNIEpQIFBEVXMgdG8gY3JlYXRlIEwy IG11bHRpY2FzdCBmb3J3YXJkaW5nIHN0YXRlLg1UaGUgbGFyZ2VyIHRoZSByZWZyZXNoIGludGVy dmFsLCB0aGUgbG9uZ2VyIGl0IHdpbGwgdGFrZSBmb3IgTDIgc3dpdGNoZXMgdG8gYnVpbGQgc3Rh dGUuDUwyIHN3aXRjaGVzIGNvdWxkIHJlcXVlc3QgZG93bnN0cmVhbSByb3V0ZXJzIHRvIHJlZnJl c2ggdGhlaXIgc3RhdGUgYnkgZWl0aGVyDVNlbmRpbmcgb3V0IGEgUElNIFBEVSAobmV3IFBEVSB0 eXBlKQ1TZXR0aW5nIEdlbklEIHRvIHplcm8gYmVmb3JlIGZvcndhcmRpbmcgYW55IEhlbGxvIHNl ZW4gZm9yIHRoZSBmaXJzdCB0aW1lIGZyb20gYSByb3V0ZXIgb24gdGhlIExBTi4AAKEPKgAAAPEA AAAAAAAAAACJAAAAAQAAAAAA8QAAAAAAAgAcAIkAAAAABAIAAAQYAAAAqg8sAAAAHAAAAAAAAAAF AAAAAQAAAAMA/QAAAAAAAAAGAAAAAQAAAAMAVgAAAAAAAAAAAOoDAAAAAA8A7gPwAQAAAgDvAxgA AAAAAAAADxAAAAAAAAAAAACAAAAAAAcAAAAPAAwEoAEAAA8AAvCYAQAAMAAI8AgAAAADAAAAAwgA AA8AA/AwAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAIAAAFAAAA DwAE8HgAAAASAArwCAAAAAIIAAAgAgAAYwAL8CQAAAAEAAAAAAB/AAAABACAALTf0QC/AQAAAQD/ AQAAAQABAwIEAAAAABDwCAAAAKAFsAHQFHAIDwAR8BAAAAAAAMMLCAAAAAAAAAAPANEADwAN8AwA AAAAAJ4PBAAAAAAAAAAPAATweAAAABIACvAIAAAAAwgAACACAABjAAvwJAAAAAQAAAAAAH8AAAAE AIAAcODRAL8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAAkAlgAyAT4A0PABHwEAAAAAAAwwsIAAAA AQAAABAA0QAPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABCAAAAAwAAIMAC/Aw AAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAA AAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPwAQAAAgDvAxgAAAABAAAADQ4A AAAAAAAAAACAAAAAAAcAAAAPAAwEoAEAAA8AAvCYAQAAcAAI8AgAAAADAAAAAzAAAA8AA/AwAQAA DwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAwAAAFAAAADwAE8HgAAAAS AArwCAAAAAIwAAAgAgAAYwAL8CQAAAB/AAAABACAABC7YgG/AQAAAQD/AQAAAQABAwIEAACIAwAA AAAAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAGIBDwAN8AwAAAAAAJ4PBAAA AAAAAAAPAATweAAAABIACvAIAAAAAzAAACACAABjAAvwJAAAAH8AAAAEAIAALLNiAb8BAAABAP8B AAABAAEDAwQAAIgDAAAAAAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4AYgEP AA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABMAAAAAwAAIMAC/AwAAAAgQEAAAAI gwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAA AICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPkAQAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACA AAAAAAcAAAAPAAwElAEAAA8AAvCMAQAAUAAI8AgAAAADAAAAAwwAAA8AA/AkAQAADwAE8CgAAAAB AAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAMAAAFAAAADwAE8HIAAAASAArwCAAAAAIM AAAgAgAAUwAL8B4AAAB/AAAABACAAKh+YgG/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIABsAHQ FFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAGIBDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIA CvAIAAAAAwwAACACAABTAAvwHgAAAH8AAAAEAIAAOH9iAb8BAAABAP8BAAABAAEDAwQAAAAAEPAI AAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4AYgEPAA3wDAAAAAAAng8EAAAAAQAAAA8A BPBIAAAAEgAK8AgAAAABDAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwES ABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8A srKyAAAAchccAAAAAQAQADNSAAADACAAAWcAAPFqAAALABAA+WgAAAAA9Q8cAAAAAAEAAJwKAAMP UgAA3WwAAAEAAAALAAAAAQBDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAA AA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAADEAAAD+////GAAAABkAAAAaAAAA GwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAAp AAAAKgAAACsAAAAsAAAALQAAAP7////9////MAAAAP7///8yAAAAMwAAADQAAAA1AAAANgAAADcA AAA4AAAAOQAAADoAAAAXAAAA/v///z0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAAAWAAAA//// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAQjYFkm0/PEYbqAKoAuSnoAAAAAAAAAAAA AAAAUCkWY7UdxQE8AAAAABEAAAAAAABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAP///////////////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4AAAApAAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4A ZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAQAAAP////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAHAAAAAAAAUABvAHcA ZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACgAAgECAAAABAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA JW0AAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABp AG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAADoAAACsAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAL8CQAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAhAAB7xEAAA AAQAAAgBAAAIAgAACPcAABAfAPAPHAAAAAAA8wMUAAAAAgAAAAAAAAAAAAAAAAAAgAAAAAAPANAH NwEAAB8AFAQcAAAAAAAVBBQAAAC6HXXsAMqaOzJOzckAypo7AQEAAQ8A+gNnAAAAAAD+AwMAAAAA AQAAAP0DNAAAAEMAAABkAAAAQwAAAGQAAAB2xwswCAAAAAAAAACo1RMAAAAAAAAAAACs////Lv// /wEAAABwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8ABwQ8AAAAAAD9AzQAAAAhAAAA ZAAAACEAAABkAAAAYPMNMGTZEwAAAAAANCjRAAAAAAAAAAAAAAAAAAAAAAAAARMAHwATBDwAAAAA AP0DNAAAAGQAAABkAAAAZAAAAGQAAABg8w0wZNkTAAAAAAA0KNEAAAAAAAAAAAAAAAAAAAAAAAAB EwAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAADwDwD0wQAAAAAPMDFAAAAAMAAAAAAAAAAgAA AAABAAAAAAAAAACfDwQAAAAAAAAAAACoDwgAAABQcm9ibGVtIBAAnw8EAAAAAQAAAAAAqA90AQAA UElNIEpvaW5zIGFyZSByZWZyZXNoZWQgZXZlcnkgNjAgc2Vjb25kcyBieSBhIGRvd25zdHJlYW0g cm91dGVyIHRvIGtlZXAgbXVsdGljYXN0IHN0YXRlIGFsaXZlIGF0IHRoZSB1cHN0cmVhbSByb3V0 ZXIuDVRoZSBtb3JlIHRoZSBudW1iZXIgb2Ygc3RhdGVzLCB0aGUgbW9yZSB0aGUgY29udHJvbCB0 cmFmZmljIHJlcXVpcmVkIGZvciByZWZyZXNoLiANU2NhbGluZyBiZWNvbWVzIGFuIGlzc3VlIGVz cGVjaWFsbHkgd2l0aCBWUE5zIChlLmcuIDEwMDAgVlBOcyB3aXRoIDEwMCBlbnRyaWVzIGVhY2gg YW5kIDEwIGRvd25zdHJlYW0gaW50ZXJmYWNlcyA9IDFtaWxsaW9uIHN0YXRlIHJlZnJlc2hlcyBl dmVyeSBtaW51dGUgaW4gc3RlYWR5IHN0YXRlKS4NAAChDxQAAAB1AQAAAAAAAAAAdQEAAAAAAgAc AAAAqg8sAAAA8gAAAAAAAAAFAAAAAQAAAAMACwAAAAAAAAAFAAAAAQAAAAMAbgAAAAAAAAAAAPMD FAAAAAQAAAAAAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDxAAAABQcm9ibGVtIChjb250 ZC4pEACfDwQAAAABAAAAAACoD08BAABSb3V0ZSBjaGFuZ2VzIGNhdXNlIEpvaW5zIHRvIGJlIHNl bnQgdG8gdGhlIG5ldyBSUEYgbmJyLiBJZiB0aGUgSm9pbiBnZXRzIGxvc3QsIHRoZSBkaXNydXB0 aW9uIG9mIHRyYWZmaWMgaXMgZm9yIGF0IGxlYXN0IGEgbWludXRlLg1ObyByZWxpYWJpbGl0eSBp biB0aGUgSm9pbi9QcnVuZSBFeGNoYW5nZSBiZXR3ZWVuIGRvd25zdHJlYW0gYW5kIHVwc3RyZWFt IHJvdXRlcnMuDUxhcmdlciB2YWx1ZXMgb2YgaG9sZHRpbWUgaW4gdGhlIEpQIFBEVSB3aWxsIHJl ZHVjZSB0aGUgZnJlcXVlbmN5IG9mIHJlZnJlc2hlcywgYnV0IGNhbiBjYXVzZSBsYXJnZXIgY29u dmVyZ2VuY2UgZGVsYXlzLgAAoQ8UAAAAUAEAAAAAABAAAFoAUAEAAAAAAAAAAKoPLAAAADQAAAAA AAAAAwAAAAEAAAADALAAAAAAAAAACQAAAAEAAAADAGAAAAAAAAAAAADzAxQAAAAFAAAAAAAAAAIA AAACAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8gAAAAV2h5IG5vdCB1c2UgVENQIGZvciByZWxpYWJp bGl0eT8QAJ8PBAAAAAEAAAAAAKAP9AEAAEMAYQBuAG4AbwB0ACAAaABhAHYAZQAgAEoAbwBpAG4A IABzAHUAcABwAHIAZQBzAHMAaQBvAG4ALAAgAG0AYQBrAGkAbgBnACAAdABoAGUAIABwAHIAbwBi AGwAZQBtACAAcABvAHQAZQBuAHQAaQBhAGwAbAB5ACAAdwBvAHIAcwBlACAAKABhAGwAbAAgAGQA bwB3AG4AcwB0AHIAZQBhAG0AIAByAG8AdQB0AGUAcgBzACAAYwBvAHUAbABkACAAcwBlAG4AZAAg AHQAaABlAGkAcgAgAEoAbwBpAG4AcwAgAGEAdAAgAGEAYgBvAHUAdAAgAHQAaABlACAAcwBhAG0A ZQAgAHQAaQBtAGUALAAgAG0AdQBsAHQAaQBwAGwAeQBpAG4AZwAgAHQAaABlACAAdABvAHQAYQBs ACAAYQBtAG8AdQBuAHQAIABvAGYAIAB0AHIAYQBmAGYAaQBjACAAcgBlAGMAZQBpAHYAZQBkACAA YQB0ACAAdABoAGUAIAB1AHAAcwB0AHIAZQBhAG0AIAByAG8AdQB0AGUAcgApAC4ADQBTAG4AbwBv AHAAaQBuAGcAIAAoAGIAeQAgAEwAMgAgAHMAdwBpAHQAYwBoAGUAcwApACAAdwBvAG4AGSB0ACAA dwBvAHIAawAuAA0AAADzAxQAAAAHAAAAAAAAAAIAAAADAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8I AAAAU29sdXRpb24QAJ8PBAAAAAEAAAAAAKgPlQEAAElmIEpQIEV4Y2hhbmdlIGlzIG1hZGUgcmVs aWFibGUsIHRoZSByZWZyZXNoIGludGVydmFsIGNhbiBiZSBtYWRlIGxhcmdlciAoNjAgbWludXRl cykuDVVzZSBhIG5ldyBKUCBBY2sgUERVLCB3aGljaCBhbiB1cHN0cmVhbSByb3V0ZXIgd2lsbCBz ZW5kIHRvIHRoZSBkb3duc3RyZWFtIHJvdXRlciwgdG8gYWNrbm93bGVkZ2UgcmVjZWlwdCBvZiBh IEpQIFBEVS4NRG93bnN0cmVhbSByb3V0ZXJzIHdpbGwgcmV0cmFuc21pdCBKUCBQRFVzIHVudGls IHRoZXkgYXJlIGFja2VkLg1SZXRyYW5zbWlzc2lvbnMgYXJlIGV4cG9uZW50aWFsbHkgYmFja2Vk IG9mZiBhbmQgY2FwcGVkIGF0IHRoZSByZWd1bGFyIHJlZnJlc2ggaW50ZXJ2YWwuDVN0YXRlIHVw ZGF0ZXMgYWxsb3dlZCB3aGlsZSBBQ0tzIGFyZSBwZW5kaW5nLgAAoQ8WAAAAlgEAAAAAABAAAFoA lgEAAAAAAgAcAAAAqg9QAAAAZAAAAAAAAAAEAAAAAQAAAAMAjAAAAAAAAAAFAAAAAQAAAAMADwAA AAAAAAAFAAAAAQAAAAMAdwAAAAAAAAAFAAAAAQAAAAMADQAAAAAAAAAAAPMDFAAAAAgAAAAAAAAA AgAAAAQBAAAAAAAAAACfDwQAAAAAAAAAAACoDxcAAABBY2tub3dsZWRnZW1lbnQgc2NoZW1lcxAA nw8EAAAAAQAAAAAAoA8gAgAARABpAG4AbwAZIHMAIABzAGMAaABlAG0AZQA6AA0AVABoAGUAIAB1 AHAAcwB0AHIAZQBhAG0AIAByAG8AdQB0AGUAcgAgAG0AbwBkAGkAZgBpAGUAcwAgAHQAaABlACAA dAB5AHAAZQAgAG8AZgAgAHQAaABlACAAcgBlAGMAZQBpAHYAZQBkACAASgBQACAAUABEAFUAIAB0 AG8AIABKAFAAIABBAEMASwAgAGEAbgBkACAAbQB1AGwAdABpAGMAYQBzAHQAcwAgAHQAaABlACAA UABEAFUAIABiAGEAYwBrACAAbwBuACAAdABoAGUAIABsAGkAbgBrACAAaQB0ACAAYQByAHIAaQB2 AGUAZAAgAG8AbgAuAA0AUgBlAHMAZQByAHYAZQBkACAAZgBpAGUAbABkACAAaQBuACAAdABoAGUA IABKAFAAIABQAEQAVQAgAHUAcwBlAGQAIABhAHMAIABhACAAcwBlAHEAdQBlAG4AYwBlACAAbgB1 AG0AYgBlAHIALAAgAHcAaABpAGMAaAAgAHQAaABlACAAZABvAHcAbgBzAHQAcgBlAGEAbQAgAHIA bwB1AHQAZQByACAAdQBzAGUAcwAgAHQAbwAgAGQAaQBzAHQAaQBuAGcAdQBpAHMAaAAgAGIAZQB0 AHcAZQBlAG4AIABBAEMASwBzACAAZgBvAHIAIABhACAASgBQACAAUABEAFUALgANAAAAoQ84AAAA DwAAAAAAAAAAAAEBAAABAAAAAAABAAAAAAAAAAAADwAAAAAAAAABAQAAAAAAAAEAAAAAAAIAGAAA AKoPGgAAAP0AAAAAAAAABQAAAAEAAAADAA8AAAAAAAAAAADzAxQAAAAJAAAAAAAAAAIAAAAFAQAA AAAAAAAAnw8EAAAAAAAAAAAAqA8XAAAAQWNrbm93bGVkZ2VtZW50IFNjaGVtZXMQAJ8PBAAAAAEA AAAAAKAP2AEAAFMAdQByAGUAcwBoABkgcwAgAHMAYwBoAGUAbQBlADoADQBUAGgAZQAgAGQAbwB3 AG4AcwB0AHIAZQBhAG0AIAByAG8AdQB0AGUAcgAgAGEAcABwAGUAbgBkAHMAIABhACAAVABMAFYA IABhAHQAIAB0AGgAZQAgAGUAbgBkACAAbwBmACAASgBQACAAUABEAFUAIAB3AGgAaQBjAGgAIABo AGEAcwAgAGEAIAAzADIAIABiAGkAdAAgAG0AZQBzAHMAYQBnAGUAIABJAEQAIAB0AGgAYQB0ACAA aQBkAGUAbgB0AGkAZgBpAGUAcwAgAGUAdgBlAHIAeQAgAEoAUAAgAG0AZQBzAHMAYQBnAGUAIABz AGUAbgB0ACAAYgB5ACAAaQB0AC4ADQBUAGgAZQAgAHUAcABzAHQAcgBlAGEAbQAgAHIAbwB1AHQA ZQByACAAYwBvAHAAaQBlAHMAIAB0AGgAZQAgAFQATABWACAAaQBuAHQAbwAgAHQAaABlACAAQQBD AEsAIABQAEQAVQAgAGEAbgBkACAAdQBuAGkAYwBhAHMAdABzACAAaQB0ACAAYgBhAGMAawAgAHQA bwAgAHQAaABlACAAcwBlAG4AZABlAHIALgAAAKEPJgAAABEAAAAAAAAAAADcAAAAAQAAAAAAEQAA AAAAAADcAAAAAAQAAAAEAACqDxoAAADNAAAAAAAAAAkAAAABAAAAAwAXAAAAAAAAAAAA8wMUAAAA CgAAAAAAAAACAAAABgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFwAAAFNub29waW5nIGNvbnNpZGVy YXRpb25zEACfDwQAAAABAAAAAACoD3kBAABMMiBzd2l0Y2hlcyBzbm9vcCBvbiBQSU0gSlAgUERV cyB0byBjcmVhdGUgTDIgbXVsdGljYXN0IGZvcndhcmRpbmcgc3RhdGUuDVRoZSBsYXJnZXIgdGhl IHJlZnJlc2ggaW50ZXJ2YWwsIHRoZSBsb25nZXIgaXQgd2lsbCB0YWtlIGZvciBMMiBzd2l0Y2hl cyB0byBidWlsZCBzdGF0ZS4NTDIgc3dpdGNoZXMgY291bGQgcmVxdWVzdCBkb3duc3RyZWFtIHJv dXRlcnMgdG8gcmVmcmVzaCB0aGVpciBzdGF0ZSBieSBlaXRoZXINU2VuZGluZyBvdXQgYSBQSU0g UERVIChuZXcgUERVIHR5cGUpDVNldHRpbmcgR2VuSUQgdG8gemVybyBiZWZvcmUgZm9yd2FyZGlu ZyBhbnkgSGVsbG8gc2VlbiBmb3IgdGhlIGZpcnN0IHRpbWUgZnJvbSBhIHJvdXRlciBvbiB0aGUg TEFOLgAAoQ8qAAAA8QAAAAAAAAAAAIkAAAABAAAAAADxAAAAAAACABwAiQAAAAAEAgAABBgAAACq DywAAAAcAAAAAAAAAAUAAAABAAAAAwD9AAAAAAAAAAYAAAABAAAAAwBWAAAAAAAAAAAA6gMAAAAA AAByFwgAAAABABAAOSoAAAAA9Q8cAAAABQEAAJwKAAMVKgAAAj4AAAEAAAAKAAAAAQBDAA8A6APB EwAAAQDpAygAAACAFgAA4BAAAOAQAACAFgAABQAAAAoAAAAAAAAAAAAAAAEAAAAAAAABDwDyAxYB AAAvAMgPDAAAADAA0g8EAAAAAQAAAA8A1QdMAAAAAAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAg AFIAbwBtAGEAbgAAAEgn0QC01RMAnNUTAHbHCzAIAAAAAAAAALTVEwAo3Q0wAAAEAAAApA8KAAAA gABgAAAA/////wAApQ8MAAAAAAAACC4AAAAHAAAAAACpDwoAAAAHAAAAAgAJBAAAQACjD24AAAAF AP/9PwAAACIgAABkAAAAAAAAAGQAAAAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD///////8YAAAA AAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwSs AAAADwAA8KQAAAAAAAbwWAAAAAIoAAAKAAAAGwAAAAgAAAABAAAABwAAAAMAAAAEAAAABAAAAAQA AAAFAAAABAAAAAYAAAAEAAAAAAAAAAQAAAAHAAAABAAAAAgAAAAEAAAAAgAAAAQAAABjAAvwAQAA AAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAP7////+ /////v////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /zsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAB0AAAD///////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////+/wAA BQECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAAAABwAACwAAAAEAAABg AAAAAgAAAGgAAAAEAAAAfAAAAAgAAACIAAAACQAAAJQAAAASAAAAoAAAAAoAAADAAAAADAAAAMwA AAANAAAA2AAAAA8AAADkAAAAEQAAAOwAAAACAAAA5AQAAB4AAAAJAAAAUHJvYmxlbSAAACAAHgAA AAQAAAB3d3cAHgAAAAQAAAB3d3cAHgAAAAMAAAAxOAAAHgAAABUAAABNaWNyb3NvZnQgUG93ZXJQ b2ludAAAUABAAAAAMCOtaggAAABAAAAA8F2M2KAcxQFAAAAA8HoLY7UdxQEDAAAAnAEAAEcAAAAK BgAA/////wMAAAAIAIkQZwwAAAEACQAAA/0CAAAGACcAAAAAABEAAAAmBg8AGAD/////AAAQAAAA AAAAAAAAwAMAANACAAAJAAAAJgYPAAgA/////wIAAAAXAAAAJgYPACMA/////wQAGwBUTlBQFAAw AdEAMgAAAP//TwAUAAAATQBpAAAACgAAACYGDwAKAFROUFAAAAIA9AMJAAAAJgYPAAgA/////wMA AAAPAAAAJgYPABQAVE5QUAQADAABAAAAAQAAAAAAAAAFAAAACwIAAAAABQAAAAwC0ALAAwUAAAAE AQ0AAAAHAAAA/AIAAP///wAAAAQAAAAtAQAACAAAAPoCBQABAAAAAAAAAAQAAAAtAQEABAAAAC0B AAAJAAAAHQYhAPAA0ALAAwAAAAAEAAAALQEAAAcAAAD8AgAA////AAAABAAAAC0BAgAEAAAA8AEA AAgAAAD6AgAAAAAAAAAAAAAEAAAALQEAABAAAAAmBg8AFgD/////AABHAAAAjwIAABEBAADBAgAA CAAAACYGDwAGAP////8BABwAAAD7AgAAAAAAAAAAAAAAAAAAAAAAAADc8XdAAAAA3QgKG0DIEwDY n/N34Z/zdyAg9XesBmZEBAAAAC0BAwAFAAAACQIAAAACBQAAABQCAAAAAAUAAAACAQIAAAAQAAAA JgYPABYA/////wAARwEAAI8CAAB5AgAAwQIAAAgAAAAmBg8ABgD/////AQAFAAAACQIAAAACBQAA ABQCAAAAAAUAAAACAQIAAAAHAAAA/AIBAAAAAAAAAAQAAAAtAQQABAAAAC0BAQAHAAAAGwRpAXkD 8ABIAAQAAAAtAQIABAAAAC0BAAAFAAAACQIAAAACBQAAABQCAAAAABwAAAD7AsX/AAAAAAAAkAEA AAAAAEAAElRpbWVzIE5ldyBSb21hbgDYn/N34Z/zdyAg9XesBmZEBAAAAC0BBQAEAAAA8AEDAAUA AAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAnAAAAMgooAckAFQAAAFBJTSBS ZWZyZXNoIFJlZHVjdGlvbgAhABMANAAPACcAGgATABQAGgAXAB4ADwAnABkAHgAeABoAEAAQAB0A HgAFAAAALgEBAAAABQAAAAIBAgAAABwAAAD7AtX/AAAAAAAAkAEAAAAAAEAAElRpbWVzIE5ldyBS b21hbgDYn/N34Z/zdyAg9XesBmZEBAAAAC0BAwAEAAAA8AEFAAUAAAAJAgAAAAIFAAAAFAIAAAAA BQAAAC4BGAAAAAUAAAACAQEAAAASAAAAMgpfAQEBBwAAAFN1cmVzaCACGAAVAA4AEgARABUACwAF AAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEA AAAVAAAAMgpfAX8BCQAAAEJvZGRhcGF0aQAdABUAFQAVABMAFgATAAwADAAFAAAALgEBAAAABQAA AAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAJAAAAMgpfAS8C AQAAACwACwAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAA AAUAAAACAQEAAAASAAAAMgpfAUUCBwAAAEFsY2F0ZWwCHgAMABIAEwANABIADAAFAAAALgEBAAAA BQAAAAIBAgAAAAUAAAACAQIAAAAEAAAALQEEAAQAAAAtAQEABwAAABsEUQIxA5gBkAAEAAAALQEC AAQAAAAtAQAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAAAgECAAAABAAAAC0BAQAEAAAALQEEABwA AAD7AhAABwAAAAAAvAIAAAAAAQICIlN5c3RlbQBErAZmRAAACgAhAIoBAAAAAAUAAAA0zBMABAAA AC0BBQAEAAAA8AEDAA8AAAAmBg8AFABUTlBQBAAMAAAAAAAAAAAAAAAAAAkAAAAmBg8ACAD///// AQAAAAMAAAAAAAAAdgAUAAAAdGhlIHVwc3RyZWxhdGUAAwAAAAEAAAAeAAAADQAAAFNsaWRlIFRp dGxlcwADAAAACAAAAAAAEQAMAAkABQAAAC4BAQAAAAUAAAAAAPYPGwAAABQAAABfwJHjAW0AAAMA 9AMDANEAd3d3CAAAAHcAdwB3AAEBAAAACQAAADIKiAFSAAEAAACVAA0ABQAAAC4BAQAAAAUAAAAC AQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAASQAAADIKiAF2ACwA AABUaGUgbW9yZSB0aGUgbnVtYmVyIG9mIHN0YXRlcywgdGhlIG1vcmUgdGhlIBcAEwAQAAkAHQAS AA0AEAAKAAoAEwAQAAkAEwATAB0AEwAQAAwACgATAAwACQAPAAoAEQAKABEADgAJAAoACgATABAA CQAeABIADQAQAAkACgAUABAACgAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIA AAAABQAAAC4BGAAAAAUAAAACAQEAAABAAAAAMgq1AXYAJgAAAGNvbnRyb2wgdHJhZmZpYyByZXF1 aXJlZCBmb3IgcmVmcmVzaC4gEAASABMACwAMABMACgAJAAsADAARAAwADQAKABAACgAMABAAEwAU AAoADAARABIACgAMABMADAAKAAwAEQAMAA0AEAAOABMACQAJAAUAAAAuAQEAAAAFAAAAAgECAAAA BQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAAkAAAAyCusBUgABAAAAlQAN AAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIB AQAAAEUAAAAyCusBdgApAAAAU2NhbGluZyBiZWNvbWVzIGFuIGlzc3VlIGVzcGVjaWFsbHkgd2l0 aCCtFAARABEACgAJABQAEgAKABIAEQAQABIAHgAQAA8ACQAQABMACgAKAA8ADgATABAACgAQAA8A EgARABEACgARAAoACgASAAkAHAAKAAoAEwAJAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAA AgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAA8AAAAyCusB5AIFAAAAVlBOcyAAGwAVABsA DwAKAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAA AAIBAQAAABgAAAAyChgCdgALAAAAKGUuZy4gMTAwMCAADAAQAAoAEgAKAAkAEwATABMAEwAJAAUA AAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAA AA8AAAAyChgCFgEFAAAAVlBOcyAAGwAVABsADgAJAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkC AAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAADMAAAAyChgCeAEdAAAAd2l0aCAxMDAg ZW50cmllcyBlYWNoIGFuZCAxMCCXHAAJAAoAEwAJABMAEwATAAkAEAATAAoADQAKABEADgAJABEA EAAQABMACgAQABMAEwAJABMAEwAJAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAU AgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAFEAAAAyCkUCdgAxAAAAZG93bnN0cmVhbSBpbnRlcmZh Y2VzID0gMW1pbGxpb24gc3RhdGUgcmVmcmVzaGVzIAASABIAGwATAA8ACgANABAAEAAeAAoACQAT AAoAEQAMAA0AEAARABAADwAJABUACQATAB4ACgAKAAoACgASABQACQAPAAoAEAALABAACgAMABEA DAANABAADgATABEADgAKAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAF AAAALgEYAAAABQAAAAIBAQAAADQAAAAyCnECdgAeAAAAZXZlcnkgbWludXRlIGluIHN0ZWFkeSBz dGF0ZSkuEAATABAADQASAAkAHgAJABMAEwALABAACgAJABMACgAOAAsAEAARABMAEgAJAA8ACgAQ AAsAEAANAAkABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgECAAAABAAAAC0BAQAEAAAALQEEABwA AAD7AhAABwAAAAAAvAIAAAAAAQICIlN5c3RlbQAZHwxmGQAACgAhAIoBAAAAAAUAAADA9RMABAAA AC0BBQAEAAAA8AEDAA8AAAAmBg8AFABUTlBQBAAMAAAAAAAAAAAAAAAAAAkAAAAmBg8ACAD///// AQAAAAMAAAAAAAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAAfAIAABAA AAABAAAAiAAAAAMAAACQAAAADwAAAKgAAAAEAAAAuAAAAAYAAADAAAAABwAAAMgAAAAIAAAA0AAA AAkAAADYAAAACgAAAOAAAAAXAAAA6AAAAAsAAADwAAAAEAAAAPgAAAATAAAAAAEAABYAAAAIAQAA DQAAABABAAAMAAAAGgIAAAIAAADkBAAAHgAAAA8AAABPbi1zY3JlZW4gU2hvdwAAHgAAAAUAAAAg d3d3AHJlZQMAAAAlbQAAAwAAACAAAAADAAAACAAAAAMAAAAAAAAAAwAAAAAAAAADAAAAAAAAAAMA AADtDgkACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAACgAAABAAAABUaW1lcyBO ZXcgUm9tYW4ADwAAAERlZmF1bHQgRGVzaWduADAAAABQSU0gUmVmcmVzaCBSUgBvAG8AdAAgAEUA bgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH/ /////////wMAAAAQjYFkm0/PEYbqAKoAuSnoAAAAAAAAAAAAAAAAYP7zlusdxQE8AAAAABEAAAAA AABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAGgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAB4AAAApAAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAADAHAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBj AHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAABAAAAP////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJW0AAAAAAAABAAAAAgAAAAMAAAAE AAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIA AAATAAAAFAAAABUAAAAxAAAA/////xgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAA ACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAD+//// ////////////////MgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAFwAAAP////89 AAAAPgAAAEoAAAD//////////0IAAABIAAAA/////0cAAAD9/////v////7///9JAAAA/v///0sA AABBAAAA//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////wEAAAACAAAAAwAAAAQA AAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAA ABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAD+////HwAAAP7///8gAAAA IQAAACIAAAAjAAAAJAAAACUAAAD+//////////////////////////////////////////////// //////////////////////////////////////////////////////////////87AAAAPAAAAD0A AAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAAAdAAAA//////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////BQBEAG8AYwB1AG0AZQBu AHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA6AAAAcAQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAAwPUTAAQAAAAtAQUA BAAAAPABAwAPAAAAJgYPABQAVE5QUAQADAAAAAAAAAAAAAAAAAAJAAAAJgYPAAgA/////wEAAAAD AAAAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/ AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cI ACss+a7AAgAAfAIAABAAAAABAAAAiAAAAAMAAACQAAAADwAAAKgAAAAEAAAAuAAAAAYAAADAAAAA BwAAAMgAAAAIAAAA0AAAAAkAAADYAAAACgAAAOAAAAAXAAAA6AAAAAsAAADwAAAAEAAAAPgAAAAT AAAAAAEAABYAAAAIAQAADQAAABABAAAMAAAAGgIAAAIAAADkBAAAHgAAAA8AAABPbi1zY3JlZW4g U2hvdwAAHgAAAAUAAAAgd3d3AHJlZQMAAAAlbQAAAwAAACAAAAADAAAACAAAAAMAAAAAAAAAAwAA AAAAAAADAAAAAAAAAAMAAADtDgkACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAA CgAAABAAAABUaW1lcyBOZXcgUm9tYW4ADwAAAERlZmF1bHQgRGVzaWduADAAAABQSU0gUmVmcmVz aCBSZWR1Y3Rpb24gU3VyZXNoIEJvZGRhcGF0aSwgQWxjYXRlbAAIAAAAUHJvYmxlbQARAAAAUHJv YmxlbSAoY29udGQuKQAhAAAAV2h5IG5vdCB1c2UgVENQIGZvciByZWxpYWJpbGl0eT8ACQAAAFNv bHV0aW9uABgAAABBY2tub3dsZWRnZW1lbnQgc2NoZW1lcwAYAAAAQWNrbm93bGVkZ2VtZW50IFNj aGVtZXMAGAAAAFNub29waW5nIGNvbnNpZGVyYXRpb25zAAwQAAAGAAAAHgAAAAsAAABGb250cyBV c2VkAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuARgAAAAFAAAAAgEBAAAA EgAAADIKXwFFAgcAAABBbGNhdGVsAh4ADAASABMADQASAAwABQAAAC4BAQAAAAUAAAACAQIAAAAF AAAAAgECAAAABAAAAC0BBAAEAAAALQEBAAcAAAAbBFECMQOYAZAABAAAAC0BAgAEAAAALQEAAAUA AAAJAgAAAAIFAAAAFAIAAAAABQAAAAIBAgAAAAQAAAAtAQEABAAAAC0BBAAcAAAA+wIQAAcAAAAA ALwCAAAAAAECAiJTeXN0ZW0ARKwGZkQAAAoAIQCKAQAAAAAFAAAANMwTAAQAAAAtAQUABAAAAPAB AwAPAAAAJgYPABQAVE5QUAQADAAAAAAAAAAAAAAAAAAJAAAAJgYPAAgA/////wEAAAADAAAAAAAA AHYAFAAAAHRoZSB1cHN0cmUAHgAAABAAAABEZXNpZ24gVGVtcGxhdGUAAwAAAAEAAAAeAAAADQAA AFNsaWRlIFRpdGxlcwADAAAACAAAAAAAAAD2DxsAAAAUAAAAX8CR4wFtAAADAPQDAwDRAHd3dwgA AAB3AHcAdwABAQAAAAkAAAAyCogBUgABAAAAlQANALABAAAHAAAAAAAAAEAAAAABAAAA9AAAAAAA AID8AAAAAgAAAAQBAAADAAAADAEAAAQAAABAAQAABQAAAIQBAAAEAAAAAgAAABQAAABfAEEAZABI AG8AYwBSAGUAdgBpAGUAdwBDAHkAYwBsAGUASQBEAAAAAwAAAA4AAABfAEUAbQBhAGkAbABTAHUA YgBqAGUAYwB0AAAABAAAAA0AAABfAEEAdQB0AGgAbwByAEUAbQBhAGkAbAAAAAAABQAAABgAAABf AEEAdQB0AGgAbwByAEUAbQBhAGkAbABEAGkAcwBwAGwAYQB5AE4AYQBtAGUAAAACAAAAsAQAABMA AAAJBAAAAwAAAE6JScQfAAAAFQAAAFsAUABpAG0ALQBzAHQAYQB0AGUAXQAgAFMAdQBtAG0AYQBy AHkAIAAAAAAAHwAAAB0AAABzAHUAcgBlAHMAaAAuAGIAbwBkAGQAYQBwAGEAdABpAEAAYQBsAGMA YQB0AGUAbAAuAGMAbwBtAAAAAAAfAAAAEQAAAFMAdQByAGUAcwBoACAAQgBvAGQAZABhAHAAYQB0 AGkAAAAAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAJAAAAMgrrAVIAAQAAAJUADQAFAAAALgEBAAAA BQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAABFAAAAMgrr AXYAKQAAAFNjYWxpbmcgYmVjb21lcyBhbiBpc3N1ZSBlc3BlYw== ------=_NextPart_000_02CD_01C51DA8.8A687560-- From mmcbride@cisco.com Tue Mar 1 19:11:37 2005 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j220BarK003796 for ; Tue, 1 Mar 2005 19:11:36 -0500 (EST) (envelope-from mmcbride@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 01 Mar 2005 16:24:13 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j220BNq8016467; Tue, 1 Mar 2005 16:11:24 -0800 (PST) Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BCH83031; Tue, 1 Mar 2005 16:11:27 -0800 (PST) Date: Tue, 1 Mar 2005 16:11:27 -0800 (PST) From: Mike McBride To: Suresh Boddapati Subject: RE: [Pim-state] Summary In-Reply-To: <02cc01c51deb$988bb560$4abb16ac@alcatelxp> Message-ID: References: <02cc01c51deb$988bb560$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 02 Mar 2005 00:11:43 -0000 Suresh, They look good, thanks for taking the time. We'll give you a full report after ietf week. mike On Mon, 28 Feb 2005, Suresh Boddapati wrote: > Here are the slides I promised. I have summarized the progress made so > far. Please feel free to make any edits as you deem necessary. I wont be > attending the IETF meet this time. I look forward to the minutes. > > Suresh > > > > > -----Original Message----- > > From: Mike McBride [mailto:mmcbride@cisco.com] > > Sent: Friday, February 25, 2005 10:27 PM > > To: Suresh Boddapati > > Cc: 'Tom Pusateri'; 'Robert Kebler'; pim-state@mountain2sea.com > > Subject: RE: [Pim-state] Summary > > > > A few slides would be appreciated. You've already come up with a good > > summary of the brainstorming you've done on this list. I think we can > say > > we've done due diligence to come up with a few solutions to pim > refresh > > reduction if its deemed necessary. Tom and I can give an update during > the > > pim wg. But at this point we should probably keep this between the wg > > chairs. After emails from Tom and I to the l3vpn wg chairs, we still > > haven't heard back from them on what exactly they want us to > accomplish > > with refresh reduction. They need to give us clear requirements, > rather > > than simply state pim wg needs to solve the pim refresh problem. What > > problem? Once we understand the requirements, we can decide if we > should > > start submitting drafts (if an ACK mechanism is the way to go, if we > need > > a more robust TCP solution, etc) or if pimv2 is fine as is. > > > > thanks, > > mike > > > > On Fri, 25 Feb 2005, Suresh Boddapati wrote: > > > > > I will try to make some slides with the summary and send it out to > the > > > list. > > > I am not sure if I am going to Minnesota yet. Either way, there will > be > > > some Alcatel representation. Is this meeting separate from the > design > > > team progress presentation that Tom/Mike are making? > > > > > > I will try to get the slides out to the group sometime next week. > > > > > > Suresh > > > > > > > -----Original Message----- > > > > From: pim-state-bounces@mountain2sea.com [mailto:pim-state- > > > > bounces@mountain2sea.com] On Behalf Of Tom Pusateri > > > > Sent: Friday, February 25, 2005 1:52 PM > > > > To: Robert Kebler > > > > Cc: pim-state@mountain2sea.com > > > > Subject: Re: [Pim-state] Summary > > > > > > > > Yes. This is a good idea. Is anyone willing to summarize the > current > > > > state of things (pun intended) with a few slides to the working > group? > > > > > > > > Tom > > > > > > > > In message <4.2.0.58.20050225140719.00d98710@mailhost.avici.com> > you > > > > write: > > > > >Is there any interest to meet together in person in Minnesota to > try > > > > >to resolve any issues we have? I think this would be very > > > productive. > > > > > > > > > >-Bob > > > > > > > > > > > > > > > > > > > >>Date: Mon, 07 Feb 2005 14:07:19 -0500 > > > > >>To: pim-state@mountain2sea.com > > > > >>From: Robert Kebler > > > > >>Subject: Re: [Pim-state] Summary > > > > >> > > > > >>Here are my opinions on the topics which have been discussed: > > > > >> > > > > >>I think we should use the existing JP messages to refresh the > state. > > > > >>I think it is really up to the implementation what to use as a > > > default > > > > >>holdtime (no inter-operability issues) and the user to decide > what > > > to > > > > >>configure. If we really want to give a default, then I would > say > > > > >>MAX_HOLDTIME. > > > > >> > > > > >>I like the idea of having some sort of "Sequence Number" or > > > > >>"Message ID" to Acknowledge. I think the best idea is to have > > > > >>a separate spec that gives a generic method of encoding a TLV > > > > >>at the end of a JP message. The first application of this will > be > > > > >>to encode a "Message ID" in the JP message. I don't see the > > > > >>need to have both a Message ID and Sequence Number. All > > > > >>we really need is one 32-bit number. > > > > >> > > > > >>I think we need a method to request JP state. If we are going > to > > > allow > > > > >>no refreshes at all, I think it makes sense that we have some > way of > > > > >>requesting JP State. > > > > >> > > > > >>I like Explicit Tracking. If we do Explicit Tracking then a > > > downstream > > > > route > > > > >r > > > > >>does not always need to parse the JP messages intended for > another > > > > router. > > > > >> > > > > >>-Bob > > > > >> > > > > >> > > > > >>At 03:14 PM 2/4/05 -0800, Suresh Boddapati wrote: > > > > >>>Trying to summarize the discussions that we had so far > > > > >>>on the list: > > > > >>> > > > > >>>1) To refresh or not: It seems like it is acceptable > > > > >>>to most of us to live with refreshes if refreshes are > > > > >>>done at a large interval (an hour or more). Adding > > > > >>>reliability gives the flexibility to do refreshes at > > > > >>>large intervals (assuming the intervals are jittered > > > > >>>so that all states do not refresh at the same time). > > > > >>>Using the existing JP messages to refresh instead of > > > > >>>using a new PDU Type seems to be acceptable as well. > > > > >>>Users can tweak the holdtime to get the refresh > > > > >>>behavior they desire. > > > > >>> > > > > >>>2) How to achieve reliability: Everyone agrees there > > > > >>>should be an ACK mechanism. There are two schemes > > > > >>>here: > > > > >>>a) Dino's scheme: Have a bit per state, the intended > > > > >>>recipient turns back the JP PDU into a new PDU type > > > > >>>and does the Acking. Back to back changes to a state > > > > >>>was pointed out as an issue. Dino's take is we could > > > > >>>use the Reserved field in the JP PDU and use it as seq > > > > >>>num. > > > > >>>b) Use a Message ID TLV for Acking. The TLV has a > > > > >>>sequence number, and is sent along with the JP PDU. > > > > >>>The intended recipient acks using the Message ID TLV > > > > >>>in a new PDU type. Back to back changes to states > > > > >>>corresponding to a Message ID while it is pending ack > > > > >>>causes the seq. num to bump up and the union of the > > > > >>>old and new states is sent out. Once the latest > > > > >>>Message ID is acked, the Message ID can be deleted. > > > > >>>(Note this is a deviation from my original proposal. > > > > >>>Now Message ID is being used only for acking). > > > > >>> > > > > >>>3)Snooping: On demand request for states was > > > > >>>mentioned. But if we are going to refresh at sometime, > > > > >>>even if it is an hour, we dont need this. > > > > >>> > > > > >>>Is there anything else I have missed? Comments? > > > > >>> > > > > >>>Suresh > > > > >>> > > > > >>>_______________________________________________ > > > > >>>Pim-state mailing list > > > > >>>Pim-state@mountain2sea.com > > > > >>>http://www.mountain2sea.com/mailman/listinfo/pim-state > > > > > > > > > >_______________________________________________ > > > > >Pim-state mailing list > > > > >Pim-state@mountain2sea.com > > > > >http://www.mountain2sea.com/mailman/listinfo/pim-state > > > > _______________________________________________ > > > > Pim-state mailing list > > > > Pim-state@mountain2sea.com > > > > http://www.mountain2sea.com/mailman/listinfo/pim-state > > > > > > _______________________________________________ > > > Pim-state mailing list > > > Pim-state@mountain2sea.com > > > http://www.mountain2sea.com/mailman/listinfo/pim-state > > > > From rkebler@avici.com Sun Mar 6 22:37:48 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j273bjaX009106 for ; Sun, 6 Mar 2005 22:37:48 -0500 (EST) (envelope-from rkebler@avici.com) Received: from webmail.avici.com (mailhost.avici.com [127.0.0.1]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id j273bc7k026092; Sun, 6 Mar 2005 22:37:38 -0500 Received: from 10.2.2.223 (SquirrelMail authenticated user rkebler) by webmail.avici.com with HTTP; Sun, 6 Mar 2005 22:37:38 -0500 (EST) Message-ID: <52959.10.2.2.223.1110166658.squirrel@webmail.avici.com> Date: Sun, 6 Mar 2005 22:37:38 -0500 (EST) From: rkebler@avici.com To: pim-state@mountain2sea.com User-Agent: SquirrelMail/1.4.0-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: Subject: [Pim-state] PIM refresh reduction writeup X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 07 Mar 2005 03:37:49 -0000 Here is a quick writeup on what I would like to have for the PIM Refresh Reduction. This is meant to be a collection of ideas, most of which have been discussed in one thread or another. I have included Dino's explicit tracking and Suresh's JP TLV idea. I didn't really have time tonight to write this up in more detail but I can do that over the next day or so. Any thoughts or opinions would be much appreciated. I'm in Minneapolis if anybody wants to discuss this topic. Thanks, Bob ###################################################################### A new Hello Option will indicate if a PIM router implements this draft. Reliable PIM JP messages will be unicast to the upstream router if the upstream router supports this draft. Otherwise the existing JP messages will be sent. The upstream routers that implement this draft will keep track of all downstream routers which have joined (explicit tracking) so there will be no Join Suppressions or Prune Overrides. The Reliable JP messages will be unicast because the other downstream routers will have no use of receiving these messages. To make the JP messages reliable, a 32-bit sequence number will be added to the JP messages. For this, we can create a new JP message type that has a 32 bit sequence number or we can encode the sequence number at the end of the existing JP message (Suresh's JP TLV idea). Upstream routers will send a new JP ACK message with the 32-bit sequence number that it is ACKing. Multiple sequence numbers can be included in the same message. Downstream routers will retransmit the JP message (with exponential backoff) until the message is ACKed. Although there will be no need for refreshes, the holdtime field will be maintained in the Reliable JP messages. If the holdtime is set to MAX_HOLDTIME (0xffff), then the entries will not be refreshed or timed out. If the holdtime is set to anything else, then the entries will be refreshed periodically and removed if the holdtime expires. Legacy PIM Routers can coexist with PIM routers implementing this draft. The JP messages that the legacy routers send and receive will be the same. The new Reliable JP messages are only sent by routers implementing this draft to routers that are sending the new hello option. Upstream nodes implementing this draft will be able to receive legacy JP messages and treat them as defined in the PIM base spec. The only difference will be when the legacy Join State time out, the outgoing interface will only be removed if there are no other (reliable) joiners on the interface. That is, the upstream routers can treat the collection of legacy downstream routers like one downstream router that is being explicitly tracked. From tian@redback.com Mon Mar 7 18:07:37 2005 Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j27N7bbA011218 for ; Mon, 7 Mar 2005 18:07:37 -0500 (EST) (envelope-from tian@redback.com) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id E68E413627C9; Mon, 7 Mar 2005 15:07:25 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05808-04; Mon, 7 Mar 2005 15:07:25 -0800 (PST) Received: from oslo.redback.com (oslo.redback.com [155.53.44.173]) by prattle.redback.com (Postfix) with ESMTP id 210AC13627C7; Mon, 7 Mar 2005 15:07:25 -0800 (PST) Subject: Re: [Pim-state] Summary From: Albert Tian To: Dino Farinacci In-Reply-To: <200502252229.j1PMT2sn011632@dino-lnx.cisco.com> References: <200502252151.j1PLpte80165@merlot.juniper.net> <200502252229.j1PMT2sn011632@dino-lnx.cisco.com> Content-Type: text/plain Message-Id: <1110236844.5161.2107.camel@oslo.redback.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 07 Mar 2005 15:07:25 -0800 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Mon, 07 Mar 2005 23:07:37 -0000 Hi Dino/Tom/Mike/Suresh, Here are a few issues that were not mentioned in the summary: - One other problem for the TCP based solution is that for MVPN, each of the PIM peering between C-instances would require a seperate TCP connection. One could device a solution that introduces VPN address families for multicast so that the TCP connections can be shared, but that would require more change in the protocol. - Prune override no longer works (therefore join supression does not work either) , because there is no guarantee that the prune from one downstream neighbor is delivered to the other downstream neighbor(s) that need(s) to override it. There are several ways to fix it, but the simplest IMHO is to enable explicit tracking and disable Join suppression. For example U is the upstream and D1,D2 are two downstream neighbors. Both D1 and D2 joined group G, not D1 send out a prune. It is possible that the prune and ack for prune are delivered to U, but not D2. U would prune the oif to D1/D2 while D2 is still in the Group. - Recovery from failed neighbor. All PIM entries learned from that neighbor must be removed. The upstream can either immediately remove them, or start the Expiry Timers with shorter durations and let the timeout process handle it. - Recovery from one way communication failure. In this scenario, say two neighbors X and Y, only X->Y direction is failing. Y will timeout X and delete all the PIM entries learned from X, without X knowing about it. So there needs a way for Y to tell X that it has lost neighbor X, so that X can retransmit all its entries once the failure goes away. One solution (from Dino) is for Y to unicast a hello with GenId 0 to X to request a refresh. This hello likely needs an Ack of some form. - A checksum based approach was mentioned, any progress over there? I can put these points in a few slides. I will attend this IETF (I wasn't sure if I can make it till today). As one of the co-authors of the JP Ack solution/draft, I could help presentating the JP Ack approach, if needed. Thanks, Albert On Fri, 2005-02-25 at 14:29, Dino Farinacci wrote: > >> Yes. This is a good idea. Is anyone willing to summarize the current > >> state of things (pun intended) with a few slides to the working group? > > Since I won't be ablt to attend the IETF, I will brief some of the cisco > guys. I think Mike (and you) were suppose to present that. > > Dino > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state From tian@redback.com Mon Mar 7 20:27:42 2005 Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j281RfAR011430 for ; Mon, 7 Mar 2005 20:27:41 -0500 (EST) (envelope-from tian@redback.com) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id BB89E129FD5F; Mon, 7 Mar 2005 17:27:23 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08121-09; Mon, 7 Mar 2005 17:27:23 -0800 (PST) Received: from oslo.redback.com (oslo.redback.com [155.53.44.173]) by prattle.redback.com (Postfix) with ESMTP id DCE00129FD61; Mon, 7 Mar 2005 17:27:22 -0800 (PST) Subject: Re: [Pim-state] Summary From: Albert Tian To: Dino Farinacci In-Reply-To: <1110236844.5161.2107.camel@oslo.redback.com> References: <200502252151.j1PLpte80165@merlot.juniper.net> <200502252229.j1PMT2sn011632@dino-lnx.cisco.com> <1110236844.5161.2107.camel@oslo.redback.com> Content-Type: multipart/mixed; boundary="=-fggLqmFBm/xMVhu4F/77" Message-Id: <1110245242.5161.3136.camel@oslo.redback.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 07 Mar 2005 17:27:22 -0800 X-Virus-Scanned: by amavisd-new at redback.com Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Mar 2005 01:27:42 -0000 --=-fggLqmFBm/xMVhu4F/77 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, Here are some slides regarding the points I raised. Thanks, Albert On Mon, 2005-03-07 at 15:07, Albert Tian wrote: > Hi Dino/Tom/Mike/Suresh, > > Here are a few issues that were not mentioned in the summary: > > - One other problem for the TCP based solution is that for MVPN, each of > the PIM peering between C-instances would require a seperate TCP > connection. One could device a solution that introduces VPN address > families for multicast so that the TCP connections can be shared, but > that would require more change in the protocol. > > - Prune override no longer works (therefore join supression does not > work either) , because there is no guarantee that the prune from one > downstream neighbor is delivered to the other downstream neighbor(s) > that need(s) to override it. There are several ways to fix it, but the > simplest IMHO is to enable explicit tracking and disable Join > suppression. For example U is the upstream and D1,D2 are two downstream > neighbors. Both D1 and D2 joined group G, not D1 send out a prune. It is > possible that the prune and ack for prune are delivered to U, but not > D2. U would prune the oif to D1/D2 while D2 is still in the Group. > > - Recovery from failed neighbor. All PIM entries learned from that > neighbor must be removed. The upstream can either immediately remove > them, or start the Expiry Timers with shorter durations and let the > timeout process handle it. > > - Recovery from one way communication failure. In this scenario, say two > neighbors X and Y, only X->Y direction is failing. Y will timeout X and > delete all the PIM entries learned from X, without X knowing about it. > So there needs a way for Y to tell X that it has lost neighbor X, so > that X can retransmit all its entries once the failure goes away. One > solution (from Dino) is for Y to unicast a hello with GenId 0 to X to > request a refresh. This hello likely needs an Ack of some form. > > - A checksum based approach was mentioned, any progress over there? > > > I can put these points in a few slides. > > I will attend this IETF (I wasn't sure if I can make it till today). > > As one of the co-authors of the JP Ack solution/draft, I could help > presentating the JP Ack approach, if needed. > > Thanks, > > Albert > > On Fri, 2005-02-25 at 14:29, Dino Farinacci wrote: > > >> Yes. This is a good idea. Is anyone willing to summarize the current > > >> state of things (pun intended) with a few slides to the working group? > > > > Since I won't be ablt to attend the IETF, I will brief some of the cisco > > guys. I think Mike (and you) were suppose to present that. > > > > Dino > > _______________________________________________ > > Pim-state mailing list > > Pim-state@mountain2sea.com > > http://www.mountain2sea.com/mailman/listinfo/pim-state --=-fggLqmFBm/xMVhu4F/77 Content-Disposition: attachment; filename=pim-redu-sum.ppt Content-Type: application/vnd.ms-powerpoint; name=pim-redu-sum.ppt Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA EAAAFAAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////HgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAHwAAAP7///8WAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA AP7////+////IAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAALwAAADAAAAAxAAAA/v////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAADDFB1p9I8UB FQAAAMAQAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAACAAAAqUgAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADUDQAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAAAFgCAAAAAAAADwDo A+kJAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAAAQAAAAAAAAEPAPID FgEAAC8AyA8MAAAAMADSDwQAAAABAAAADwDVB0wAAAAAALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3 ACAAUgBvAG0AYQBuAAAADDS4AGjWEgBQ1hIA7KAHMAgAAAAAAAAAaNYSAFdvDTAAAAQAAACkDwoA AACBAGAAAQD/////AAClDwwAAAAAAAAILgAAAAcAAAAAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAA AAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAP///////xgA AAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwAL BLAAAAAPAADwqAAAAAAABvBQAAAACyAAAAkAAAAjAAAABQAAAAEAAAAHAAAAAAAAAAgAAAAAAAAA BgAAAAAAAAAEAAAAAwAAAAQAAAAEAAAAEgAAAAUAAAAEAAAABgAAAAsAAABjAAvwJAAAAIEBBAAA CIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACBAAGvEEAAAA/wAAAEAAHvEQAAAABAAACP8A AAACAAAI9wAAEB8A8A8cAAAAAADzAxQAAAACAAAAAAAAAAAAAAAAAACAAAAAAA8A0Ac3AQAAHwD/ AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8AFAQcAAAAAAAVBBQAAAC6HXXsAMqaOzJOzckAypo7 AQEAAQ8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAAEMAAABkAAAAQwAAAGQAAADsoAcwCAAAAAAA AABc1hIAAAAAAAAAAACs////Cv///wEAAABwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsA AB8ABwQ8AAAAAAD9AzQAAAAhAAAAZAAAACEAAABkAAAArn8NMBjaEgAAAAAA+DS4AAAAAAAAAAAA AAAAAAAAAAAAARIAHwATBDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQAAACufw0wGNoSAAAAAAD4 NLgAAAAAAAAAAAAAAAAAAAAAAAABEgAPAPAPcAYAAAAA8wMUAAAAAwAAAAAAAAACAAAAAAEAAAAA AAAAAJ8PBAAAAAAAAAAAAKgPIAAAAEFuIElzc3VlIHdpdGggVENQIEJhc2VkIFNvbHV0aW9uEACf DwQAAAABAAAAAACoDw0BAABJbiBNVlBOIGFwcGxpY2F0aW9uLCBlYWNoIFBJTSBwZWVyaW5nIGJl dHdlZW4gQy1pbnN0YW5jZXMgd291bGQgcmVxdWlyZSBhIHNlcGFyYXRlIFRDUCBjb25uZWN0aW9u DVZQTiBhZGRyZXNzIGZhbWlseSBjYW4gYmUgaW50cm9kdWNlZCB0byBtdWx0aWNhc3QgdG8gYWxs b3cgVENQIGNvbm5lY3Rpb25zIGJldHdlZW4gUC1pbnN0YW5jZXMgdG8gYmUgc2hhcmVkIGFtb25n IEMtaW5zdGFuY2VzLCBidXQgdGhhdCByZXF1aXJlIG1vcmUgY2hhbmdlIGluIHRoZSBwcm90b2Nv bAAA8wMUAAAABAAAAAQAAAACAAAAAQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPHAAAAFBydW5lIE92 ZXJyaWRlIERvZXMgTm90IFdvcmsQAJ8PBAAAAAEAAAAAAKgPAgEAAFUgaXMgdGhlIHVwc3RyZWFt IGFuZCBEMS9EMiBhcmUgdHdvIGRvd25zdHJlYW0gbmVpZ2hib3JzLiBCb3RoIEQxL0QyIGpvaW5l ZCBncm91cCBHLiBJdCBpcyBwb3NzaWJsZSB0aGF0IHBydW5lIGZyb20gRDEgYW5kIHRoZSBwcnVu ZSBBY2sgZnJvbSBVIGFyZSBub3QgcmVjZWl2ZWQgYnkgRDIuIFUgd291bGQgcHJ1bmUgdGhlIG9p ZiB0b3dhcmRzIEQxL0QyLg1Kb2luIHN1cHByZXNzaW9uIGRvZXMgbm90IHdvcmsNTmVlZCBleHBs aWNpdCB0cmFja2luZwAAoQ8UAAAAAwEAAAAAAAAAAAMBAAAAAAIAHAAAAKoPLAAAAIUAAAAAAAAA BAAAAAEAAAADADEAAAAAAAAABAAAAAEAAAADAEUAAAAAAAAAAADzAxQAAAAFAAAAAAAAAAIAAAAC AQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8eAAAAUmVjb3ZlcnkgZnJvbSBOZWlnaGJvciBGYWlsdXJl AACqDxIAAAAeAAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgPwAAAAEFsbCBQSU0gZW50 cmllcyBsZWFybmVkIGZyb20gdGhlIGZhaWxlZCBuZWlnaGJvciBtdXN0IGJlIHJlbW92ZWQuIA1U aGUgdXBzdHJlYW0gY2FuIGVpdGhlciBpbW1lZGlhdGVseSByZW1vdmUgdGhlIFBJTSBlbnRyaWVz LCBvciBzdGFydCB0aGUgRXhwaXJ5IFRpbWVyIGFuZCBsZXQgdGhlIHRpbWVvdXQgaGFuZGxlIHRo ZSByZW1vdmFsLgAA8wMUAAAABgAAAAQAAAACAAAAAwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPHQAA AFJlY292ZXJ5IGZyb20gT25lIFdheSBGYWlsdXJlEACfDwQAAAABAAAAAACoD0wBAABUd28gbmVp Z2hib3IgWCBhbmQgWS4gSWYgb25seSBYIHRvIFkgZGlyZWN0aW9uIGlzIGZhaWxpbmcsIFkgY291 bGQgdGltZW91dCBhbmQgcmVtb3ZlIGFsbCBQSU0gZW50cmllcyBsZWFybmVkIGZyb20gWCwgd2l0 aG91dCBYIGtub3dpbmcgYWJvdXQgaXQuDU5lZWQgYSB3YXkgZm9yIFkgdG8gaW5mb3JtIFggdGhh dCBpdCBoYXMgbG90IHRoZSBuZWlnaGJvciBhbmQgcmVxdWVzdCBhIHJlZnJlc2guDU9uZSBzb2x1 dGlvbiBmcm9tIERpbm8gaXMgdG8gbGV0IFkgdG8gc2VuZCBhIHVuaWNhc3QgaGVsbG8gd2l0aCBH ZW5JZCAwIHRvIFguIFRoaXMgaGVsbG8gbWF5IG5lZWQgYW4gQWNrLgAAoQ8WAAAATQEAAAAAABAA AFoATQEAAAAAAgAcAAAAqg8+AAAAEAEAAAAAAAAIAAAAAQAAAAMACwAAAAAAAAAGAAAAAQAAAAMA HwAAAAAAAAADAAAAAQAAAAMAAgAAAAAAAAAAAOoDAAAAAA8A+AOiCAAAAgDvAxgAAAABAAAAAQIH CQgAAAAAAAAAAAAAAAAAAABgAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIA YADwByAAAAAAAP8A////AAAAAAD//wAA/5kAAAD//wD/AAAAlpaWAGAA8AcgAAAA///MAAAAAABm ZjMAgIAAADOZMwCAAAAAADPMAP/MZgBgAPAHIAAAAP///wAAAAAAMzMzAAAAAADd3d0AgICAAE1N TQDq6uoAYADwByAAAAD///8AAAAAAICAgAAAAAAA/8xmAAAA/wDMAMwAwMDAAGAA8AcgAAAA//// AAAAAACAgIAAAAAAAMDAwAAAZv8A/wAAAACZAABgAPAHIAAAAP///wAAAAAAgICAAAAAAAAzmf8A mf/MAMwAzACysrIAAACjDz4AAAABAP/9PwAAACIgAABkAAAAAAABAGQAAAAAAAAAAABAAgAAAAAH AAAA///vAAAAAAD///////8sAAAAAAMAABAAow98AAAABQD//T8AAQAiIAAAZAAAAAAAAABkABQA AADYAAAAQAIAAAAABwAAAP//7wAAAAAA////////IAAAAAABAACABQAAEyDUASABAAACABwAgAUA ACIg0AJAAgAAAgAYAIAFAAATIPADYAMAAAIAFACABQAAuwAQBYAEAAAAACAAow9uAAAABQD//T8A AAAiIAAAZAAAAAAAAABkAB4AAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA////////DAAAAAABAAAA BQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAABQAKMPUgAAAAUA AAABCQAAAAABAAAAAAAAAAEAAQkAAAAAAQAgAQAAAAACAAEJAAAAAAEAQAIAAAAAAwABCQAAAAAB AGADAAAAAAQAAQkAAAAAAQCABAAAAABgAKMPDAAAAAEAAAAAAAAAAAAAAHAAow8+AAAABQAAAAAA AAAAAAIAHAABAAAAAAAAAAIAGAACAAAAAAAAAAIAFAADAAAAAAAAAAIAEgAEAAAAAAAAAAIAEgCA AKMPPgAAAAUAAAAAAAAAAAACABgAAQAAAAAAAAACABQAAgAAAAAAAAACABIAAwAAAAAAAAACABAA BAAAAAAAAAACABAADwAMBNwEAAAPAALw1AQAABAACPAIAAAABgAAAAYEAAAPAAPwbAQAAA8ABPAo AAAAAQAJ8BAAAAD19fX19fX19fX19fX19fX1AgAK8AgAAAAABAAABQAAAA8ABPDSAAAAEgAK8AgA AAACBAAAAAoAAJMAC/A2AAAAfwABAAEAgADQhbgAhwABAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEB AAAI/wEBAAkAAQICAAAIAAAQ8AgAAACAAbAB0BRQBA8AEfAQAAAAAADDCwgAAAAAAAAAAQC4AA8A DfBUAAAAAACfDwQAAAAAAAAAAACoDyAAAABDbGljayB0byBlZGl0IE1hc3RlciB0aXRsZSBzdHls ZQAAog8GAAAAIQAAAAAAAACqDwoAAAAhAAAAAQAAAAAADwAE8BYBAAASAArwCAAAAAMEAAAACgAA gwAL8DAAAAB/AAEAAQCAAICIuACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgA ABDwCAAAAOAEsAHQFAAPDwAR8BAAAAAAAMMLCAAAAAEAAAACALgADwAN8J4AAAAAAJ8PBAAAAAEA AAAAAKgPUgAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRleHQgc3R5bGVzDVNlY29uZCBsZXZlbA1U aGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlmdGggbGV2ZWwAAKIPHgAAACEAAAAAAA0AAAABAAwA AAACAA0AAAADAAwAAAAEAAAAqg8KAAAAUwAAAAEAAAAAAA8ABPC4AAAAEgAK8AgAAAAEBAAAAAoA AIMAC/AwAAAAfwABAAEAgABcjbgAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAI AAAQ8AgAAABgD7ABYAaAEA8AEfAQAAAAAADDCwgAAAACAAAABwG4AA8ADfBAAAAAAACfDwQAAAAE AAAAAACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAAKAAcAAgAAAAAAAgAOAAAA+A8EAAAAAAAAAA8A BPC6AAAAEgAK8AgAAAAFBAAAAAoAAIMAC/AwAAAAfwABAAEAgADYkrgAgQEEAAAIgwEAAAAIvwEB ABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABgD7AH0A6AEA8AEfAQAAAAAADDCwgAAAADAAAA CQK4AA8ADfBCAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8YAAAAAgAAAAAAAAgKAAEABwAC AAAAAAACAA4AAAD6DwQAAAAAAAAADwAE8LoAAAASAArwCAAAAAYEAAAACgAAgwAL8DAAAAB/AAEA AQCAANyVuACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAGAPIBDQ FIAQDwAR8BAAAAAAAMMLCAAAAAQAAAAIArgADwAN8EIAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoA AAChDxgAAAACAAAAAAAACAoAAgAHAAIAAAAAAAIADgAAANgPBAAAAAAAAAAPAATwSAAAABIACvAI AAAAAQQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQD CQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAgALoPHAAA AEQAZQBmAGEAdQBsAHQAIABEAGUAcwBpAGcAbgAPAO4D5AEAAAIA7wMYAAAAAQAAAA0OAAAAAAAA AAAAgAAAAAAHAAAADwAMBJQBAAAPAALwjAEAADAACPAIAAAAAwAAAAMUAAAPAAPwJAEAAA8ABPAo AAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAFAAABQAAAA8ABPByAAAAEgAK8AgA AAACFAAAIAIAAFMAC/AeAAAAfwAAAAQAgABMI78BvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACA AbAB0BRQBA8AEfAQAAAAAADDCwgAAAAAAAAADQC/AQ8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIA AAASAArwCAAAAAMUAAAgAgAAUwAL8B4AAAB/AAAABACAAKwnvwG/AQAAAQD/AQAAAQABAwMEAAAA ABDwCAAAAOAEsAHQFAAPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAL8BDwAN8AwAAAAAAJ4PBAAAAAEA AAAPAATwSAAAABIACvAIAAAAARQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1o AL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wA zMz/ALKysgAPAO4DXQYAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHAAAADwAMBA0GAAAP AALwBQYAAEAACPAIAAAADQAAABEYAAAPAAPwnQUAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAA AAAAAAAAAgAK8AgAAAAAGAAABQAAAA8ABPByAAAAEgAK8AgAAAACGAAAIAIAAFMAC/AeAAAAfwAA AAQAgACsPr8BvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACAAbAB0BRQBA8AEfAQAAAAAADDCwgA AAAAAAAADQC/AQ8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMYAAAgAgAAUwAL 8B4AAAB/AAAABACAAERlvwG/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAIAH4AEAFfAPDwAR8BAA AAAAAMMLCAAAAAEAAAAOAL8BDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwoAAAABIACvAIAAAABBgA AAAKAACjAAvwPAAAAH8AAAAEAIAAbEmgAoUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMAB AQAACP8BCAAIAAECAgAACAAAEPAIAAAAcAXABrAHwAYPAA3wNAAAAAAAnw8EAAAABAAAAAAAqA8C AAAARDEAAKEPFgAAAAMAAAAAAAAICgABAAcAAwAAAAAAAAAPAATwoAAAABIACvAIAAAABRgAAAAK AACjAAvwPAAAAH8AAAAEAIAA7EOgAoUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAA CP8BCAAIAAECAgAACAAAEPAIAAAAcAVwC2AMwAYPAA3wNAAAAAAAnw8EAAAABAAAAAAAqA8CAAAA RDIAAKEPFgAAAAMAAAAAAAAICgABAAcAAwAAAAAAAAAPAATwUgAAAEIBCvAIAAAABhgAAAAKAABz AAvwKgAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsB1JQAAP8BGAAYAAECAgAACAAAEPAIAAAA MAawB3ALMAYPAATwnwAAABIACvAIAAAACxgAAAAKAACjAAvwPAAAAH8AAAAEAIAArFegAoUAAgAA AIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAIAQwCSAK cAUPAA3wMwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAVQAAoQ8WAAAAAgAAAAAAAAgKAAEABwACAAAA AAAAAA8ABPBSAAAAQgEK8AgAAAAMGAAAAAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEB AAAIywHUlAAA/wEYABgAAQICAAAIAAAQ8AgAAABwBZAJkAkwBg8ABPBSAAAAQgEK8AgAAAANGAAA gAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0QEBAAAA/wEYABgAAQICAAAIAAAQ 8AgAAADgBEAIMAnQBQ8AA/ASAQAADwAE8EYAAAABAAnwEAAAAMAPAACwBAAAgBAAAHAFAAACAArw CAAAAA4YAAABAgAAEwAL8AYAAACIAwAAAAAAABDwCAAAANAFgApAC5AGDwAE8FoAAABCAQrwCAAA AA8YAAACCgAAcwAL8CoAAABEAQQAAAB/AQAAAQC/AQAAEADAAf8AAADLAdSUAAD/ARgAGAABAgIA AAgAAA/wEAAAAMAPAACwBAAAgBAAAHAFAAAPAATwWgAAAEIBCvAIAAAAEBgAAEIKAABzAAvwKgAA AEQBBAAAAH8BAAABAL8BAAAQAMAB/wAAAMsB1JQAAP8BGAAYAAECAgAACAAAD/AQAAAAwA8AALAE AACAEAAAcAUAAA8ABPBSAAAAQgEK8AgAAAARGAAAAAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEA ABAAwAEBAAAI0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAACQBkAIUAqQBg8ABPBIAAAAEgAK8AgA AAABGAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJ AAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPkAQAA AgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwElAEAAA8AAvCMAQAAUAAI8AgAAAAD AAAAAxwAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAc AAAFAAAADwAE8HIAAAASAArwCAAAAAIcAAAgAgAAUwAL8B4AAAB/AAAABACAAHzEvwG/AQAAAQD/ AQAAAQABAwIEAAAAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAL8BDwAN8AwA AAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAxwAACACAABTAAvwHgAAAH8AAAAEAIAAMM2/ Ab8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4A vwEPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABHAAAAAwAAIMAC/AwAAAAgQEA AAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8A AAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gP+BAAAAgDvAxgAAAABAAAADQ4AAAAAAAAA AACAAAAAAAcAAAAPAAwErgQAAA8AAvCmBAAAYAAI8AgAAAAKAAAACiAAAA8AA/A+BAAADwAE8CgA AAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAgAAAFAAAADwAE8HIAAAASAArwCAAA AAIgAAAgAgAAUwAL8B4AAAB/AAAABACAAPw3vwG/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIAB sAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAKACDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAA ABIACvAIAAAAAyAAACACAABTAAvwHgAAAH8AAAAEAIAArCu/Ab8BAAABAP8BAAABAAEDAwQAAAAA EPAIAAAAkAawAdAUwA8PABHwEAAAAAAAwwsIAAAAAQAAAA4AvwEPAA3wDAAAAAAAng8EAAAAAQAA AA8ABPCfAAAAEgAK8AgAAAAEIAAAAAoAAKMAC/A8AAAAfwAAAAQAgAAU+78BhQACAAAAhwABAAAA gQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAABQBMAGsAegBQ8ADfAz AAAAAACfDwQAAAAEAAAAAACoDwEAAABYAAChDxYAAAACAAAAAAAACAoAAQAHAAIAAAAAAAAADwAE 8J8AAAASAArwCAAAAAUgAAAACgAAowAL8DwAAAB/AAAABACAAABNvwGFAAIAAACHAAEAAACBAQQA AAiDAQAAAAi/AQAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAFAEcAtgDKAFDwAN8DMAAAAA AJ8PBAAAAAQAAAAAAKgPAQAAAFkAAKEPFgAAAAIAAAAAAAAICgABAAcAAgAAAAAAAAAPAATwWAAA AEIBCvAIAAAABiAAAAAKAACDAAvwMAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsB1JQAANEB AQAAAP8BGAAYAAECAgAACAAAEPAIAAAAsASwB3ALsAQPAATwWAAAAEIBCvAIAAAAByAAAEAKAACD AAvwMAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsB1JQAANEBAQAAAP8BGAAYAAECAgAACAAA EPAIAAAAQAWwB3ALQAUPAAPwBAEAAA8ABPA4AAAAAQAJ8BAAAADADwAAsAQAAIAQAABwBQAAAgAK 8AgAAAAKIAAAAQIAAAAAEPAIAAAAUAQwCfAJEAUPAATwWgAAAEIBCvAIAAAACCAAAAIKAABzAAvw KgAAAEQBBAAAAH8BAAABAL8BAAAQAMAB/wAAAMsB1JQAAP8BGAAYAAECAgAACAAAD/AQAAAAwA8A ALAEAACAEAAAcAUAAA8ABPBaAAAAQgEK8AgAAAAJIAAAQgoAAHMAC/AqAAAARAEEAAAAfwEAAAEA vwEAABAAwAH/AAAAywHUlAAA/wEYABgAAQICAAAIAAAP8BAAAADADwAAsAQAAIAQAABwBQAADwAE 8EgAAAASAArwCAAAAAEgAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIA EgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCy srIAAAByFxwAAAABAGAAAAAAAPEJAACbEgAAhxQAAOwaAADYHAAAAAD1DxwAAAABAQAA7Q4AAwAA AADeIQAAAQAAAAYAAAABAHQADwDoAwgKAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAA AAAAAAAAAAAAAQAAAAAAAAEPAPIDFgEAAC8AyA8MAAAAMADSDwQAAAABAAAADwDVB0wAAAAAALcP RAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAADDS4AGjWEgBQ1hIA7KAHMAgAAAAA AAAAaNYSAFdvDTAAAAQAAACkDwoAAACBAGAAAQD/////AAClDwwAAAAAAAAILgAAAAcAAAAAAKkP CgAAAAcAAAACAAkEAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAA AAIAAAD//+8AAAAAAP///////xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGAD YAMAAAAAAAUAAIAEgAQAAAAADwALBLAAAAAPAADwqAAAAAAABvBQAAAACyAAAAkAAAAjAAAABQAA AAEAAAAHAAAAAAAAAAgAAAAAAAAABgAAAAAAAAAEAAAAAwAAAAQAAAAEAAAAEgAAAAUAAAAEAAAA BgAAAAsAAABjAAvwJAAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAAAAIAAAADAAAABAAAAAUAAAAG AAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQA AAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAA ACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAA MQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAAP7///85AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/ AAAAQAAAAEEAAAD+/////v////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////+/wAABQACAAAAAAAAAAAAAAAAAAAA AAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACkDQAADAAAAAEAAABoAAAAAgAAAHAAAAAEAAAAkAAA AAcAAACcAAAACAAAAKgAAAAJAAAAuAAAABIAAADEAAAACgAAAOQAAAAMAAAA8AAAAA0AAAD8AAAA DwAAAAgBAAARAAAAEAEAAAIAAADkBAAAHgAAABgAAABQb3dlclBvaW50IFByZXNlbnRhdGlvbgAe AAAAAQAAAABvd2UeAAAAAQAAAABvd2UeAAAABQAAAHRpYW4AUG9pHgAAAAIAAAA0AGFuHgAAABUA AABNaWNyb3NvZnQgUG93ZXJQb2ludABvbgBAAAAAADdl2wUAAABAAAAAAAAAAAAAAABAAAAA0Bb9 WX0jxQEDAAAA6gAAAEcAAACKDAAA/////wMAAAAIAIkQZwwAAAEACQAAAz0GAAAGAEgAAAAAABEA AAAmBg8AGAD/////AAAQAAAAAAAAAAAAwAMAANACAAAJAAAAJgYPAAgA/////wIAAAAXAAAAJgYP ACMA/////wQAGwBUTlBQFAAcAbgAMgAAAP//TwAUAAAATQBpAAAACgAAACYGDwAKAFROUFAAAAIA 9AMJAAAAJgYPAAgA/////wMAAAAPAAAAJgYPABQAVE5QUAQADAABAAAAAQAAAAAAAAAFAAAACwIA AAAABQAAAAwC0ALAAwUAAAAEAQ0AAAAHAAAA/AIAAP///wAAAAQAAAAtAQAACAAAAPoCBQABAAAA AAAAAAQAAAAtAQEABAAAAC0BAAAJAAAAHQYhAPAA0ALAAwAAAAAEAAAALQEAAAcAAAD8AgAA//// AAAABAAAAC0BAgAEAAAA8AEAAAgAAAD6AgAAAAAAAAAAAAAEAAAALQEAABAAAAAmBg8AFgD///// AABHAAAAjwIAABEBAADBAgAACAAAACYGDwAGAP////8BABwAAAD7AgAAAAAAAAAAAAAAAAAAAAAA AADJEgAEq/R3QAAAAKMGCuZb1PR3ZNT0dwEAAAAAADAABAAAAC0BAwAFAAAACQIAAAACBQAAABQC AAAAAAUAAAACAQIAAAAQAAAAJgYPABYA/////wAARwEAAI8CAAB5AgAAwQIAAAgAAAAmBg8ABgD/ ////AQAFAAAACQIAAAACBQAAABQCAAAAAAUAAAACAQIAAAAHAAAA/AIBAAAAAAAAAAQAAAAtAQQA BAAAAC0BAQAHAAAAGwS5AHkDQABIAAQAAAAtAQIABAAAAC0BAAAFAAAACQIAAAACBQAAABQCAAAA ABwAAAD7AsX/AAAAAAAAkAEAAAAAAEAAAFRpbWVzIE5ldyBSb21hbgBb1PR3ZNT0dwEAAAAAADAA BAAAAC0BBQAEAAAA8AEDAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAr AAAAMgpuALEAGAAAAEFuIElzc3VlIHdpdGggVENQIEJhc2VkICoAHgAPABMAFwAXAB4AGQAPACsA EAAQAB0ADwAjACcAIQAPACcAGgAXABoAHgAOAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAA AgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAABMAAAAyCrQAfQEIAAAAU29sdXRpb24hAB0A DwAeABAAEQAdAB4ABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgECAAAABAAAAC0BBAAEAAAALQEB AAcAAAAbBIECeQPQAEgABAAAAC0BAgAEAAAALQEAAAUAAAAJAgAAAAIFAAAAFAIAAAAAHAAAAPsC 1f8AAAAAAACQAQAAAAAAQAAAVGltZXMgTmV3IFJvbWFuAFvU9Hdk1PR3AQAAAAAAMAAEAAAALQED AAQAAADwAQUABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAAkAAAAyCv4A UgABAAAAlQAPAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEY AAAABQAAAAIBAQAAAEAAAAAyCv4AdgAmAAAASW4gTVZQTiBhcHBsaWNhdGlvbiwgZWFjaCBQSU0g cGVlcmluZyAOABUACwAmAB8AGAAfAAsAEgAWABYACwAMABIAEwAMAAwAFQAVAAsACwASABQAEgAV AAsAGAAOACYACwAWABMAEgAOAAwAFgAVAAsABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAAC BQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAFQAAADIKMQF2AAkAAABiZXR3ZWVuIEMAFgAS AAwAHwATABIAFQALAB0ABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUA AAAuARgAAAAFAAAAAgEBAAAACQAAADIKMQErAQEAAAAtAA4ABQAAAC4BAQAAAAUAAAACAQIAAAAF AAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAALgAAADIKMQE5ARoAAABpbnN0 YW5jZXMgd291bGQgcmVxdWlyZSBhIAwAFQARAAwAEwAWABMAEgARAAsAHgAVABUADQAVAAsADgAS ABYAFQAMAA8AEgALABMACwAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAA BQAAAC4BGAAAAAUAAAACAQEAAAAqAAAAMgpkAXYAFwAAAHNlcGFyYXRlIFRDUCBjb25uZWN0aW9u IBEAEgAWABMADgATAAwAEgALABoAHQAYAAsAEgAVABUAFgATABIADAAMABYAFQAFAAAALgEBAAAA BQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAJAAAAMgqi AVIAAQAAAJUADwAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4B GAAAAAUAAAACAQEAAABDAAAAMgqiAXYAKAAAAFZQTiBhZGRyZXNzIGZhbWlseSBjYW4gYmUgaW50 cm9kdWNlZCB0byAfABgAHwALABMAFQAVAA4AEgARABEACwANABQAIAAMAA0AFAAMABIAEwAVAAsA FgASAAsADAAVAAwADgAWABUAFgATABIAFQALAAwAFQAMAAUAAAAuAQEAAAAFAAAAAgECAAAABQAA AAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAADwAAAAyCtUBdgAjAAAAbXVsdGlj YXN0IHRvIGFsbG93IFRDUCBjb25uZWN0aW9ucyAAIAAVAAwADAANABIAEwARAAwACwAMABUACwAT AAwADAAVAB4ACwAaAB0AGAALABIAFQAVABYAEwASAAwADAAWABUAEQALAAUAAAAuAQEAAAAFAAAA AgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAABUAAAAyCggCdgAJ AAAAYmV0d2VlbiBQABYAEgAMAB8AEwASABUACwAYAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkC AAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAAkAAAAyCggCJgEBAAAALQAOAAUAAAAu AQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAADQA AAAyCggCNAEeAAAAaW5zdGFuY2VzIHRvIGJlIHNoYXJlZCBhbW9uZyBDDAAVABEADAATABYAEwAS ABEACwAMABUACwAWABIACwARABUAEwAOABIAFQALABQAIQAVABUAFQALAB0ABQAAAC4BAQAAAAUA AAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAACQAAADIKCAJQ AwEAAAAtAA8ABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgA AAAFAAAAAgEBAAAASAAAADIKOwJ2ACsAAABpbnN0YW5jZXMsIGJ1dCB0aGF0IHJlcXVpcmUgbW9y ZSBjaGFuZ2UgaW4gAAwAFQARAAwAEwAVABMAEgARAAsACwAWABUADAALAAwAFQATAAwACwAOABIA FgAVAAwADgASAAsAIQAVAA8AEgAMABIAFQATABYAFgASAAsADAAVAAsABQAAAC4BAQAAAAUAAAAC AQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAGQAAADIKbgJ2AAwA AAB0aGUgcHJvdG9jb2wMABUAEgALABYADgAVAAwAFgASABUADAAFAAAALgEBAAAABQAAAAIBAgAA AAUAAAACAQIAAAAEAAAALQEBAAQAAAAtAQQAHAAAAPsCEAAHAAAAAAC8AgAAAAABAgIiU3lzdGVt AAAAAAoAAAAEAAAAAAAFAAAAAQAAAAAAMAAEAAAALQEFAAQAAADwAQMADwAAACYGDwAUAFROUFAE AAwAAAAAAAAAAAAAAAAACQAAACYGDwAIAP////8BAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC 1c3VnC4bEJOXCAArLPmuMAAAACgCAAAQAAAAAQAAAIgAAAADAAAAkAAAAA8AAACoAAAABAAAALQA AAAGAAAAvAAAAAcAAADEAAAACAAAAMwAAAAJAAAA1AAAAAoAAADcAAAAFwAAAOQAAAALAAAA7AAA ABAAAAD0AAAAEwAAAPwAAAAWAAAABAEAAA0AAAAMAQAADAAAAMYBAAACAAAA5AQAAB4AAAAPAAAA T24tc2NyZWVuIFNob3cAAB4AAAABAAAAAG4tcwMAAACpSAAAAwAAABMAAAADAAAABAAAAAMAAAAA AAAAAwAAAAAAAAADAAAAAAAAAAMAAADtDgkACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAA AAAeEAAABgAAABAAAABUaW1lcyBOZXcgUm9tYW4ADwAAAERlZmF1bHQgRGVzaWduACEAAABBbiBJ c3N1ZSB3aXRoIFRDUCBCYXNlZCBTb2x1dGlvbgAdAAAAUHJ1bmUgT3ZlcnJpZGUgRG9lcyBOb3Qg V29yawAfAAAAUmVjb3ZlcnkgZnJvbSBOZWlnaGJvciBGYWlsdXJlAB4AAABSZWNvdmVyeSBmcm9t IE9uZSBXYXkgRmFpbHVyZQAMEAAABgAAAB4AAAALAAAARm9udHMgVXNlZAADAAAAAQAAAB4AAAAQ AAAARGVzaWduIFRlbXBsYXRlAAMAAAABAAAAHgAAAA0AAABTbGlkZSBUaXRsZXMAAwAAAAQAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPYPHAAAABQAAABfwJHj hUgAAAQA9AMDALgAdGlhbggAAAB0AGkAYQBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAP///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEIAAAAsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAj/AQgACAABAgIAAAgQABrxBAAAAP8AAABAAB7x EAAAAAQAAAj/AAAAAgAACPcAABAfAPAPHAAAAAAA8wMUAAAAAgAAAAAAAAAAAAAAAAAAgAAAAAAP ANAHNwEAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAfABQEHAAAAAAAFQQUAAAAuh117ADK mjsyTs3JAMqaOwEBAAEPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABDAAAAZAAAAEMAAABkAAAA 7KAHMAgAAAAAAAAAXNYSAAAAAAAAAAAArP///wr///8BAAAAcAD7AwgAAAAAAAAAcAgAAHAA+wMI AAAAAQAAAEALAAAfAAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAK5/DTAY2hIAAAAAAPg0 uAAAAAAAAAAAAAAAAAAAAAAAAAESAB8AEwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAArn8N MBjaEgAAAAAA+DS4AAAAAAAAAAAAAAAAAAAAAAAAARIADwDwD48GAAAAAPMDFAAAAAMAAAAAAAAA AgAAAAABAAAAAAAAAACfDwQAAAAAAAAAAACoDyAAAABBbiBJc3N1ZSB3aXRoIFRDUCBCYXNlZCBT b2x1dGlvbhAAnw8EAAAAAQAAAAAAqA8NAQAASW4gTVZQTiBhcHBsaWNhdGlvbiwgZWFjaCBQSU0g cGVlcmluZyBiZXR3ZWVuIEMtaW5zdGFuY2VzIHdvdWxkIHJlcXVpcmUgYSBzZXBhcmF0ZSBUQ1Ag Y29ubmVjdGlvbg1WUE4gYWRkcmVzcyBmYW1pbHkgY2FuIGJlIGludHJvZHVjZWQgdG8gbXVsdGlj YXN0IHRvIGFsbG93IFRDUCBjb25uZWN0aW9ucyBiZXR3ZWVuIFAtaW5zdGFuY2VzIHRvIGJlIHNo YXJlZCBhbW9uZyBDLWluc3RhbmNlcywgYnV0IHRoYXQgcmVxdWlyZSBtb3JlIGNoYW5nZSBpbiB0 aGUgcHJvdG9jb2wAAPMDFAAAAAQAAAAEAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDxwA AABQcnVuZSBPdmVycmlkZSBEb2VzIE5vdCBXb3JrEACfDwQAAAABAAAAAACoDyEBAABVIGlzIHRo ZSB1cHN0cmVhbSBhbmQgRDEvRDIgYXJlIHR3byBkb3duc3RyZWFtIG5laWdoYm9ycy4gQm90aCBE MS9EMiBqb2luZWQgZ3JvdXAgRy4gSXQgaXMgcG9zc2libGUgdGhhdCBwcnVuZSBmcm9tIEQxIGFu ZCB0aGUgcHJ1bmUgQWNrIGZyb20gVSBhcmUgbm90IHJlY2VpdmVkIGJ5IEQyLiBVIHdvdWxkIHBy dW5lIHRoZSBvaWYgdG93YXJkcyBEMS9EMiwgd2hlbiBEMiBpcyBzdGlsbCBpbiB0aGUgZ3JvdXAu DUpvaW4gc3VwcHJlc3Npb24gZG9lcyBub3Qgd29yaw1OZWVkIGV4cGxpY2l0IHRyYWNraW5nAACh DxQAAAAiAQAAAAAAAAAAIgEAAAAAAgAcAAAAqg8sAAAAhQAAAAAAAAAEAAAAAQAAAAMAMQAAAAAA AAAEAAAAAQAAAAMAZAAAAAAAAAAAAPMDFAAAAAUAAAAAAAAAAgAAAAIBAAAAAAAAAACfDwQAAAAA AAAAAACoDx4AAABSZWNvdmVyeSBmcm9tIE5laWdoYm9yIEZhaWx1cmUAAKoPEgAAAB4AAAAAAAAA AQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAqA/AAAAAQWxsIFBJTSBlbnRyaWVzIGxlYXJuZWQgZnJv bSB0aGUgZmFpbGVkIG5laWdoYm9yIG11c3QgYmUgcmVtb3ZlZC4gDVRoZSB1cHN0cmVhbSBjYW4g ZWl0aGVyIGltbWVkaWF0ZWx5IHJlbW92ZSB0aGUgUElNIGVudHJpZXMsIG9yIHN0YXJ0IHRoZSBF eHBpcnkgVGltZXIgYW5kIGxldCB0aGUgdGltZW91dCBoYW5kbGUgdGhlIHJlbW92YWwuAADzAxQA AAAGAAAABAAAAAIAAAADAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8dAAAAUmVjb3ZlcnkgZnJvbSBP bmUgV2F5IEZhaWx1cmUQAJ8PBAAAAAEAAAAAAKgPTAEAAFR3byBuZWlnaGJvciBYIGFuZCBZLiBJ ZiBvbmx5IFggdG8gWSBkaXJlY3Rpb24gaXMgZmFpbGluZywgWSBjb3VsZCB0aW1lb3V0IGFuZCBy ZW1vdmUgYWxsIFBJTSBlbnRyaWVzIGxlYXJuZWQgZnJvbSBYLCB3aXRob3V0IFgga25vd2luZyBh Ym91dCBpdC4NTmVlZCBhIHdheSBmb3IgWSB0byBpbmZvcm0gWCB0aGF0IGl0IGhhcyBsb3QgdGhl IG5laWdoYm9yIGFuZCByZXF1ZXN0IGEgcmVmcmVzaC4NT25lIHNvbHV0aW9uIGZyb20gRGlubyBp cyB0byBsZXQgWSB0byBzZW5kIGEgdW5pY2FzdCBoZWxsbyB3aXRoIEdlbklkIDAgdG8gWC4gVGhp cyBoZWxsbyBtYXkgbmVlZCBhbiBBY2suAAChDxYAAABNAQAAAAAAEAAAWgBNAQAAAAACABwAAACq Dz4AAAAQAQAAAAAAAAgAAAABAAAAAwALAAAAAAAAAAYAAAABAAAAAwAfAAAAAAAAAAMAAAABAAAA AwACAAAAAAAAAAAA6gMAAAAADwDuA10GAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwAA AA8ADAQNBgAADwAC8AUGAABAAAjwCAAAAA0AAAARGAAADwAD8J0FAAAPAATwKAAAAAEACfAQAAAA AAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAABgAAAUAAAAPAATwcgAAABIACvAIAAAAAhgAACACAABT AAvwHgAAAH8AAAAEAIAArD6/Ab8BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAAgAGwAdAUUAQPABHw EAAAAAAAwwsIAAAAAAAAAA0AvwEPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAAD GAAAIAIAAFMAC/AeAAAAfwAAAAQAgABEZb8BvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgAAACAB+AB ABXwDw8AEfAQAAAAAADDCwgAAAABAAAADgC/AQ8ADfAMAAAAAACeDwQAAAABAAAADwAE8KAAAAAS AArwCAAAAAQYAAAACgAAowAL8DwAAAB/AAAABACAAGxJoAKFAAIAAACHAAEAAACBAQQAAAiDAQAA AAi/AQAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAHAFwAawB8AGDwAN8DQAAAAAAJ8PBAAA AAQAAAAAAKgPAgAAAEQxAAChDxYAAAADAAAAAAAACAoAAQAHAAMAAAAAAAAADwAE8KAAAAASAArw CAAAAAUYAAAACgAAowAL8DwAAAB/AAAABACAAOxDoAKFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ AQAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAHAFcAtgDMAGDwAN8DQAAAAAAJ8PBAAAAAQA AAAAAKgPAgAAAEQyAAChDxYAAAADAAAAAAAACAoAAQAHAAMAAAAAAAAADwAE8FIAAABCAQrwCAAA AAYYAAAACgAAcwAL8CoAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAdSUAAD/ARgAGAABAgIA AAgAABDwCAAAADAGsAdwCzAGDwAE8J8AAAASAArwCAAAAAsYAAAACgAAowAL8DwAAAB/AAAABACA AKxXoAKFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQgACAABAgIAAAgAABDw CAAAACAEMAkgCnAFDwAN8DMAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAAFUAAKEPFgAAAAIAAAAAAAAI CgABAAcAAgAAAAAAAAAPAATwUgAAAEIBCvAIAAAADBgAAAAKAABzAAvwKgAAAEQBBAAAAH8BAAAB AL8BAAAQAMABAQAACMsB1JQAAP8BGAAYAAECAgAACAAAEPAIAAAAcAWQCZAJMAYPAATwUgAAAEIB CvAIAAAADRgAAIAKAABzAAvwKgAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACNEBAQAAAP8BGAAY AAECAgAACAAAEPAIAAAA4ARACDAJ0AUPAAPwEgEAAA8ABPBGAAAAAQAJ8BAAAADADwAAsAQAAIAQ AABwBQAAAgAK8AgAAAAOGAAAAQIAABMAC/AGAAAAiAMAAAAAAAAQ8AgAAADQBYAKQAuQBg8ABPBa AAAAQgEK8AgAAAAPGAAAAgoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAH/AAAAywHUlAAA /wEYABgAAQICAAAIAAAP8BAAAADADwAAsAQAAIAQAABwBQAADwAE8FoAAABCAQrwCAAAABAYAABC CgAAcwAL8CoAAABEAQQAAAB/AQAAAQC/AQAAEADAAf8AAADLAdSUAAD/ARgAGAABAgIAAAgAAA/w EAAAAMAPAACwBAAAgBAAAHAFAAAPAATwUgAAAEIBCvAIAAAAERgAAAAKAABzAAvwKgAAAEQBBAAA AH8BAAABAL8BAAAQAMABAQAACNEBAQAAAP8BGAAYAAECAgAACAAAEPAIAAAAkAZACFAKkAYPAATw SAAAABIACvAIAAAAARgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgAS AP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKy sgAAAHIXEAAAAAEAEAAmIgAABAAQADYsAAAAAPUPHAAAAAEBAADtDgADAiIAAJsyAAABAAAABgAA AAEAdAAPAOgDGwoAAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAAAAAAAAAAAAABAAAA AAAAAQ8A8gMWAQAALwDIDwwAAAAwANIPBAAAAAEAAAAPANUHTAAAAAAAtw9EAAAAVABpAG0AZQBz ACAATgBlAHcAIABSAG8AbQBhAG4AAAAMNLgAaNYSAFDWEgDsoAcwCAAAAAAAAABo1hIAV28NMAAA BAAAAKQPCgAAAIEAYAABAP////8AAKUPDAAAAAAAAAguAAAABwAAAAAAqQ8KAAAABwAAAAIACQQA AEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA ////////GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASA BAAAAAAPAAsEsAAAAA8AAPCoAAAAAAAG8FAAAAALIAAACQAAACMAAAAFAAAAAQAAAAcAAAAAAAAA CAAAAAAAAAAGAAAAAAAAAAQAAAADAAAABAAAAAQAAAASAAAABQAAAAQAAAAGAAAACwAAAGMAC/Ak AAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIEAAa8QQAAAD/AAAAQAAe8RAA AAAEAAAI/wAAAAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAIAAAAAAAAAAAAAAAAAAIAAAAAADwDQ BzcBAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAAHwAUBBwAAAAAABUEFAAAALoddewAypo7 Mk7NyQDKmjsBAQABDwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAAQwAAAGQAAABDAAAAZAAAAOyg BzAIAAAAAAAAAFzWEgAAAAAAAAAAAKz///8K////AQAAAHAA+wMIAAAAAAAAAHAIAABwAPsDCAAA AAEAAABACwAAHwAHBDwAAAAAAP0DNAAAACEAAABkAAAAIQAAAGQAAACufw0wGNoSAAAAAAD4NLgA AAAAAAAAAAAAAAAAAAAAAAABEgAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAAK5/DTAY 2hIAAAAAAPg0uAAAAAAAAAAAAAAAAAAAAAAAAAESAA8A8A+iBgAAAADzAxQAAAADAAAAAAAAAAIA AAAAAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8gAAAAQW4gSXNzdWUgd2l0aCBUQ1AgQmFzZWQgU29s dXRpb24QAJ8PBAAAAAEAAAAAAKgPDQEAAEluIE1WUE4gYXBwbGljYXRpb24sIGVhY2ggUElNIHBl ZXJpbmcgYmV0d2VlbiBDLWluc3RhbmNlcyB3b3VsZCByZXF1aXJlIGEgc2VwYXJhdGUgVENQIGNv bm5lY3Rpb24NVlBOIGFkZHJlc3MgZmFtaWx5IGNhbiBiZSBpbnRyb2R1Y2VkIHRvIG11bHRpY2Fz dCB0byBhbGxvdyBUQ1AgY29ubmVjdGlvbnMgYmV0d2VlbiBQLWluc3RhbmNlcyB0byBiZSBzaGFy ZWQgYW1vbmcgQy1pbnN0YW5jZXMsIGJ1dCB0aGF0IHJlcXVpcmUgbW9yZSBjaGFuZ2UgaW4gdGhl IHByb3RvY29sAADzAxQAAAAEAAAABAAAAAIAAAABAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8cAAAA UHJ1bmUgT3ZlcnJpZGUgRG9lcyBOb3QgV29yaxAAnw8EAAAAAQAAAAAAqA8zAQAAVSBpcyB0aGUg dXBzdHJlYW0gYW5kIEQxL0QyIGFyZSB0d28gZG93bnN0cmVhbSBuZWlnaGJvcnMuIEJvdGggRDEv RDIgam9pbmVkIGdyb3VwIEcuIEl0IGlzIHBvc3NpYmxlIHRoYXQgcHJ1bmUgZnJvbSBEMSBhbmQg dGhlIHBydW5lIEFjayBmcm9tIFUgYXJlIG5vdCByZWNlaXZlZCBieSBEMi4gVSB3b3VsZCBwcnVu ZSB0aGUgb2lmIHRvd2FyZHMgRDEvRDIsIHdoZW4gRDIgaXMgc3RpbGwgaW4gdGhlIGdyb3VwLg1K b2luIHN1cHByZXNzaW9uIGRvZXMgbm90IHdvcmsNT25lIHNvbHV0aW9uIGlzIHRvIHVzZSBleHBs aWNpdCB0cmFja2luZwAAoQ8UAAAANAEAAAAAAAAAADQBAAAAAAIAHAAAAKoPLAAAAIUAAAAAAAAA BAAAAAEAAAADADEAAAAAAAAABAAAAAEAAAADAHYAAAAAAAAAAADzAxQAAAAFAAAAAAAAAAIAAAAC AQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8eAAAAUmVjb3ZlcnkgZnJvbSBOZWlnaGJvciBGYWlsdXJl AACqDxIAAAAeAAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgPwAAAAEFsbCBQSU0gZW50 cmllcyBsZWFybmVkIGZyb20gdGhlIGZhaWxlZCBuZWlnaGJvciBtdXN0IGJlIHJlbW92ZWQuIA1U aGUgdXBzdHJlYW0gY2FuIGVpdGhlciBpbW1lZGlhdGVseSByZW1vdmUgdGhlIFBJTSBlbnRyaWVz LCBvciBzdGFydCB0aGUgRXhwaXJ5IFRpbWVyIGFuZCBsZXQgdGhlIHRpbWVvdXQgaGFuZGxlIHRo ZSByZW1vdmFsLgAA8wMUAAAABgAAAAQAAAACAAAAAwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPHQAA AFJlY292ZXJ5IGZyb20gT25lIFdheSBGYWlsdXJlEACfDwQAAAABAAAAAACoD00BAABUd28gbmVp Z2hib3IgWCBhbmQgWS4gSWYgb25seSBYIHRvIFkgZGlyZWN0aW9uIGlzIGZhaWxpbmcsIFkgY291 bGQgdGltZW91dCBhbmQgcmVtb3ZlIGFsbCBQSU0gZW50cmllcyBsZWFybmVkIGZyb20gWCwgd2l0 aG91dCBYIGtub3dpbmcgYWJvdXQgaXQuDU5lZWQgYSB3YXkgZm9yIFkgdG8gaW5mb3JtIFggdGhh dCBpdCBoYXMgbG9zdCB0aGUgbmVpZ2hib3IgYW5kIHJlcXVlc3QgYSByZWZyZXNoLg1PbmUgc29s dXRpb24gZnJvbSBEaW5vIGlzIHRvIGxldCBZIHRvIHNlbmQgYSB1bmljYXN0IGhlbGxvIHdpdGgg R2VuSWQgMCB0byBYLiBUaGlzIGhlbGxvIG1heSBuZWVkIGFuIEFjay4AAKEPFgAAAE4BAAAAAAAQ AABaAE4BAAAAAAIAHAAAAKoPPgAAABEBAAAAAAAACAAAAAEAAAADAAsAAAAAAAAABgAAAAEAAAAD AB8AAAAAAAAAAwAAAAEAAAADAAIAAAAAAAAAAADqAwAAAAAPAO4DXQYAAAIA7wMYAAAAAQAAAA0O AAAAAAAAAAAAgAAAAAAHAAAADwAMBA0GAAAPAALwBQYAAEAACPAIAAAADQAAABEYAAAPAAPwnQUA AA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAGAAABQAAAA8ABPByAAAA EgAK8AgAAAACGAAAIAIAAFMAC/AeAAAAfwAAAAQAgACsPr8BvwEAAAEA/wEAAAEAAQMCBAAAAAAQ 8AgAAACAAbAB0BRQBA8AEfAQAAAAAADDCwgAAAAAAAAADQC/AQ8ADfAMAAAAAACeDwQAAAAAAAAA DwAE8HIAAAASAArwCAAAAAMYAAAgAgAAUwAL8B4AAAB/AAAABACAAERlvwG/AQAAAQD/AQAAAQAB AwMEAAAAABDwCAAAAIAH4AEAFfAPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAL8BDwAN8AwAAAAAAJ4P BAAAAAEAAAAPAATwoAAAABIACvAIAAAABBgAAAAKAACjAAvwPAAAAH8AAAAEAIAAbEmgAoUAAgAA AIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAcAXABrAH wAYPAA3wNAAAAAAAnw8EAAAABAAAAAAAqA8CAAAARDEAAKEPFgAAAAMAAAAAAAAICgABAAcAAwAA AAAAAAAPAATwoAAAABIACvAIAAAABRgAAAAKAACjAAvwPAAAAH8AAAAEAIAA7EOgAoUAAgAAAIcA AQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAcAVwC2AMwAYP AA3wNAAAAAAAnw8EAAAABAAAAAAAqA8CAAAARDIAAKEPFgAAAAMAAAAAAAAICgABAAcAAwAAAAAA AAAPAATwUgAAAEIBCvAIAAAABhgAAAAKAABzAAvwKgAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAA CMsB1JQAAP8BGAAYAAECAgAACAAAEPAIAAAAMAawB3ALMAYPAATwnwAAABIACvAIAAAACxgAAAAK AACjAAvwPAAAAH8AAAAEAIAArFegAoUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAA CP8BCAAIAAECAgAACAAAEPAIAAAAIAQwCSAKcAUPAA3wMwAAAAAAnw8EAAAABAAAAAAAqA8BAAAA VQAAoQ8WAAAAAgAAAAAAAAgKAAEABwACAAAAAAAAAA8ABPBSAAAAQgEK8AgAAAAMGAAAAAoAAHMA C/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywHUlAAA/wEYABgAAQICAAAIAAAQ8AgAAABw BZAJkAkwBg8ABPBSAAAAQgEK8AgAAAANGAAAgAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAA wAEBAAAI0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAADgBEAIMAnQBQ8AA/ASAQAADwAE8EYAAAAB AAnwEAAAAMAPAACwBAAAgBAAAHAFAAACAArwCAAAAA4YAAABAgAAEwAL8AYAAACIAwAAAAAAABDw CAAAANAFgApAC5AGDwAE8FoAAABCAQrwCAAAAA8YAAACCgAAcwAL8CoAAABEAQQAAAB/AQAAAQC/ AQAAEADAAf8AAADLAdSUAAD/ARgAGAABAgIAAAgAAA/wEAAAAMAPAACwBAAAgBAAAHAFAAAPAATw WgAAAEIBCvAIAAAAEBgAAEIKAABzAAvwKgAAAEQBBAAAAH8BAAABAL8BAAAQAMAB/wAAAMsB1JQA AP8BGAAYAAECAgAACAAAD/AQAAAAwA8AALAEAACAEAAAcAUAAA8ABPBSAAAAQgEK8AgAAAARGAAA AAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0QEBAAAA/wEYABgAAQICAAAIAAAQ 8AgAAACQBkAIUAqQBg8ABPBIAAAAEgAK8AgAAAABGAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAI kwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAA AAAAAMyZADMzzADMzP8AsrKyAA8A7gP+BAAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcA AAAPAAwErgQAAA8AAvCmBAAAYAAI8AgAAAAKAAAACiAAAA8AA/A+BAAADwAE8CgAAAABAAnwEAAA AAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAgAAAFAAAADwAE8HIAAAASAArwCAAAAAIgAAAgAgAA UwAL8B4AAAB/AAAABACAAPw3vwG/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIABsAHQFFAEDwAR 8BAAAAAAAMMLCAAAAAAAAAANAKACDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAA AyAAACACAABTAAvwHgAAAH8AAAAEAIAArCu/Ab8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAAkAaw AdAUwA8PABHwEAAAAAAAwwsIAAAAAQAAAA4AvwEPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPCfAAAA EgAK8AgAAAAEIAAAAAoAAKMAC/A8AAAAfwAAAAQAgAAU+78BhQACAAAAhwABAAAAgQEEAAAIgwEA AAAIvwEAABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAABQBMAGsAegBQ8ADfAzAAAAAACfDwQA AAAEAAAAAACoDwEAAABYAAChDxYAAAACAAAAAAAACAoAAQAHAAIAAAAAAAAADwAE8J8AAAASAArw CAAAAAUgAAAACgAAowAL8DwAAAB/AAAABACAAABNvwGFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ AQAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAFAEcAtgDKAFDwAN8DMAAAAAAJ8PBAAAAAQA AAAAAKgPAQAAAFkAAKEPFgAAAAIAAAAAAAAICgABAAcAAgAAAAAAAAAPAATwWAAAAEIBCvAIAAAA BiAAAAAKAACDAAvwMAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsB1JQAANEBAQAAAP8BGAAY AAECAgAACAAAEPAIAAAAsASwB3ALsAQPAATwWAAAAEIBCvAIAAAAByAAAEAKAACDAAvwMAAAAEQB BAAAAH8BAAABAL8BAAAQAMABAQAACMsB1JQAANEBAQAAAP8BGAAYAAECAgAACAAAEPAIAAAAQAWw B3ALQAUPAAPwBAEAAA8ABPA4AAAAAQAJ8BAAAADADwAAsAQAAIAQAABwBQAAAgAK8AgAAAAKIAAA AQIAAAAAEPAIAAAAUAQwCfAJEAUPAATwWgAAAEIBCvAIAAAACCAAAAIKAABzAAvwKgAAAEQBBAAA AH8BAAABAL8BAAAQAMAB/wAAAMsB1JQAAP8BGAAYAAECAgAACAAAD/AQAAAAwA8AALAEAACAEAAA cAUAAA8ABPBaAAAAQgEK8AgAAAAJIAAAQgoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAH/ AAAAywHUlAAA/wEYABgAAQICAAAIAAAP8BAAAADADwAAsAQAAIAQAABwBQAADwAE8EgAAAASAArw CAAAAAEgAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAE AwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIAAAByFxgA AAABABAA1zIAAAQAEAD6PAAABgAQAF9DAAAAAPUPHAAAAAEBAADtDgADszIAAGVIAAABAAAABgAA AAEAdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA --=-fggLqmFBm/xMVhu4F/77-- From mmcbride@cisco.com Mon Mar 7 21:10:33 2005 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j282AXpW011508 for ; Mon, 7 Mar 2005 21:10:33 -0500 (EST) (envelope-from mmcbride@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 Mar 2005 18:24:21 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j282AKq8007231; Mon, 7 Mar 2005 18:10:21 -0800 (PST) Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BCO20648; Mon, 7 Mar 2005 18:10:24 -0800 (PST) Date: Mon, 7 Mar 2005 18:10:24 -0800 (PST) From: Mike McBride To: Albert Tian Subject: Re: [Pim-state] Summary In-Reply-To: <1110245242.5161.3136.camel@oslo.redback.com> Message-ID: References: <200502252151.j1PLpte80165@merlot.juniper.net> <200502252229.j1PMT2sn011632@dino-lnx.cisco.com> <1110236844.5161.2107.camel@oslo.redback.com> <1110245242.5161.3136.camel@oslo.redback.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Mar 2005 02:10:34 -0000 Since you are here (and since Suresh and Dino are not) why don't you plan on taking a few minutes during the wg to discuss this. Tom or I can give an update on the work and you (and perhaps Bob) can give the details of the proposed solutions. I have Suresh's slides if you need them, they are a good review. thanks, mike On Mon, 7 Mar 2005, Albert Tian wrote: > Hi, > > Here are some slides regarding the points I raised. > > Thanks, > > Albert > > On Mon, 2005-03-07 at 15:07, Albert Tian wrote: > > Hi Dino/Tom/Mike/Suresh, > > > > Here are a few issues that were not mentioned in the summary: > > > > - One other problem for the TCP based solution is that for MVPN, each of > > the PIM peering between C-instances would require a seperate TCP > > connection. One could device a solution that introduces VPN address > > families for multicast so that the TCP connections can be shared, but > > that would require more change in the protocol. > > > > - Prune override no longer works (therefore join supression does not > > work either) , because there is no guarantee that the prune from one > > downstream neighbor is delivered to the other downstream neighbor(s) > > that need(s) to override it. There are several ways to fix it, but the > > simplest IMHO is to enable explicit tracking and disable Join > > suppression. For example U is the upstream and D1,D2 are two downstream > > neighbors. Both D1 and D2 joined group G, not D1 send out a prune. It is > > possible that the prune and ack for prune are delivered to U, but not > > D2. U would prune the oif to D1/D2 while D2 is still in the Group. > > > > - Recovery from failed neighbor. All PIM entries learned from that > > neighbor must be removed. The upstream can either immediately remove > > them, or start the Expiry Timers with shorter durations and let the > > timeout process handle it. > > > > - Recovery from one way communication failure. In this scenario, say two > > neighbors X and Y, only X->Y direction is failing. Y will timeout X and > > delete all the PIM entries learned from X, without X knowing about it. > > So there needs a way for Y to tell X that it has lost neighbor X, so > > that X can retransmit all its entries once the failure goes away. One > > solution (from Dino) is for Y to unicast a hello with GenId 0 to X to > > request a refresh. This hello likely needs an Ack of some form. > > > > - A checksum based approach was mentioned, any progress over there? > > > > > > I can put these points in a few slides. > > > > I will attend this IETF (I wasn't sure if I can make it till today). > > > > As one of the co-authors of the JP Ack solution/draft, I could help > > presentating the JP Ack approach, if needed. > > > > Thanks, > > > > Albert > > > > On Fri, 2005-02-25 at 14:29, Dino Farinacci wrote: > > > >> Yes. This is a good idea. Is anyone willing to summarize the current > > > >> state of things (pun intended) with a few slides to the working group? > > > > > > Since I won't be ablt to attend the IETF, I will brief some of the cisco > > > guys. I think Mike (and you) were suppose to present that. > > > > > > Dino > > > _______________________________________________ > > > Pim-state mailing list > > > Pim-state@mountain2sea.com > > > http://www.mountain2sea.com/mailman/listinfo/pim-state > From rkebler@avici.com Mon Mar 7 22:05:21 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j2835LiI011601 for ; Mon, 7 Mar 2005 22:05:21 -0500 (EST) (envelope-from rkebler@avici.com) Received: from webmail.avici.com (mailhost.avici.com [127.0.0.1]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id j2835C7k028256 for ; Mon, 7 Mar 2005 22:05:13 -0500 Received: from 10.2.2.223 (SquirrelMail authenticated user rkebler) by webmail.avici.com with HTTP; Mon, 7 Mar 2005 22:05:13 -0500 (EST) Message-ID: <55958.10.2.2.223.1110251113.squirrel@webmail.avici.com> Date: Mon, 7 Mar 2005 22:05:13 -0500 (EST) From: rkebler@avici.com To: pim-state@mountain2sea.com User-Agent: SquirrelMail/1.4.0-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Avici-MailScanner-Information: Please contact the ISP for more information Subject: [Pim-state] consensus X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Mar 2005 03:05:21 -0000 These are the major ideas that I think we have come to consensus on. Let me know if anybody disagrees or I've missed anything. Consensus: ---------- hello option to advertise capability new JP Ack messages to make the Joins reliable JP holdtime will be maintained. Never refreshed if holdtime=0xffff, otherwise refreshed method to request full JP state Explicit Tracking (I think) Still need to come to agreement on: ----------------------------------- A sequence number per JP message or per route entry Reliable JP messages should be multicast (ALL-PIM-ROUTERS) or unicast JP ACKs should be multicast (ALL-PIM-ROUTERS) or unicast From sboddapa@yahoo.com Mon Mar 7 22:16:11 2005 Received: from web81302.mail.yahoo.com (web81302.mail.yahoo.com [206.190.37.77]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j283GBEo011638 for ; Mon, 7 Mar 2005 22:16:11 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050308031606.3752.qmail@web81302.mail.yahoo.com> Received: from [64.160.53.144] by web81302.mail.yahoo.com via HTTP; Mon, 07 Mar 2005 19:16:06 PST Date: Mon, 7 Mar 2005 19:16:06 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] Summary To: Mike McBride , Albert Tian In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Mar 2005 03:16:11 -0000 Mike, I was under the impression that the presentations were going to be between the chairs like you suggested in your earlier email. If the presentation can be made by someone else, Venu Hemige is there from Alcatel and he has also been participating in the discussion from the beginning. He can present my slides. Thanks. Suresh --- Mike McBride wrote: > Since you are here (and since Suresh and Dino are > not) why don't you plan > on taking a few minutes during the wg to discuss > this. Tom or I can give > an update on the work and you (and perhaps Bob) can > give the details of > the proposed solutions. I have Suresh's slides if > you need them, they are > a good review. > > thanks, > mike > > On Mon, 7 Mar 2005, Albert Tian wrote: > > > Hi, > > > > Here are some slides regarding the points I > raised. > > > > Thanks, > > > > Albert > > > > On Mon, 2005-03-07 at 15:07, Albert Tian wrote: > > > Hi Dino/Tom/Mike/Suresh, > > > > > > Here are a few issues that were not mentioned in > the summary: > > > > > > - One other problem for the TCP based solution > is that for MVPN, each of > > > the PIM peering between C-instances would > require a seperate TCP > > > connection. One could device a solution that > introduces VPN address > > > families for multicast so that the TCP > connections can be shared, but > > > that would require more change in the protocol. > > > > > > - Prune override no longer works (therefore join > supression does not > > > work either) , because there is no guarantee > that the prune from one > > > downstream neighbor is delivered to the other > downstream neighbor(s) > > > that need(s) to override it. There are several > ways to fix it, but the > > > simplest IMHO is to enable explicit tracking and > disable Join > > > suppression. For example U is the upstream and > D1,D2 are two downstream > > > neighbors. Both D1 and D2 joined group G, not D1 > send out a prune. It is > > > possible that the prune and ack for prune are > delivered to U, but not > > > D2. U would prune the oif to D1/D2 while D2 is > still in the Group. > > > > > > - Recovery from failed neighbor. All PIM entries > learned from that > > > neighbor must be removed. The upstream can > either immediately remove > > > them, or start the Expiry Timers with shorter > durations and let the > > > timeout process handle it. > > > > > > - Recovery from one way communication failure. > In this scenario, say two > > > neighbors X and Y, only X->Y direction is > failing. Y will timeout X and > > > delete all the PIM entries learned from X, > without X knowing about it. > > > So there needs a way for Y to tell X that it has > lost neighbor X, so > > > that X can retransmit all its entries once the > failure goes away. One > > > solution (from Dino) is for Y to unicast a hello > with GenId 0 to X to > > > request a refresh. This hello likely needs an > Ack of some form. > > > > > > - A checksum based approach was mentioned, any > progress over there? > > > > > > > > > I can put these points in a few slides. > > > > > > I will attend this IETF (I wasn't sure if I can > make it till today). > > > > > > As one of the co-authors of the JP Ack > solution/draft, I could help > > > presentating the JP Ack approach, if needed. > > > > > > Thanks, > > > > > > Albert > > > > > > On Fri, 2005-02-25 at 14:29, Dino Farinacci > wrote: > > > > >> Yes. This is a good idea. Is anyone willing > to summarize the current > > > > >> state of things (pun intended) with a few > slides to the working group? > > > > > > > > Since I won't be ablt to attend the IETF, > I will brief some of the cisco > > > > guys. I think Mike (and you) were suppose > to present that. > > > > > > > > Dino > > > > > _______________________________________________ > > > > Pim-state mailing list > > > > Pim-state@mountain2sea.com > > > > > http://www.mountain2sea.com/mailman/listinfo/pim-state > > > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state > From sboddapa@yahoo.com Mon Mar 7 22:30:35 2005 Received: from web81309.mail.yahoo.com (web81309.mail.yahoo.com [206.190.37.84]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j283UZ0A011669 for ; Mon, 7 Mar 2005 22:30:35 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050308033030.85318.qmail@web81309.mail.yahoo.com> Received: from [64.160.53.144] by web81309.mail.yahoo.com via HTTP; Mon, 07 Mar 2005 19:30:30 PST Date: Mon, 7 Mar 2005 19:30:30 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] consensus To: rkebler@avici.com, pim-state@mountain2sea.com In-Reply-To: <55958.10.2.2.223.1110251113.squirrel@webmail.avici.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Mar 2005 03:30:35 -0000 Bob, On the "still need to come to agreement on": 1)The JP Ack packet, whether it is the JP packet clone or a separate packet with just the sequence number in it. 2)I dont think there is any disagreement on whether JP Packets should be multicast or unicast. They should be multicast, otherwise you will not have Join suppression. The JP Ack being unicast or multicast is definitely something we need to agree on. On the consensus side: Explicit tracking is orthogonal to the issue. With either scheme, explicit tracking can be achieved if everybody on the LAN supports tracking (disabling Join suppression). The point that Albert is raising here regarding Prune override and explicit tracking as a solution is independent of Refresh reduction. It can happen with existing PIM and can be solved with tracking support, which also already exists. The reliability that we are talking about is between an upstream and a downstream router in order to reduce refreshes, we are not necessarily concerned with the exchange between D1 and U being reliably seen by D2. Suresh --- rkebler@avici.com wrote: > These are the major ideas that I think we have come > to consensus on. > Let me know if anybody disagrees or I've missed > anything. > > > > Consensus: > ---------- > > hello option to advertise capability > > new JP Ack messages to make the Joins reliable > > JP holdtime will be maintained. > Never refreshed if holdtime=0xffff, otherwise > refreshed > > method to request full JP state > > Explicit Tracking (I think) > > > > > Still need to come to agreement on: > ----------------------------------- > > A sequence number per JP message or per route entry > > Reliable JP messages should be multicast > (ALL-PIM-ROUTERS) or unicast > > JP ACKs should be multicast (ALL-PIM-ROUTERS) or > unicast > > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state > From venu.hemige@alcatel.com Mon Mar 7 22:55:18 2005 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j283tHUd011749 for ; Mon, 7 Mar 2005 22:55:18 -0500 (EST) (envelope-from venu.hemige@alcatel.com) Received: from venuxp ([172.22.187.78] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Mar 2005 19:55:08 -0800 From: "Venu Hemige" To: "'Albert Tian'" , "'Dino Farinacci'" Subject: RE: [Pim-state] Summary Date: Mon, 7 Mar 2005 19:54:09 -0800 Message-ID: <0b9001c52392$7e48e130$4ebb16ac@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <1110236844.5161.2107.camel@oslo.redback.com> X-OriginalArrivalTime: 08 Mar 2005 03:55:08.0780 (UTC) FILETIME=[9EE2FAC0:01C52392] Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: venu.hemige@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Mar 2005 03:55:18 -0000 Albert, Please see my comments inline. You do make one good point, I don't quite agree with the others. Mike, Tom, I would be happy to present Suresh's slides that summarize the design team work if you are looking for a volunteer. Albert can present his. Regards, -Venu > -----Original Message----- > From: pim-state-bounces@mountain2sea.com [mailto:pim-state- > bounces@mountain2sea.com] On Behalf Of Albert Tian > Sent: Monday, March 07, 2005 3:07 PM > To: Dino Farinacci > Cc: pim-state@mountain2sea.com > Subject: Re: [Pim-state] Summary > > Hi Dino/Tom/Mike/Suresh, > > Here are a few issues that were not mentioned in the summary: > > - One other problem for the TCP based solution is that for MVPN, each of > the PIM peering between C-instances would require a seperate TCP > connection. One could device a solution that introduces VPN address > families for multicast so that the TCP connections can be shared, but > that would require more change in the protocol. > Agreed. But TCP as a solution is a non-starter anyway because it is not PIM snooping friendly. > - Prune override no longer works (therefore join supression does not > work either) , because there is no guarantee that the prune from one > downstream neighbor is delivered to the other downstream neighbor(s) > that need(s) to override it. There are several ways to fix it, but the > simplest IMHO is to enable explicit tracking and disable Join > suppression. For example U is the upstream and D1,D2 are two downstream > neighbors. Both D1 and D2 joined group G, not D1 send out a prune. It is > possible that the prune and ack for prune are delivered to U, but not > D2. U would prune the oif to D1/D2 while D2 is still in the Group. > Good point. I think this was discussed, but I do not recall. Actually ET suffices... there may still be benefit to JP suppression. Of course this would mean changing the hello definition a bit. If we decide JP suppression should be turned off instead, then we might as well unicast the JP and JP ACKs. > - Recovery from failed neighbor. All PIM entries learned from that > neighbor must be removed. The upstream can either immediately remove > them, or start the Expiry Timers with shorter durations and let the > timeout process handle it. > All entries learnt from the neighbor must be removed. If there is no one else interested, then there is no point continuing to forward on that interface. I don't think this needs to be explicitly stated in the summary. It is no different from regular PIM behavior. > - Recovery from one way communication failure. In this scenario, say two > neighbors X and Y, only X->Y direction is failing. Y will timeout X and > delete all the PIM entries learned from X, without X knowing about it. > So there needs a way for Y to tell X that it has lost neighbor X, so > that X can retransmit all its entries once the failure goes away. One > solution (from Dino) is for Y to unicast a hello with GenId 0 to X to > request a refresh. This hello likely needs an Ack of some form. > Again, this is no different than regular PIM. And I do not agree with what you are proposing. It is another thing to look into reliability in the hello mechanism itself (some light-weight hello scheme) and that is left for future discussions I suppose; but to react the way you are suggesting after not receiving up to 3 hellos from a downstream router is not right IMO. From tian@redback.com Mon Mar 7 23:18:21 2005 Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j284ILv3011818 for ; Mon, 7 Mar 2005 23:18:21 -0500 (EST) (envelope-from tian@redback.com) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 0680BD6FED1; Mon, 7 Mar 2005 20:18:16 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07249-02; Mon, 7 Mar 2005 20:18:15 -0800 (PST) Received: from oslo.redback.com (oslo.redback.com [155.53.44.173]) by prattle.redback.com (Postfix) with ESMTP id 133BBD6FED0; Mon, 7 Mar 2005 20:18:15 -0800 (PST) Subject: Re: [Pim-state] Summary From: Albert Tian To: Mike McBride In-Reply-To: References: <200502252151.j1PLpte80165@merlot.juniper.net> <200502252229.j1PMT2sn011632@dino-lnx.cisco.com> <1110236844.5161.2107.camel@oslo.redback.com> <1110245242.5161.3136.camel@oslo.redback.com> Content-Type: text/plain Message-Id: <1110255494.5157.4344.camel@oslo.redback.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 07 Mar 2005 20:18:15 -0800 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Mar 2005 04:18:22 -0000 On Mon, 2005-03-07 at 18:10, Mike McBride wrote: > Since you are here (and since Suresh and Dino are not) why don't you plan > on taking a few minutes during the wg to discuss this. Tom or I can give > an update on the work and you (and perhaps Bob) can give the details of > the proposed solutions. I have Suresh's slides if you need them, they are > a good review. Sure I can get a few more slides and could also use Suresh's. Thanks, Albert > > thanks, > mike > > On Mon, 7 Mar 2005, Albert Tian wrote: > > > Hi, > > > > Here are some slides regarding the points I raised. > > > > Thanks, > > > > Albert > > > > On Mon, 2005-03-07 at 15:07, Albert Tian wrote: > > > Hi Dino/Tom/Mike/Suresh, > > > > > > Here are a few issues that were not mentioned in the summary: > > > > > > - One other problem for the TCP based solution is that for MVPN, each of > > > the PIM peering between C-instances would require a seperate TCP > > > connection. One could device a solution that introduces VPN address > > > families for multicast so that the TCP connections can be shared, but > > > that would require more change in the protocol. > > > > > > - Prune override no longer works (therefore join supression does not > > > work either) , because there is no guarantee that the prune from one > > > downstream neighbor is delivered to the other downstream neighbor(s) > > > that need(s) to override it. There are several ways to fix it, but the > > > simplest IMHO is to enable explicit tracking and disable Join > > > suppression. For example U is the upstream and D1,D2 are two downstream > > > neighbors. Both D1 and D2 joined group G, not D1 send out a prune. It is > > > possible that the prune and ack for prune are delivered to U, but not > > > D2. U would prune the oif to D1/D2 while D2 is still in the Group. > > > > > > - Recovery from failed neighbor. All PIM entries learned from that > > > neighbor must be removed. The upstream can either immediately remove > > > them, or start the Expiry Timers with shorter durations and let the > > > timeout process handle it. > > > > > > - Recovery from one way communication failure. In this scenario, say two > > > neighbors X and Y, only X->Y direction is failing. Y will timeout X and > > > delete all the PIM entries learned from X, without X knowing about it. > > > So there needs a way for Y to tell X that it has lost neighbor X, so > > > that X can retransmit all its entries once the failure goes away. One > > > solution (from Dino) is for Y to unicast a hello with GenId 0 to X to > > > request a refresh. This hello likely needs an Ack of some form. > > > > > > - A checksum based approach was mentioned, any progress over there? > > > > > > > > > I can put these points in a few slides. > > > > > > I will attend this IETF (I wasn't sure if I can make it till today). > > > > > > As one of the co-authors of the JP Ack solution/draft, I could help > > > presentating the JP Ack approach, if needed. > > > > > > Thanks, > > > > > > Albert > > > > > > On Fri, 2005-02-25 at 14:29, Dino Farinacci wrote: > > > > >> Yes. This is a good idea. Is anyone willing to summarize the current > > > > >> state of things (pun intended) with a few slides to the working group? > > > > > > > > Since I won't be ablt to attend the IETF, I will brief some of the cisco > > > > guys. I think Mike (and you) were suppose to present that. > > > > > > > > Dino > > > > _______________________________________________ > > > > Pim-state mailing list > > > > Pim-state@mountain2sea.com > > > > http://www.mountain2sea.com/mailman/listinfo/pim-state > > From tian@redback.com Tue Mar 8 00:22:47 2005 Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j285Mkiq011963 for ; Tue, 8 Mar 2005 00:22:47 -0500 (EST) (envelope-from tian@redback.com) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 4F57DD8C06C; Mon, 7 Mar 2005 21:22:41 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14691-05; Mon, 7 Mar 2005 21:22:41 -0800 (PST) Received: from oslo.redback.com (oslo.redback.com [155.53.44.173]) by prattle.redback.com (Postfix) with ESMTP id A9361D8C06B; Mon, 7 Mar 2005 21:22:40 -0800 (PST) Subject: Re: [Pim-state] consensus From: Albert Tian To: Suresh Boddapati In-Reply-To: <20050308033030.85318.qmail@web81309.mail.yahoo.com> References: <20050308033030.85318.qmail@web81309.mail.yahoo.com> Content-Type: text/plain Message-Id: <1110259360.5157.4859.camel@oslo.redback.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 07 Mar 2005 21:22:40 -0800 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Mar 2005 05:22:47 -0000 Hi Suresh, On Mon, 2005-03-07 at 19:30, Suresh Boddapati wrote: > Bob, > On the "still need to come to agreement on": > > 1)The JP Ack packet, whether it is the JP packet clone > or a separate packet with just the sequence number in > it. > > 2)I dont think there is any disagreement on whether JP > Packets should be multicast or unicast. They should be > multicast, otherwise you will not have Join > suppression. My feeling is that you may not be able to really enjoy join supression with refresh reduction. Sure the problem of prune override that I pointed out is not new. The problem just got amplified by the fact that we have no or very long refresh. Before the periodic refresh was serving as the catch all and for many corner cases you may not even realize they are there. So you would agree that if Join suppression can not be achieved, we should send the join unicast, right? > The JP Ack being unicast or multicast is > definitely something we need to agree on. > > On the consensus side: > Explicit tracking is orthogonal to the issue. With > either scheme, explicit tracking can be achieved if > everybody on the LAN supports tracking (disabling Join > suppression). The point that Albert is raising here > regarding Prune override and explicit tracking as a > solution is independent of Refresh reduction. It can > happen with existing PIM and can be solved with > tracking support, which also already exists. The > reliability that we are talking about is between an > upstream and a downstream router in order to reduce > refreshes, we are not necessarily concerned with the > exchange between D1 and U being reliably seen by D2. Well I'm pointing out a case where U has pruned its oif while D2 is still in join state. I don't think this can be viewed orthogonal. IMHO prune override and join suppression goes hand in hand, failure of one will sure cause the failure of the other. Also explicit tracking means no join suppression. If we go with explicit tracking, there is no point sending joins multicast. Thanks, Albert > > > Suresh > --- rkebler@avici.com wrote: > > > These are the major ideas that I think we have come > > to consensus on. > > Let me know if anybody disagrees or I've missed > > anything. > > > > > > > > Consensus: > > ---------- > > > > hello option to advertise capability > > > > new JP Ack messages to make the Joins reliable > > > > JP holdtime will be maintained. > > Never refreshed if holdtime=0xffff, otherwise > > refreshed > > > > method to request full JP state > > > > Explicit Tracking (I think) > > > > > > > > > > Still need to come to agreement on: > > ----------------------------------- > > > > A sequence number per JP message or per route entry > > > > Reliable JP messages should be multicast > > (ALL-PIM-ROUTERS) or unicast > > > > JP ACKs should be multicast (ALL-PIM-ROUTERS) or > > unicast > > > > _______________________________________________ > > Pim-state mailing list > > Pim-state@mountain2sea.com > > > http://www.mountain2sea.com/mailman/listinfo/pim-state > > > > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state From mmcbride@cisco.com Tue Mar 8 00:32:43 2005 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j285Wgor011991 for ; Tue, 8 Mar 2005 00:32:42 -0500 (EST) (envelope-from mmcbride@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 07 Mar 2005 22:49:34 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,145,1107734400"; d="scan'208"; a="232436573:sNHT23929908" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j285WZuC019151; Mon, 7 Mar 2005 21:32:35 -0800 (PST) Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BCO31526; Mon, 7 Mar 2005 21:32:34 -0800 (PST) Date: Mon, 7 Mar 2005 21:32:34 -0800 (PST) From: Mike McBride To: suresh boddapati Subject: RE: [Pim-state] Summary In-Reply-To: <7E90603CF1C63145BD09E0E6FDAD95ECE9F55B@exchange.timetra.timetra.com> Message-ID: References: <7E90603CF1C63145BD09E0E6FDAD95ECE9F55B@exchange.timetra.timetra.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Mar 2005 05:32:43 -0000 I haven't synced up with Tom yet but the more I think about it, I think Tom and I should still give the general overview and how l3vpn will perhaps provide a requirements doc for us, but also you guys have done all the work so far and should share it. Regardless of what happens going further. So unless Tom chimes in saying I'm high, we'll plan on Venu sharing your slides and Albert sharing his. I think we'll have plenty of time and to be honest, its the most interesting thing we've got going right now ;-) This work can continue even while waiting for requirements. But we really did start solving the problem before understanding what the scale of the problem is. Thats what I'm trying to figure out. thanks, mike On Mon, 7 Mar 2005, suresh boddapati wrote: > Mike, > > I was under the impression that the presentation was gonna be only between the chairs like you suggested in your earlier email. If the slides can be presented by someone else, Venu Hemige is there from Alcatel and he has been participating in the discussion as well from the beginning. He can present my slides. Thanks. > > Suresh > > -----Original Message----- > From: pim-state-bounces@mountain2sea.com on behalf of Mike McBride > Sent: Mon 3/7/2005 6:10 PM > To: Albert Tian > Cc: pim-state@mountain2sea.com > Subject: Re: [Pim-state] Summary > > > > Since you are here (and since Suresh and Dino are not) why don't you plan > on taking a few minutes during the wg to discuss this. Tom or I can give > an update on the work and you (and perhaps Bob) can give the details of > the proposed solutions. I have Suresh's slides if you need them, they are > a good review. > > thanks, > mike > > On Mon, 7 Mar 2005, Albert Tian wrote: > > > Hi, > > > > Here are some slides regarding the points I raised. > > > > Thanks, > > > > Albert > > > > On Mon, 2005-03-07 at 15:07, Albert Tian wrote: > > > Hi Dino/Tom/Mike/Suresh, > > > > > > Here are a few issues that were not mentioned in the summary: > > > > > > - One other problem for the TCP based solution is that for MVPN, each of > > > the PIM peering between C-instances would require a seperate TCP > > > connection. One could device a solution that introduces VPN address > > > families for multicast so that the TCP connections can be shared, but > > > that would require more change in the protocol. > > > > > > - Prune override no longer works (therefore join supression does not > > > work either) , because there is no guarantee that the prune from one > > > downstream neighbor is delivered to the other downstream neighbor(s) > > > that need(s) to override it. There are several ways to fix it, but the > > > simplest IMHO is to enable explicit tracking and disable Join > > > suppression. For example U is the upstream and D1,D2 are two downstream > > > neighbors. Both D1 and D2 joined group G, not D1 send out a prune. It is > > > possible that the prune and ack for prune are delivered to U, but not > > > D2. U would prune the oif to D1/D2 while D2 is still in the Group. > > > > > > - Recovery from failed neighbor. All PIM entries learned from that > > > neighbor must be removed. The upstream can either immediately remove > > > them, or start the Expiry Timers with shorter durations and let the > > > timeout process handle it. > > > > > > - Recovery from one way communication failure. In this scenario, say two > > > neighbors X and Y, only X->Y direction is failing. Y will timeout X and > > > delete all the PIM entries learned from X, without X knowing about it. > > > So there needs a way for Y to tell X that it has lost neighbor X, so > > > that X can retransmit all its entries once the failure goes away. One > > > solution (from Dino) is for Y to unicast a hello with GenId 0 to X to > > > request a refresh. This hello likely needs an Ack of some form. > > > > > > - A checksum based approach was mentioned, any progress over there? > > > > > > > > > I can put these points in a few slides. > > > > > > I will attend this IETF (I wasn't sure if I can make it till today). > > > > > > As one of the co-authors of the JP Ack solution/draft, I could help > > > presentating the JP Ack approach, if needed. > > > > > > Thanks, > > > > > > Albert > > > > > > On Fri, 2005-02-25 at 14:29, Dino Farinacci wrote: > > > > >> Yes. This is a good idea. Is anyone willing to summarize the current > > > > >> state of things (pun intended) with a few slides to the working group? > > > > > > > > Since I won't be ablt to attend the IETF, I will brief some of the cisco > > > > guys. I think Mike (and you) were suppose to present that. > > > > > > > > Dino > > > > _______________________________________________ > > > > Pim-state mailing list > > > > Pim-state@mountain2sea.com > > > > http://www.mountain2sea.com/mailman/listinfo/pim-state > > > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state > > > From tian@redback.com Tue Mar 8 00:53:34 2005 Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j285rXht012028 for ; Tue, 8 Mar 2005 00:53:34 -0500 (EST) (envelope-from tian@redback.com) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id CD580D8C06D; Mon, 7 Mar 2005 21:53:25 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06921-04; Mon, 7 Mar 2005 21:53:25 -0800 (PST) Received: from oslo.redback.com (oslo.redback.com [155.53.44.173]) by prattle.redback.com (Postfix) with ESMTP id 2EA69D8C06B; Mon, 7 Mar 2005 21:53:17 -0800 (PST) Subject: RE: [Pim-state] Summary From: Albert Tian To: Mike McBride In-Reply-To: References: <7E90603CF1C63145BD09E0E6FDAD95ECE9F55B@exchange.timetra.timetra.com> Content-Type: text/plain Message-Id: <1110261197.5161.5090.camel@oslo.redback.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 07 Mar 2005 21:53:17 -0800 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Cc: pim-state@mountain2sea.com, suresh boddapati X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Mar 2005 05:53:34 -0000 Hi Mike, That sounds good ... Thanks, Albert On Mon, 2005-03-07 at 21:32, Mike McBride wrote: > I haven't synced up with Tom yet but the more I think about it, I think > Tom and I should still give the general overview and how l3vpn will > perhaps provide a requirements doc for us, but also you guys have done all > the work so far and should share it. Regardless of what happens going > further. So unless Tom chimes in saying I'm high, we'll plan on Venu > sharing your slides and Albert sharing his. I think we'll have plenty of > time and to be honest, its the most interesting thing we've got going > right now ;-) This work can continue even while waiting for requirements. > But we really did start solving the problem before understanding what the > scale of the problem is. Thats what I'm trying to figure out. > > thanks, > mike > > On Mon, 7 Mar 2005, suresh boddapati wrote: > > > Mike, > > > > I was under the impression that the presentation was gonna be only between the chairs like you suggested in your earlier email. If the slides can be presented by someone else, Venu Hemige is there from Alcatel and he has been participating in the discussion as well from the beginning. He can present my slides. Thanks. > > > > Suresh > > > > -----Original Message----- > > From: pim-state-bounces@mountain2sea.com on behalf of Mike McBride > > Sent: Mon 3/7/2005 6:10 PM > > To: Albert Tian > > Cc: pim-state@mountain2sea.com > > Subject: Re: [Pim-state] Summary > > > > > > > > Since you are here (and since Suresh and Dino are not) why don't you plan > > on taking a few minutes during the wg to discuss this. Tom or I can give > > an update on the work and you (and perhaps Bob) can give the details of > > the proposed solutions. I have Suresh's slides if you need them, they are > > a good review. > > > > thanks, > > mike > > > > On Mon, 7 Mar 2005, Albert Tian wrote: > > > > > Hi, > > > > > > Here are some slides regarding the points I raised. > > > > > > Thanks, > > > > > > Albert > > > > > > On Mon, 2005-03-07 at 15:07, Albert Tian wrote: > > > > Hi Dino/Tom/Mike/Suresh, > > > > > > > > Here are a few issues that were not mentioned in the summary: > > > > > > > > - One other problem for the TCP based solution is that for MVPN, each of > > > > the PIM peering between C-instances would require a seperate TCP > > > > connection. One could device a solution that introduces VPN address > > > > families for multicast so that the TCP connections can be shared, but > > > > that would require more change in the protocol. > > > > > > > > - Prune override no longer works (therefore join supression does not > > > > work either) , because there is no guarantee that the prune from one > > > > downstream neighbor is delivered to the other downstream neighbor(s) > > > > that need(s) to override it. There are several ways to fix it, but the > > > > simplest IMHO is to enable explicit tracking and disable Join > > > > suppression. For example U is the upstream and D1,D2 are two downstream > > > > neighbors. Both D1 and D2 joined group G, not D1 send out a prune. It is > > > > possible that the prune and ack for prune are delivered to U, but not > > > > D2. U would prune the oif to D1/D2 while D2 is still in the Group. > > > > > > > > - Recovery from failed neighbor. All PIM entries learned from that > > > > neighbor must be removed. The upstream can either immediately remove > > > > them, or start the Expiry Timers with shorter durations and let the > > > > timeout process handle it. > > > > > > > > - Recovery from one way communication failure. In this scenario, say two > > > > neighbors X and Y, only X->Y direction is failing. Y will timeout X and > > > > delete all the PIM entries learned from X, without X knowing about it. > > > > So there needs a way for Y to tell X that it has lost neighbor X, so > > > > that X can retransmit all its entries once the failure goes away. One > > > > solution (from Dino) is for Y to unicast a hello with GenId 0 to X to > > > > request a refresh. This hello likely needs an Ack of some form. > > > > > > > > - A checksum based approach was mentioned, any progress over there? > > > > > > > > > > > > I can put these points in a few slides. > > > > > > > > I will attend this IETF (I wasn't sure if I can make it till today). > > > > > > > > As one of the co-authors of the JP Ack solution/draft, I could help > > > > presentating the JP Ack approach, if needed. > > > > > > > > Thanks, > > > > > > > > Albert > > > > > > > > On Fri, 2005-02-25 at 14:29, Dino Farinacci wrote: > > > > > >> Yes. This is a good idea. Is anyone willing to summarize the current > > > > > >> state of things (pun intended) with a few slides to the working group? > > > > > > > > > > Since I won't be ablt to attend the IETF, I will brief some of the cisco > > > > > guys. I think Mike (and you) were suppose to present that. > > > > > > > > > > Dino > > > > > _______________________________________________ > > > > > Pim-state mailing list > > > > > Pim-state@mountain2sea.com > > > > > http://www.mountain2sea.com/mailman/listinfo/pim-state > > > > > _______________________________________________ > > Pim-state mailing list > > Pim-state@mountain2sea.com > > http://www.mountain2sea.com/mailman/listinfo/pim-state > > > > > > From sboddapa@yahoo.com Tue Mar 8 00:59:38 2005 Received: from web81301.mail.yahoo.com (web81301.mail.yahoo.com [206.190.37.76]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j285xc31012045 for ; Tue, 8 Mar 2005 00:59:38 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050308055932.81521.qmail@web81301.mail.yahoo.com> Received: from [64.160.53.144] by web81301.mail.yahoo.com via HTTP; Mon, 07 Mar 2005 21:59:32 PST Date: Mon, 7 Mar 2005 21:59:32 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] consensus To: Albert Tian In-Reply-To: <1110259360.5157.4859.camel@oslo.redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Mar 2005 05:59:38 -0000 > My feeling is that you may not be able to really > enjoy join supression > with refresh reduction. > > Sure the problem of prune override that I pointed > out is not new. The > problem just got amplified by the fact that we have > no or very long > refresh. Before the periodic refresh was serving as > the catch all and > for many corner cases you may not even realize they > are there. > > So you would agree that if Join suppression can not > be achieved, we > should send the join unicast, right? > I see your point now. Yes, it makes sense to unicast Joins and get rid of Join suppression altogether. Explicit tracking will have to be a requirement on the part of the upstream router then. From dino@dino-lnx.cisco.com Tue Mar 8 01:45:02 2005 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j286j2S3012127 for ; Tue, 8 Mar 2005 01:45:02 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 07 Mar 2005 22:45:10 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j286ipTM017121 for ; Mon, 7 Mar 2005 22:44:52 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j286ipGm027262 for ; Mon, 7 Mar 2005 22:44:51 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j286ipgr027258; Mon, 7 Mar 2005 22:44:51 -0800 Date: Mon, 7 Mar 2005 22:44:51 -0800 Message-Id: <200503080644.j286ipgr027258@dino-lnx.cisco.com> From: Dino Farinacci To: pim-state@mountain2sea.com Subject: [Pim-state] Reason for multicasting JP-Acks X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Mar 2005 06:45:02 -0000 Folks, just wanted to note the reason we wanted to multicast JP-Acks is so other downstream routers could know the upstream router has received a JP reliably from at least one other downstream router and hence, the receiving JP-Ack downstream router, could suppress a future JP it might want to send. So this is, in a sense doing Join suppression, but not according to the orginal definition, where periodic Joins would/could be suppressed. Dino From dino@dino-lnx.cisco.com Tue Mar 8 03:12:31 2005 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j288CUY0012557 for ; Tue, 8 Mar 2005 03:12:30 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 08 Mar 2005 00:15:25 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,145,1107763200"; d="scan'208"; a="165707576:sNHT16571196" Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j288CMYO000667; Tue, 8 Mar 2005 00:12:23 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j288CKR4030453; Tue, 8 Mar 2005 00:12:20 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j288CIt0030445; Tue, 8 Mar 2005 00:12:18 -0800 Date: Tue, 8 Mar 2005 00:12:18 -0800 Message-Id: <200503080812.j288CIt0030445@dino-lnx.cisco.com> From: Dino Farinacci To: rkebler@avici.com In-reply-to: <52959.10.2.2.223.1110166658.squirrel@webmail.avici.com> (rkebler@avici.com) Subject: Re: [Pim-state] PIM refresh reduction writeup References: <52959.10.2.2.223.1110166658.squirrel@webmail.avici.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Mar 2005 08:12:31 -0000 >> Any thoughts or opinions would be much appreciated. I'm in >> Minneapolis if anybody wants to discuss this topic. Good summary Bob. Dino From pusateri@juniper.net Tue Mar 8 07:56:57 2005 Received: from colo-dns-ext1.juniper.net (colo-dns-ext1.juniper.net [207.17.137.57]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j28CuvFv012991 for ; Tue, 8 Mar 2005 07:56:57 -0500 (EST) (envelope-from pusateri@juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j28Cul919032; Tue, 8 Mar 2005 04:56:51 -0800 (PST) (envelope-from pusateri@juniper.net) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j28Cuge33074; Tue, 8 Mar 2005 04:56:42 -0800 (PST) (envelope-from pusateri@juniper.net) Message-Id: <200503081256.j28Cuge33074@merlot.juniper.net> To: Mike McBride Subject: Re: [Pim-state] Summary In-Reply-To: Message from Mike McBride of "Mon, 07 Mar 2005 21:32:34 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11342.1110286602.1@juniper.net> Date: Tue, 08 Mar 2005 04:56:42 -0800 From: Tom Pusateri Cc: suresh boddapati , pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Mar 2005 12:56:58 -0000 Mike, I'm fine with both Albert and Venu presenting. I also think that while we need to get more input from l3vpn, we also have enough experience with PIM to know some of the problems we faced with the periodic refresh so this effort is needed regardless. Thanks, Tom In message you write: >I haven't synced up with Tom yet but the more I think about it, I think >Tom and I should still give the general overview and how l3vpn will >perhaps provide a requirements doc for us, but also you guys have done all >the work so far and should share it. Regardless of what happens going >further. So unless Tom chimes in saying I'm high, we'll plan on Venu >sharing your slides and Albert sharing his. I think we'll have plenty of >time and to be honest, its the most interesting thing we've got going >right now ;-) This work can continue even while waiting for requirements. >But we really did start solving the problem before understanding what the >scale of the problem is. Thats what I'm trying to figure out. > >thanks, >mike > >On Mon, 7 Mar 2005, suresh boddapati wrote: > >> Mike, >> >> I was under the impression that the presentation was gonna be only between t >he chairs like you suggested in your earlier email. If the slides can be prese >nted by someone else, Venu Hemige is there from Alcatel and he has been partic >ipating in the discussion as well from the beginning. He can present my slides >. Thanks. >> >> Suresh >> >> -----Original Message----- >> From: pim-state-bounces@mountain2sea.com on behalf of Mike McBride >> Sent: Mon 3/7/2005 6:10 PM >> To: Albert Tian >> Cc: pim-state@mountain2sea.com >> Subject: Re: [Pim-state] Summary >> >> >> >> Since you are here (and since Suresh and Dino are not) why don't you pl >an >> on taking a few minutes during the wg to discuss this. Tom or I can giv >e >> an update on the work and you (and perhaps Bob) can give the details of >> the proposed solutions. I have Suresh's slides if you need them, they a >re >> a good review. >> >> thanks, >> mike >> >> On Mon, 7 Mar 2005, Albert Tian wrote: >> >> > Hi, >> > >> > Here are some slides regarding the points I raised. >> > >> > Thanks, >> > >> > Albert >> > >> > On Mon, 2005-03-07 at 15:07, Albert Tian wrote: >> > > Hi Dino/Tom/Mike/Suresh, >> > > >> > > Here are a few issues that were not mentioned in the summary: >> > > >> > > - One other problem for the TCP based solution is that for MVPN, ea >ch of >> > > the PIM peering between C-instances would require a seperate TCP >> > > connection. One could device a solution that introduces VPN address >> > > families for multicast so that the TCP connections can be shared, b >ut >> > > that would require more change in the protocol. >> > > >> > > - Prune override no longer works (therefore join supression does no >t >> > > work either) , because there is no guarantee that the prune from on >e >> > > downstream neighbor is delivered to the other downstream neighbor(s >) >> > > that need(s) to override it. There are several ways to fix it, but >the >> > > simplest IMHO is to enable explicit tracking and disable Join >> > > suppression. For example U is the upstream and D1,D2 are two downst >ream >> > > neighbors. Both D1 and D2 joined group G, not D1 send out a prune. >It is >> > > possible that the prune and ack for prune are delivered to U, but n >ot >> > > D2. U would prune the oif to D1/D2 while D2 is still in the Group. >> > > >> > > - Recovery from failed neighbor. All PIM entries learned from that >> > > neighbor must be removed. The upstream can either immediately remov >e >> > > them, or start the Expiry Timers with shorter durations and let the >> > > timeout process handle it. >> > > >> > > - Recovery from one way communication failure. In this scenario, sa >y two >> > > neighbors X and Y, only X->Y direction is failing. Y will timeout X > and >> > > delete all the PIM entries learned from X, without X knowing about >it. >> > > So there needs a way for Y to tell X that it has lost neighbor X, s >o >> > > that X can retransmit all its entries once the failure goes away. O >ne >> > > solution (from Dino) is for Y to unicast a hello with GenId 0 to X >to >> > > request a refresh. This hello likely needs an Ack of some form. >> > > >> > > - A checksum based approach was mentioned, any progress over there? >> > > >> > > >> > > I can put these points in a few slides. >> > > >> > > I will attend this IETF (I wasn't sure if I can make it till today) >. >> > > >> > > As one of the co-authors of the JP Ack solution/draft, I could help >> > > presentating the JP Ack approach, if needed. >> > > >> > > Thanks, >> > > >> > > Albert >> > > >> > > On Fri, 2005-02-25 at 14:29, Dino Farinacci wrote: >> > > > >> Yes. This is a good idea. Is anyone willing to summarize the c >urrent >> > > > >> state of things (pun intended) with a few slides to the workin >g group? >> > > > >> > > > Since I won't be ablt to attend the IETF, I will brief some o >f the cisco >> > > > guys. I think Mike (and you) were suppose to present that. >> > > > >> > > > Dino >> > > > _______________________________________________ >> > > > Pim-state mailing list >> > > > Pim-state@mountain2sea.com >> > > > http://www.mountain2sea.com/mailman/listinfo/pim-state >> > >> _______________________________________________ >> Pim-state mailing list >> Pim-state@mountain2sea.com >> http://www.mountain2sea.com/mailman/listinfo/pim-state >> >> >> >_______________________________________________ >Pim-state mailing list >Pim-state@mountain2sea.com >http://www.mountain2sea.com/mailman/listinfo/pim-state From rkebler@avici.com Tue Mar 8 11:41:03 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j28Gf3C5013378 for ; Tue, 8 Mar 2005 11:41:03 -0500 (EST) (envelope-from rkebler@avici.com) Received: from webmail.avici.com (mailhost.avici.com [127.0.0.1]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id j28Gec7k009992; Tue, 8 Mar 2005 11:40:38 -0500 Received: from 10.2.2.223 (SquirrelMail authenticated user rkebler) by webmail.avici.com with HTTP; Tue, 8 Mar 2005 11:40:38 -0500 (EST) Message-ID: <57620.10.2.2.223.1110300038.squirrel@webmail.avici.com> In-Reply-To: <200503080644.j286ipgr027258@dino-lnx.cisco.com> References: <200503080644.j286ipgr027258@dino-lnx.cisco.com> Date: Tue, 8 Mar 2005 11:40:38 -0500 (EST) Subject: Re: [Pim-state] Reason for multicasting JP-Acks From: rkebler@avici.com To: "Dino Farinacci" User-Agent: SquirrelMail/1.4.0-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Mar 2005 16:41:03 -0000 Dino, I think we can get rid of Join Suppression all together with reliable ACKS. The downstream nodes will not suppress their Joins at all which means they do not need to even process the message, which means they can be unicast. If a Join is suppressed but a Prune is missed by a downstream router, then it will not override. I think we're better off with no Join Suppression/Prune Override and unicast JPs. > Folks, just wanted to note the reason we wanted to multicast JP-Acks > is > so other downstream routers could know the upstream router has > received > a JP reliably from at least one other downstream router and hence, the > receiving JP-Ack downstream router, could suppress a future JP it > might > want to send. > > So this is, in a sense doing Join suppression, but not according to > the > orginal definition, where periodic Joins would/could be suppressed. > > Dino > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state > From rkebler@avici.com Tue Mar 8 11:43:48 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j28GhmOh013389 for ; Tue, 8 Mar 2005 11:43:48 -0500 (EST) (envelope-from rkebler@avici.com) Received: from webmail.avici.com (mailhost.avici.com [127.0.0.1]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id j28Ghe7k010366; Tue, 8 Mar 2005 11:43:40 -0500 Received: from 10.2.2.223 (SquirrelMail authenticated user rkebler) by webmail.avici.com with HTTP; Tue, 8 Mar 2005 11:43:40 -0500 (EST) Message-ID: <57635.10.2.2.223.1110300220.squirrel@webmail.avici.com> In-Reply-To: <20050308055932.81521.qmail@web81301.mail.yahoo.com> References: <1110259360.5157.4859.camel@oslo.redback.com> <20050308055932.81521.qmail@web81301.mail.yahoo.com> Date: Tue, 8 Mar 2005 11:43:40 -0500 (EST) Subject: Re: [Pim-state] consensus From: rkebler@avici.com To: "Suresh Boddapati" User-Agent: SquirrelMail/1.4.0-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Mar 2005 16:43:49 -0000 So are you in agreement of the consensus list if we add 'where to put the sequence number' as an added bullet under 'need to come to aggrement'? >> My feeling is that you may not be able to really >> enjoy join supression >> with refresh reduction. >> >> Sure the problem of prune override that I pointed >> out is not new. The >> problem just got amplified by the fact that we have >> no or very long >> refresh. Before the periodic refresh was serving as >> the catch all and >> for many corner cases you may not even realize they >> are there. >> >> So you would agree that if Join suppression can not >> be achieved, we >> should send the join unicast, right? >> > > I see your point now. Yes, it makes sense to unicast > Joins and get rid of Join suppression altogether. > Explicit tracking will have to be a requirement on the > part of the upstream router then. > From sboddapa@yahoo.com Tue Mar 8 12:46:33 2005 Received: from web81301.mail.yahoo.com (web81301.mail.yahoo.com [206.190.37.76]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j28HkW7H013494 for ; Tue, 8 Mar 2005 12:46:33 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050308174627.7428.qmail@web81301.mail.yahoo.com> Received: from [64.160.53.144] by web81301.mail.yahoo.com via HTTP; Tue, 08 Mar 2005 09:46:27 PST Date: Tue, 8 Mar 2005 09:46:27 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] consensus To: rkebler@avici.com In-Reply-To: <57635.10.2.2.223.1110300220.squirrel@webmail.avici.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Mar 2005 17:46:33 -0000 Bob, Yes, we need to decide where the sequence number goes in the JP PDU. But it's ultimately which ACK scheme we want to use, that we need to come to agreement on (which will determine IMO where the sequence number goes). There are two schemes currently which finally need to converge. Dino's scheme has the JP Ack packet as a clone of the original JP packet. The rationale being (correct me Dino if I am wrong) 1)Sending acks is easy since just the PDU type needs to be changed, 2)The downstream routers get a second chance to see the Joins in order to suppress their own Joins. Squeezing the sequence number into the reserved field was an add on after our discussions, but again the motive here was that the JP ACK PDU should be a clone of JP PDU. Note that even with a TLV at the end, relaying the JP Packet back on the LAN with just the type modified should still be fine. But if we are saying that Explicit Tracking is essential (Albert's point on Prunes being missed by other downstream routers), Join suppression should be taken out and PIM Joins are to be unicast, then there is not much point in the JP Ack packet being a clone of the JP packet (and hence exhausting the reserved field for sequence number is not necessary). A TLV scheme is much better IMO. Note that the reserved field is only 1 byte. If implementations do not pack, with a worst case of 1 state per JP PDU, there could be only 256 unacked states (much less if you consider the same state changing while an ACK is pending). Suresh --- rkebler@avici.com wrote: > So are you in agreement of the consensus list if > we add 'where to put the sequence number' as > an added bullet under 'need to come to aggrement'? > > > >> My feeling is that you may not be able to really > >> enjoy join supression > >> with refresh reduction. > >> > >> Sure the problem of prune override that I pointed > >> out is not new. The > >> problem just got amplified by the fact that we > have > >> no or very long > >> refresh. Before the periodic refresh was serving > as > >> the catch all and > >> for many corner cases you may not even realize > they > >> are there. > >> > >> So you would agree that if Join suppression can > not > >> be achieved, we > >> should send the join unicast, right? > >> > > > > I see your point now. Yes, it makes sense to > unicast > > Joins and get rid of Join suppression altogether. > > Explicit tracking will have to be a requirement on > the > > part of the upstream router then. > > > > From rkebler@avici.com Tue Mar 8 13:45:25 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j28IjMTL014008 for ; Tue, 8 Mar 2005 13:45:23 -0500 (EST) (envelope-from rkebler@avici.com) Received: from webmail.avici.com (mailhost.avici.com [127.0.0.1]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id j28IjF7k000838; Tue, 8 Mar 2005 13:45:15 -0500 Received: from 10.2.2.223 (SquirrelMail authenticated user rkebler) by webmail.avici.com with HTTP; Tue, 8 Mar 2005 13:45:15 -0500 (EST) Message-ID: <58000.10.2.2.223.1110307515.squirrel@webmail.avici.com> In-Reply-To: <20050308174627.7428.qmail@web81301.mail.yahoo.com> References: <57635.10.2.2.223.1110300220.squirrel@webmail.avici.com> <20050308174627.7428.qmail@web81301.mail.yahoo.com> Date: Tue, 8 Mar 2005 13:45:15 -0500 (EST) Subject: Re: [Pim-state] consensus From: rkebler@avici.com To: "Suresh Boddapati" User-Agent: SquirrelMail/1.4.0-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Mar 2005 18:45:25 -0000 The list had 'A sequence number per JP message or per route entry'. This was the major issue that I felt needed to be resolved. Aren't you simply agreeing that this is the issue. If you agree with the list then we try to close on the open issues. For the open issues, I think JP and ACK messages should be unicast, and a sequence number per JP message is the way to go. Are there any differing opinions? Thanks, Bob ---------------------------------------------------------------- Consensus: hello option to advertise capability new JP Ack messages to make the Joins reliable JP holdtime will be maintained. Never refreshed if holdtime=0xffff, otherwise refreshed method to request full JP state Explicit Tracking Still need to come to agreement on: A sequence number per JP message or per route entry Reliable JP messages should be multicast (ALL-PIM-ROUTERS) or unicast JP ACKs should be multicast (ALL-PIM-ROUTERS) or unicast > Bob, > Yes, we need to decide where the sequence number goes > in the JP PDU. But it's ultimately which ACK scheme we > want to use, that we need to come to agreement on > (which will determine IMO where the sequence number > goes). There are two schemes currently which finally > need to converge. Dino's scheme has the JP Ack packet > as a clone of the original JP packet. The rationale > being (correct me Dino if I am wrong) 1)Sending acks > is easy since just the PDU type needs to be changed, > 2)The downstream routers get a second chance to see > the Joins in order to suppress their own Joins. > Squeezing the sequence number into the reserved field > was an add on after our discussions, but again the > motive here was that the JP ACK PDU should be a clone > of JP PDU. Note that even with a TLV at the end, > relaying the JP Packet back on the LAN with just the > type modified should still be fine. > > But if we are saying that Explicit Tracking is > essential (Albert's point on Prunes being missed by > other downstream routers), Join suppression should be > taken out and PIM Joins are to be unicast, then there > is not much point in the JP Ack packet being a clone > of the JP packet (and hence exhausting the reserved > field for sequence number is not necessary). A TLV > scheme is much better IMO. Note that the reserved > field is only 1 byte. If implementations do not pack, > with a worst case of 1 state per JP PDU, there could > be only 256 unacked states (much less if you consider > the same state changing while an ACK is pending). > > Suresh > > --- rkebler@avici.com wrote: > >> So are you in agreement of the consensus list if >> we add 'where to put the sequence number' as >> an added bullet under 'need to come to aggrement'? >> >> >> >> My feeling is that you may not be able to really >> >> enjoy join supression >> >> with refresh reduction. >> >> >> >> Sure the problem of prune override that I pointed >> >> out is not new. The >> >> problem just got amplified by the fact that we >> have >> >> no or very long >> >> refresh. Before the periodic refresh was serving >> as >> >> the catch all and >> >> for many corner cases you may not even realize >> they >> >> are there. >> >> >> >> So you would agree that if Join suppression can >> not >> >> be achieved, we >> >> should send the join unicast, right? >> >> >> > >> > I see your point now. Yes, it makes sense to >> unicast >> > Joins and get rid of Join suppression altogether. >> > Explicit tracking will have to be a requirement on >> the >> > part of the upstream router then. >> > >> >> > From suresh.boddapati@alcatel.com Tue Mar 8 14:15:17 2005 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j28JFGWM014072 for ; Tue, 8 Mar 2005 14:15:17 -0500 (EST) (envelope-from suresh.boddapati@alcatel.com) Received: from alcatelxp ([172.22.187.74] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 8 Mar 2005 11:15:06 -0800 From: "Suresh Boddapati" To: , "'Suresh Boddapati'" Subject: RE: [Pim-state] consensus Date: Tue, 8 Mar 2005 11:15:15 -0800 Organization: Alcatel USA Message-ID: <046001c52413$2b4afb40$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <58000.10.2.2.223.1110307515.squirrel@webmail.avici.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 08 Mar 2005 19:15:06.0488 (UTC) FILETIME=[2348CF80:01C52413] Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: suresh.boddapati@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Tue, 08 Mar 2005 19:15:17 -0000 Bob, > > The list had 'A sequence number per JP message or per route > entry'. This was the major issue that I felt needed to be > resolved. Aren't you simply agreeing that this is the issue. Yes. Suresh From rkebler@avici.com Tue Mar 8 19:11:17 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j290BHOU019628 for ; Tue, 8 Mar 2005 19:11:17 -0500 (EST) (envelope-from rkebler@avici.com) Received: from webmail.avici.com (mailhost.avici.com [127.0.0.1]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id j290BB7k023327; Tue, 8 Mar 2005 19:11:11 -0500 Received: from 10.2.2.223 (SquirrelMail authenticated user rkebler) by webmail.avici.com with HTTP; Tue, 8 Mar 2005 19:11:11 -0500 (EST) Message-ID: <59399.10.2.2.223.1110327071.squirrel@webmail.avici.com> In-Reply-To: <200503081256.j28Cuge33074@merlot.juniper.net> References: Message from Mike McBride of "Mon, 07 Mar 2005 21:32:34 PST." <200503081256.j28Cuge33074@merlot.juniper.net> Date: Tue, 8 Mar 2005 19:11:11 -0500 (EST) Subject: Re: [Pim-state] Summary From: rkebler@avici.com To: "suresh boddapati" User-Agent: SquirrelMail/1.4.0-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 00:11:17 -0000 Suresh, Under "Suresh's scheme" in your slides, it does not appear that you describe the proposal that you sent to the list. Your proposal had a 32-bit message-id and a 32 sequence number with message-id being refreshed periodically in a new "refresh message". Was your intention to descibe this under Suresh's scheme? Or was your intention to describe using only a 32-bit id with the normal JP refresh procedures, and calling this "Suresh's scheme". Thanks, Bob > Mike, > > I'm fine with both Albert and Venu presenting. > > I also think that while we need to get more input from l3vpn, we also > have enough experience with PIM to know some of the problems we faced > with the periodic refresh so this effort is needed regardless. > > Thanks, > Tom > > In message you > write: >>I haven't synced up with Tom yet but the more I think about it, I think >>Tom and I should still give the general overview and how l3vpn will >>perhaps provide a requirements doc for us, but also you guys have done >> all >>the work so far and should share it. Regardless of what happens going >>further. So unless Tom chimes in saying I'm high, we'll plan on Venu >>sharing your slides and Albert sharing his. I think we'll have plenty of >>time and to be honest, its the most interesting thing we've got going >>right now ;-) This work can continue even while waiting for requirements. >>But we really did start solving the problem before understanding what the >>scale of the problem is. Thats what I'm trying to figure out. >> >>thanks, >>mike >> >>On Mon, 7 Mar 2005, suresh boddapati wrote: >> >>> Mike, >>> >>> I was under the impression that the presentation was gonna be only >>> between t >>he chairs like you suggested in your earlier email. If the slides can be >> prese >>nted by someone else, Venu Hemige is there from Alcatel and he has been >> partic >>ipating in the discussion as well from the beginning. He can present my >> slides >>. Thanks. >>> >>> Suresh >>> >>> -----Original Message----- >>> From: pim-state-bounces@mountain2sea.com on behalf of Mike McBride >>> Sent: Mon 3/7/2005 6:10 PM >>> To: Albert Tian >>> Cc: pim-state@mountain2sea.com >>> Subject: Re: [Pim-state] Summary >>> >>> >>> >>> Since you are here (and since Suresh and Dino are not) why don't you >>> pl >>an >>> on taking a few minutes during the wg to discuss this. Tom or I can >>> giv >>e >>> an update on the work and you (and perhaps Bob) can give the details >>> of >>> the proposed solutions. I have Suresh's slides if you need them, they >>> a >>re >>> a good review. >>> >>> thanks, >>> mike >>> >>> On Mon, 7 Mar 2005, Albert Tian wrote: >>> >>> > Hi, >>> > >>> > Here are some slides regarding the points I raised. >>> > >>> > Thanks, >>> > >>> > Albert >>> > >>> > On Mon, 2005-03-07 at 15:07, Albert Tian wrote: >>> > > Hi Dino/Tom/Mike/Suresh, >>> > > >>> > > Here are a few issues that were not mentioned in the summary: >>> > > >>> > > - One other problem for the TCP based solution is that for MVPN, >>> ea >>ch of >>> > > the PIM peering between C-instances would require a seperate TCP >>> > > connection. One could device a solution that introduces VPN >>> address >>> > > families for multicast so that the TCP connections can be shared, >>> b >>ut >>> > > that would require more change in the protocol. >>> > > >>> > > - Prune override no longer works (therefore join supression does >>> no >>t >>> > > work either) , because there is no guarantee that the prune from >>> on >>e >>> > > downstream neighbor is delivered to the other downstream >>> neighbor(s >>) >>> > > that need(s) to override it. There are several ways to fix it, but >>the >>> > > simplest IMHO is to enable explicit tracking and disable Join >>> > > suppression. For example U is the upstream and D1,D2 are two >>> downst >>ream >>> > > neighbors. Both D1 and D2 joined group G, not D1 send out a prune. >>It is >>> > > possible that the prune and ack for prune are delivered to U, but >>> n >>ot >>> > > D2. U would prune the oif to D1/D2 while D2 is still in the Group. >>> > > >>> > > - Recovery from failed neighbor. All PIM entries learned from that >>> > > neighbor must be removed. The upstream can either immediately >>> remov >>e >>> > > them, or start the Expiry Timers with shorter durations and let >>> the >>> > > timeout process handle it. >>> > > >>> > > - Recovery from one way communication failure. In this scenario, >>> sa >>y two >>> > > neighbors X and Y, only X->Y direction is failing. Y will timeout >>> X >> and >>> > > delete all the PIM entries learned from X, without X knowing about >>it. >>> > > So there needs a way for Y to tell X that it has lost neighbor X, >>> s >>o >>> > > that X can retransmit all its entries once the failure goes away. >>> O >>ne >>> > > solution (from Dino) is for Y to unicast a hello with GenId 0 to X >>to >>> > > request a refresh. This hello likely needs an Ack of some form. >>> > > >>> > > - A checksum based approach was mentioned, any progress over >>> there? >>> > > >>> > > >>> > > I can put these points in a few slides. >>> > > >>> > > I will attend this IETF (I wasn't sure if I can make it till >>> today) >>. >>> > > >>> > > As one of the co-authors of the JP Ack solution/draft, I could >>> help >>> > > presentating the JP Ack approach, if needed. >>> > > >>> > > Thanks, >>> > > >>> > > Albert >>> > > >>> > > On Fri, 2005-02-25 at 14:29, Dino Farinacci wrote: >>> > > > >> Yes. This is a good idea. Is anyone willing to summarize the >>> c >>urrent >>> > > > >> state of things (pun intended) with a few slides to the >>> workin >>g group? >>> > > > >>> > > > Since I won't be ablt to attend the IETF, I will brief some >>> o >>f the cisco >>> > > > guys. I think Mike (and you) were suppose to present that. >>> > > > >>> > > > Dino >>> > > > _______________________________________________ >>> > > > Pim-state mailing list >>> > > > Pim-state@mountain2sea.com >>> > > > http://www.mountain2sea.com/mailman/listinfo/pim-state >>> > >>> _______________________________________________ >>> Pim-state mailing list >>> Pim-state@mountain2sea.com >>> http://www.mountain2sea.com/mailman/listinfo/pim-state >>> >>> >>> >>_______________________________________________ >>Pim-state mailing list >>Pim-state@mountain2sea.com >>http://www.mountain2sea.com/mailman/listinfo/pim-state > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state > From suresh.boddapati@alcatel.com Tue Mar 8 20:44:30 2005 Received: from exchange.timetra.com (host-64-47-51-130.masergy.com [64.47.51.130] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j291iTgX019763 for ; Tue, 8 Mar 2005 20:44:30 -0500 (EST) (envelope-from suresh.boddapati@alcatel.com) Received: from alcatelxp ([172.22.187.74] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 8 Mar 2005 17:44:20 -0800 From: "Suresh Boddapati" To: , "'suresh boddapati'" Subject: RE: [Pim-state] Summary Date: Tue, 8 Mar 2005 17:45:30 -0800 Organization: Alcatel USA Message-ID: <04a801c52449$aec00700$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <59399.10.2.2.223.1110327071.squirrel@webmail.avici.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 09 Mar 2005 01:44:20.0589 (UTC) FILETIME=[8369D1D0:01C52449] Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: suresh.boddapati@alcatel.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 01:44:30 -0000 Bob, I thought we had gone past that stage. Based on the discussions on this list, and based on the consensus that there was not much interest in having regular refreshes (even if they were condensed), I had modified my scheme to remove the Refresh message (the email titled Summary that I originated a while back says so) and have only the TLV for ACK purposes. I originally had both message ID and sequence number in it, but I think it was your suggestion to have only one 32 bit number. That's the only change. The intention was to give an update on where we are at, not where we started at and everything that was discussed. It seems like you are saying that this scheme should not be called "Suresh's scheme". Are you? Suresh > -----Original Message----- > From: rkebler@avici.com [mailto:rkebler@avici.com] > Sent: Tuesday, March 08, 2005 4:11 PM > To: suresh boddapati > Cc: pim-state@mountain2sea.com > Subject: Re: [Pim-state] Summary > > Suresh, > Under "Suresh's scheme" in your slides, it does not appear that you > describe the proposal that you sent to the list. Your > proposal had a 32-bit message-id and a 32 sequence number with > message-id being refreshed periodically in a new "refresh > message". Was your intention to descibe this under Suresh's > scheme? Or was your intention to describe using only a 32-bit > id with the normal JP refresh procedures, and calling this > "Suresh's scheme". > > Thanks, > Bob > > > > > > Mike, > > > > I'm fine with both Albert and Venu presenting. > > > > I also think that while we need to get more input from l3vpn, we also > > have enough experience with PIM to know some of the problems we faced > > with the periodic refresh so this effort is needed regardless. > > > > Thanks, > > Tom > > > > In message you > > write: > >>I haven't synced up with Tom yet but the more I think about it, I think > >>Tom and I should still give the general overview and how l3vpn will > >>perhaps provide a requirements doc for us, but also you guys have done > >> all > >>the work so far and should share it. Regardless of what happens going > >>further. So unless Tom chimes in saying I'm high, we'll plan on Venu > >>sharing your slides and Albert sharing his. I think we'll have plenty of > >>time and to be honest, its the most interesting thing we've got going > >>right now ;-) This work can continue even while waiting for > requirements. > >>But we really did start solving the problem before understanding what > the > >>scale of the problem is. Thats what I'm trying to figure out. > >> > >>thanks, > >>mike > >> > >>On Mon, 7 Mar 2005, suresh boddapati wrote: > >> > >>> Mike, > >>> > >>> I was under the impression that the presentation was gonna be only > >>> between t > >>he chairs like you suggested in your earlier email. If the slides can be > >> prese > >>nted by someone else, Venu Hemige is there from Alcatel and he has been > >> partic > >>ipating in the discussion as well from the beginning. He can present my > >> slides > >>. Thanks. > >>> > >>> Suresh > >>> > >>> -----Original Message----- > >>> From: pim-state-bounces@mountain2sea.com on behalf of Mike McBride > >>> Sent: Mon 3/7/2005 6:10 PM > >>> To: Albert Tian > >>> Cc: pim-state@mountain2sea.com > >>> Subject: Re: [Pim-state] Summary > >>> > >>> > >>> > >>> Since you are here (and since Suresh and Dino are not) why don't you > >>> pl > >>an > >>> on taking a few minutes during the wg to discuss this. Tom or I can > >>> giv > >>e > >>> an update on the work and you (and perhaps Bob) can give the details > >>> of > >>> the proposed solutions. I have Suresh's slides if you need them, > they > >>> a > >>re > >>> a good review. > >>> > >>> thanks, > >>> mike > >>> > >>> On Mon, 7 Mar 2005, Albert Tian wrote: > >>> > >>> > Hi, > >>> > > >>> > Here are some slides regarding the points I raised. > >>> > > >>> > Thanks, > >>> > > >>> > Albert > >>> > > >>> > On Mon, 2005-03-07 at 15:07, Albert Tian wrote: > >>> > > Hi Dino/Tom/Mike/Suresh, > >>> > > > >>> > > Here are a few issues that were not mentioned in the summary: > >>> > > > >>> > > - One other problem for the TCP based solution is that for MVPN, > >>> ea > >>ch of > >>> > > the PIM peering between C-instances would require a seperate TCP > >>> > > connection. One could device a solution that introduces VPN > >>> address > >>> > > families for multicast so that the TCP connections can be > shared, > >>> b > >>ut > >>> > > that would require more change in the protocol. > >>> > > > >>> > > - Prune override no longer works (therefore join supression does > >>> no > >>t > >>> > > work either) , because there is no guarantee that the prune from > >>> on > >>e > >>> > > downstream neighbor is delivered to the other downstream > >>> neighbor(s > >>) > >>> > > that need(s) to override it. There are several ways to fix it, > but > >>the > >>> > > simplest IMHO is to enable explicit tracking and disable Join > >>> > > suppression. For example U is the upstream and D1,D2 are two > >>> downst > >>ream > >>> > > neighbors. Both D1 and D2 joined group G, not D1 send out a > prune. > >>It is > >>> > > possible that the prune and ack for prune are delivered to U, > but > >>> n > >>ot > >>> > > D2. U would prune the oif to D1/D2 while D2 is still in the > Group. > >>> > > > >>> > > - Recovery from failed neighbor. All PIM entries learned from > that > >>> > > neighbor must be removed. The upstream can either immediately > >>> remov > >>e > >>> > > them, or start the Expiry Timers with shorter durations and let > >>> the > >>> > > timeout process handle it. > >>> > > > >>> > > - Recovery from one way communication failure. In this scenario, > >>> sa > >>y two > >>> > > neighbors X and Y, only X->Y direction is failing. Y will > timeout > >>> X > >> and > >>> > > delete all the PIM entries learned from X, without X knowing > about > >>it. > >>> > > So there needs a way for Y to tell X that it has lost neighbor > X, > >>> s > >>o > >>> > > that X can retransmit all its entries once the failure goes > away. > >>> O > >>ne > >>> > > solution (from Dino) is for Y to unicast a hello with GenId 0 to > X > >>to > >>> > > request a refresh. This hello likely needs an Ack of some form. > >>> > > > >>> > > - A checksum based approach was mentioned, any progress over > >>> there? > >>> > > > >>> > > > >>> > > I can put these points in a few slides. > >>> > > > >>> > > I will attend this IETF (I wasn't sure if I can make it till > >>> today) > >>. > >>> > > > >>> > > As one of the co-authors of the JP Ack solution/draft, I could > >>> help > >>> > > presentating the JP Ack approach, if needed. > >>> > > > >>> > > Thanks, > >>> > > > >>> > > Albert > >>> > > > >>> > > On Fri, 2005-02-25 at 14:29, Dino Farinacci wrote: > >>> > > > >> Yes. This is a good idea. Is anyone willing to summarize > the > >>> c > >>urrent > >>> > > > >> state of things (pun intended) with a few slides to the > >>> workin > >>g group? > >>> > > > > >>> > > > Since I won't be ablt to attend the IETF, I will brief > some > >>> o > >>f the cisco > >>> > > > guys. I think Mike (and you) were suppose to present that. > >>> > > > > >>> > > > Dino > >>> > > > _______________________________________________ > >>> > > > Pim-state mailing list > >>> > > > Pim-state@mountain2sea.com > >>> > > > http://www.mountain2sea.com/mailman/listinfo/pim-state > >>> > > >>> _______________________________________________ > >>> Pim-state mailing list > >>> Pim-state@mountain2sea.com > >>> http://www.mountain2sea.com/mailman/listinfo/pim-state > >>> > >>> > >>> > >>_______________________________________________ > >>Pim-state mailing list > >>Pim-state@mountain2sea.com > >>http://www.mountain2sea.com/mailman/listinfo/pim-state > > _______________________________________________ > > Pim-state mailing list > > Pim-state@mountain2sea.com > > http://www.mountain2sea.com/mailman/listinfo/pim-state > > From dino@dino-lnx.cisco.com Tue Mar 8 21:11:59 2005 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j292Bwxl019821 for ; Tue, 8 Mar 2005 21:11:59 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2005 18:12:19 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j292BmYO025260; Tue, 8 Mar 2005 18:11:51 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j292BlXI014032; Tue, 8 Mar 2005 18:11:48 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j292BgZ6014026; Tue, 8 Mar 2005 18:11:42 -0800 Date: Tue, 8 Mar 2005 18:11:42 -0800 Message-Id: <200503090211.j292BgZ6014026@dino-lnx.cisco.com> From: Dino Farinacci To: rkebler@avici.com In-reply-to: <57620.10.2.2.223.1110300038.squirrel@webmail.avici.com> (rkebler@avici.com) Subject: Re: [Pim-state] Reason for multicasting JP-Acks References: <200503080644.j286ipgr027258@dino-lnx.cisco.com> <57620.10.2.2.223.1110300038.squirrel@webmail.avici.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 02:11:59 -0000 >> Dino, I think we can get rid of Join Suppression all together with >> reliable ACKS. The downstream nodes will not suppress their Joins >> at all which means they do not need to even process the message, On a multi-access network, where state is already created in an upstream router, and a downstream router gets a triggered Join from onen of it's downstream routers for the same state, wouldn't it be good to not have to send the Join? "Triggered Join Suppression" is one of the mechanisms to get the protocol to scale better. That is why I think we should continue to *want* Join suppression in the proposal. We are not talking about "Periodic Join Suppression" because periodic JPs will go away but "Triggered Join Suppression". Dino From dino@dino-lnx.cisco.com Tue Mar 8 21:18:33 2005 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j292IXQL019838 for ; Tue, 8 Mar 2005 21:18:33 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2005 18:18:54 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j292IPTM004803; Tue, 8 Mar 2005 18:18:26 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j292IPHd014179; Tue, 8 Mar 2005 18:18:25 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j292IPpK014175; Tue, 8 Mar 2005 18:18:25 -0800 Date: Tue, 8 Mar 2005 18:18:25 -0800 Message-Id: <200503090218.j292IPpK014175@dino-lnx.cisco.com> From: Dino Farinacci To: sboddapa@yahoo.com In-reply-to: <20050308174627.7428.qmail@web81301.mail.yahoo.com> (message from Suresh Boddapati on Tue, 8 Mar 2005 09:46:27 -0800 (PST)) Subject: Re: [Pim-state] consensus References: <20050308174627.7428.qmail@web81301.mail.yahoo.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 02:18:33 -0000 >> as a clone of the original JP packet. The rationale >> being (correct me Dino if I am wrong) 1)Sending acks >> is easy since just the PDU type needs to be changed, True. >> 2)The downstream routers get a second chance to see >> the Joins in order to suppress their own Joins. True. >> Squeezing the sequence number into the reserved field >> was an add on after our discussions, but again the >> motive here was that the JP ACK PDU should be a clone >> of JP PDU. Note that even with a TLV at the end, Right. The point about should the sequence number go per route versus per message in it's own right is not so important. My main concern is how flow-control will be done. And if you build a transmission layer below the PIM topology table, I'm worried about the additional buffering requirements in PIM. I've mentioned this before, but if you can suppress J-P-J-P-J events and able to guarantee that the last J was received by the upstream router, then this is a good scaling benefit. So by adding sequence numbers to each of the routes above, could allow you to suppress and reliably deliver the route state. Having said that, let's put sequence numbers on the above messages so you have J1-P2-J3-P4-J5. So if a transmitter sends J1 through J5 and only gets an ack for J5 back, it should be happy (and can remove any state or timers associated with wanting to retransmit J1-P4). You will get a damping effect of not oscillating the tree branch. This is a good thing. Dino From rkebler@avici.com Tue Mar 8 22:56:44 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j293uicQ019988 for ; Tue, 8 Mar 2005 22:56:44 -0500 (EST) (envelope-from rkebler@avici.com) Received: from webmail.avici.com (mailhost.avici.com [127.0.0.1]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id j293ub7k016817; Tue, 8 Mar 2005 22:56:37 -0500 Received: from 10.2.2.223 (SquirrelMail authenticated user rkebler) by webmail.avici.com with HTTP; Tue, 8 Mar 2005 22:56:37 -0500 (EST) Message-ID: <60102.10.2.2.223.1110340597.squirrel@webmail.avici.com> In-Reply-To: <200503090211.j292BgZ6014026@dino-lnx.cisco.com> References: <200503080644.j286ipgr027258@dino-lnx.cisco.com> <57620.10.2.2.223.1110300038.squirrel@webmail.avici.com> <200503090211.j292BgZ6014026@dino-lnx.cisco.com> Date: Tue, 8 Mar 2005 22:56:37 -0500 (EST) Subject: Re: [Pim-state] Reason for multicasting JP-Acks From: rkebler@avici.com To: "Dino Farinacci" User-Agent: SquirrelMail/1.4.0-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 03:56:44 -0000 >>> Dino, I think we can get rid of Join Suppression all together with >>> reliable ACKS. The downstream nodes will not suppress their Joins >>> at all which means they do not need to even process the message, > > On a multi-access network, where state is already created in an > upstream > router, and a downstream router gets a triggered Join from onen of > it's > downstream routers for the same state, wouldn't it be good to not have > to send the Join? > > "Triggered Join Suppression" is one of the mechanisms to get the > protocol > to scale better. That is why I think we should continue to *want* Join > suppression in the proposal. We are not talking about "Periodic Join > Suppression" because periodic JPs will go away but "Triggered Join > Suppression". > > Dino > I think you have limited benefits of Join Suppression if the Joins are reliable. One scenario that causes problems would be if a Join is suppressed by downstream node A because it receives a Join from downstream node B. If B sends a prune, then A must override the prune with a Join. Now, what if this prune does not reach A. Then A will not override and this interface will be removed from the upstream router. There will not be periodic Joins (or the refreshes will be few and far between) to cleanup this state. I think it is nice to get rid of Join Suppression all together. It is nice that other downstream nodes don't even have to receive these messages and then they can be unicast. Regards, Bob From rkebler@avici.com Tue Mar 8 23:04:08 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j29447g6020014 for ; Tue, 8 Mar 2005 23:04:07 -0500 (EST) (envelope-from rkebler@avici.com) Received: from webmail.avici.com (mailhost.avici.com [127.0.0.1]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id j2943w7k017415; Tue, 8 Mar 2005 23:03:58 -0500 Received: from 10.2.2.223 (SquirrelMail authenticated user rkebler) by webmail.avici.com with HTTP; Tue, 8 Mar 2005 23:03:58 -0500 (EST) Message-ID: <60123.10.2.2.223.1110341038.squirrel@webmail.avici.com> In-Reply-To: <04a801c52449$aec00700$4abb16ac@alcatelxp> References: <59399.10.2.2.223.1110327071.squirrel@webmail.avici.com> <04a801c52449$aec00700$4abb16ac@alcatelxp> Date: Tue, 8 Mar 2005 23:03:58 -0500 (EST) Subject: RE: [Pim-state] Summary From: rkebler@avici.com To: suresh.boddapati@alcatel.com User-Agent: SquirrelMail/1.4.0-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 04:04:08 -0000 Right, I don't think it should be called 'Suresh's scheme' in that case. Also, the removal of the new refresh message type was my suggestion also. Regards, Bob > Bob, > I thought we had gone past that stage. Based on the discussions on this > list, and based on the consensus that there was not much interest in > having regular refreshes (even if they were condensed), I had modified > my scheme to remove the Refresh message (the email titled Summary that I > originated a while back says so) and have only the TLV for ACK purposes. > I originally had both message ID and sequence number in it, but I think > it was your suggestion to have only one 32 bit number. That's the only > change. The intention was to give an update on where we are at, not > where we started at and everything that was discussed. It seems like you > are saying that this scheme should not be called "Suresh's scheme". Are > you? > > Suresh > >> -----Original Message----- >> From: rkebler@avici.com [mailto:rkebler@avici.com] >> Sent: Tuesday, March 08, 2005 4:11 PM >> To: suresh boddapati >> Cc: pim-state@mountain2sea.com >> Subject: Re: [Pim-state] Summary >> >> Suresh, >> Under "Suresh's scheme" in your slides, it does not appear that you >> describe the proposal that you sent to the list. Your >> proposal had a 32-bit message-id and a 32 sequence number with >> message-id being refreshed periodically in a new "refresh >> message". Was your intention to descibe this under Suresh's >> scheme? Or was your intention to describe using only a 32-bit >> id with the normal JP refresh procedures, and calling this >> "Suresh's scheme". >> >> Thanks, >> Bob >> >> >> >> >> > Mike, >> > >> > I'm fine with both Albert and Venu presenting. >> > >> > I also think that while we need to get more input from l3vpn, we > also >> > have enough experience with PIM to know some of the problems we > faced >> > with the periodic refresh so this effort is needed regardless. >> > >> > Thanks, >> > Tom >> > >> > In message > you >> > write: >> >>I haven't synced up with Tom yet but the more I think about it, I > think >> >>Tom and I should still give the general overview and how l3vpn will >> >>perhaps provide a requirements doc for us, but also you guys have > done >> >> all >> >>the work so far and should share it. Regardless of what happens > going >> >>further. So unless Tom chimes in saying I'm high, we'll plan on Venu >> >>sharing your slides and Albert sharing his. I think we'll have > plenty of >> >>time and to be honest, its the most interesting thing we've got > going >> >>right now ;-) This work can continue even while waiting for >> requirements. >> >>But we really did start solving the problem before understanding > what >> the >> >>scale of the problem is. Thats what I'm trying to figure out. >> >> >> >>thanks, >> >>mike >> >> >> >>On Mon, 7 Mar 2005, suresh boddapati wrote: >> >> >> >>> Mike, >> >>> >> >>> I was under the impression that the presentation was gonna be only >> >>> between t >> >>he chairs like you suggested in your earlier email. If the slides > can be >> >> prese >> >>nted by someone else, Venu Hemige is there from Alcatel and he has > been >> >> partic >> >>ipating in the discussion as well from the beginning. He can present > my >> >> slides >> >>. Thanks. >> >>> >> >>> Suresh >> >>> >> >>> -----Original Message----- >> >>> From: pim-state-bounces@mountain2sea.com on behalf of Mike > McBride >> >>> Sent: Mon 3/7/2005 6:10 PM >> >>> To: Albert Tian >> >>> Cc: pim-state@mountain2sea.com >> >>> Subject: Re: [Pim-state] Summary >> >>> >> >>> >> >>> >> >>> Since you are here (and since Suresh and Dino are not) why don't > you >> >>> pl >> >>an >> >>> on taking a few minutes during the wg to discuss this. Tom or I > can >> >>> giv >> >>e >> >>> an update on the work and you (and perhaps Bob) can give the > details >> >>> of >> >>> the proposed solutions. I have Suresh's slides if you need them, >> they >> >>> a >> >>re >> >>> a good review. >> >>> >> >>> thanks, >> >>> mike >> >>> >> >>> On Mon, 7 Mar 2005, Albert Tian wrote: >> >>> >> >>> > Hi, >> >>> > >> >>> > Here are some slides regarding the points I raised. >> >>> > >> >>> > Thanks, >> >>> > >> >>> > Albert >> >>> > >> >>> > On Mon, 2005-03-07 at 15:07, Albert Tian wrote: >> >>> > > Hi Dino/Tom/Mike/Suresh, >> >>> > > >> >>> > > Here are a few issues that were not mentioned in the > summary: >> >>> > > >> >>> > > - One other problem for the TCP based solution is that for > MVPN, >> >>> ea >> >>ch of >> >>> > > the PIM peering between C-instances would require a seperate > TCP >> >>> > > connection. One could device a solution that introduces VPN >> >>> address >> >>> > > families for multicast so that the TCP connections can be >> shared, >> >>> b >> >>ut >> >>> > > that would require more change in the protocol. >> >>> > > >> >>> > > - Prune override no longer works (therefore join supression > does >> >>> no >> >>t >> >>> > > work either) , because there is no guarantee that the prune > from >> >>> on >> >>e >> >>> > > downstream neighbor is delivered to the other downstream >> >>> neighbor(s >> >>) >> >>> > > that need(s) to override it. There are several ways to fix > it, >> but >> >>the >> >>> > > simplest IMHO is to enable explicit tracking and disable > Join >> >>> > > suppression. For example U is the upstream and D1,D2 are two >> >>> downst >> >>ream >> >>> > > neighbors. Both D1 and D2 joined group G, not D1 send out a >> prune. >> >>It is >> >>> > > possible that the prune and ack for prune are delivered to > U, >> but >> >>> n >> >>ot >> >>> > > D2. U would prune the oif to D1/D2 while D2 is still in the >> Group. >> >>> > > >> >>> > > - Recovery from failed neighbor. All PIM entries learned > from >> that >> >>> > > neighbor must be removed. The upstream can either > immediately >> >>> remov >> >>e >> >>> > > them, or start the Expiry Timers with shorter durations and > let >> >>> the >> >>> > > timeout process handle it. >> >>> > > >> >>> > > - Recovery from one way communication failure. In this > scenario, >> >>> sa >> >>y two >> >>> > > neighbors X and Y, only X->Y direction is failing. Y will >> timeout >> >>> X >> >> and >> >>> > > delete all the PIM entries learned from X, without X knowing >> about >> >>it. >> >>> > > So there needs a way for Y to tell X that it has lost > neighbor >> X, >> >>> s >> >>o >> >>> > > that X can retransmit all its entries once the failure goes >> away. >> >>> O >> >>ne >> >>> > > solution (from Dino) is for Y to unicast a hello with GenId > 0 to >> X >> >>to >> >>> > > request a refresh. This hello likely needs an Ack of some > form. >> >>> > > >> >>> > > - A checksum based approach was mentioned, any progress over >> >>> there? >> >>> > > >> >>> > > >> >>> > > I can put these points in a few slides. >> >>> > > >> >>> > > I will attend this IETF (I wasn't sure if I can make it till >> >>> today) >> >>. >> >>> > > >> >>> > > As one of the co-authors of the JP Ack solution/draft, I > could >> >>> help >> >>> > > presentating the JP Ack approach, if needed. >> >>> > > >> >>> > > Thanks, >> >>> > > >> >>> > > Albert >> >>> > > >> >>> > > On Fri, 2005-02-25 at 14:29, Dino Farinacci wrote: >> >>> > > > >> Yes. This is a good idea. Is anyone willing to > summarize >> the >> >>> c >> >>urrent >> >>> > > > >> state of things (pun intended) with a few slides to the >> >>> workin >> >>g group? >> >>> > > > >> >>> > > > Since I won't be ablt to attend the IETF, I will brief >> some >> >>> o >> >>f the cisco >> >>> > > > guys. I think Mike (and you) were suppose to present > that. >> >>> > > > >> >>> > > > Dino >> >>> > > > _______________________________________________ >> >>> > > > Pim-state mailing list >> >>> > > > Pim-state@mountain2sea.com >> >>> > > > http://www.mountain2sea.com/mailman/listinfo/pim-state >> >>> > >> >>> _______________________________________________ >> >>> Pim-state mailing list >> >>> Pim-state@mountain2sea.com >> >>> http://www.mountain2sea.com/mailman/listinfo/pim-state >> >>> >> >>> >> >>> >> >>_______________________________________________ >> >>Pim-state mailing list >> >>Pim-state@mountain2sea.com >> >>http://www.mountain2sea.com/mailman/listinfo/pim-state >> > _______________________________________________ >> > Pim-state mailing list >> > Pim-state@mountain2sea.com >> > http://www.mountain2sea.com/mailman/listinfo/pim-state >> > > From rkebler@avici.com Tue Mar 8 23:51:01 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j294p1H9020090 for ; Tue, 8 Mar 2005 23:51:01 -0500 (EST) (envelope-from rkebler@avici.com) Received: from webmail.avici.com (mailhost.avici.com [127.0.0.1]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id j294or7k022919; Tue, 8 Mar 2005 23:50:53 -0500 Received: from 10.2.2.223 (SquirrelMail authenticated user rkebler) by webmail.avici.com with HTTP; Tue, 8 Mar 2005 23:50:53 -0500 (EST) Message-ID: <60256.10.2.2.223.1110343853.squirrel@webmail.avici.com> In-Reply-To: <200503090218.j292IPpK014175@dino-lnx.cisco.com> References: <20050308174627.7428.qmail@web81301.mail.yahoo.com> <200503090218.j292IPpK014175@dino-lnx.cisco.com> Date: Tue, 8 Mar 2005 23:50:53 -0500 (EST) Subject: Re: [Pim-state] consensus From: rkebler@avici.com To: "Dino Farinacci" User-Agent: SquirrelMail/1.4.0-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 04:51:02 -0000 Dino, I agree with your comments that it will be important to collapse changing S,G state in JP messages. In your example, if we resend J1-P4 for an entry, it could also lead to incorrect state. I'm confident that we can accomplish what you are looking for with a sequence number per JP message. I haven't yet written out that level of detail yet. I will try to do that as soon as possible, though. Regards, Bob >>> as a clone of the original JP packet. The rationale >>> being (correct me Dino if I am wrong) 1)Sending acks >>> is easy since just the PDU type needs to be changed, > > True. > >>> 2)The downstream routers get a second chance to see >>> the Joins in order to suppress their own Joins. > > True. > >>> Squeezing the sequence number into the reserved field >>> was an add on after our discussions, but again the >>> motive here was that the JP ACK PDU should be a clone >>> of JP PDU. Note that even with a TLV at the end, > > Right. > > The point about should the sequence number go per route versus per > message > in it's own right is not so important. My main concern is how > flow-control > will be done. And if you build a transmission layer below the PIM > topology > table, I'm worried about the additional buffering requirements in PIM. > > I've mentioned this before, but if you can suppress J-P-J-P-J events > and > able to guarantee that the last J was received by the upstream router, > then this is a good scaling benefit. So by adding sequence numbers to > each of the routes above, could allow you to suppress and reliably > deliver > the route state. > > Having said that, let's put sequence numbers on the above messages so > you > have J1-P2-J3-P4-J5. So if a transmitter sends J1 through J5 and only > gets > an ack for J5 back, it should be happy (and can remove any state or > timers > associated with wanting to retransmit J1-P4). > > You will get a damping effect of not oscillating the tree branch. This > is > a good thing. > > Dino > > > From sboddapa@yahoo.com Wed Mar 9 00:31:22 2005 Received: from web81308.mail.yahoo.com (web81308.mail.yahoo.com [206.190.37.83]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j295VMtt020169 for ; Wed, 9 Mar 2005 00:31:22 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050309053117.51483.qmail@web81308.mail.yahoo.com> Received: from [64.169.160.26] by web81308.mail.yahoo.com via HTTP; Tue, 08 Mar 2005 21:31:17 PST Date: Tue, 8 Mar 2005 21:31:17 -0800 (PST) From: Suresh Boddapati Subject: RE: [Pim-state] Summary To: rkebler@avici.com, suresh.boddapati@alcatel.com In-Reply-To: <60123.10.2.2.223.1110341038.squirrel@webmail.avici.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 05:31:22 -0000 Why? What am I missing here? I proposed something. We had a discussion. I modified my proposal to say that TLV will be used for ACK alone. I incorporated your suggestion for a 32 bit sequence number instead of Message ID and sequence number. Would that make it your proposal? Dino made a proposal. We suggested sequence numbers. He proposed using the reserved field for sequencing. Are you saying therefore it would not be Dino's scheme? Bob, I am not saying you have not contributed to the discussion, but if you are saying that my scheme is not mine, I dont get it. There were always two proposals that we discussed, Dino's and mine. There were suggestions made which were incorporated and of course, everybody's contribution will be aptly acknowledged when the final draft comes out. I hate to get into this kind of discussion, but if you want credit, I am not sure the right way is to take away credit from someone else. That certainly was not my intention when I put my name on the slide. Anyway, to put this to rest, I request the chairs to modify the slides to call the schemes Scheme A and Scheme B in the larger interest (in retrospect I wish I had done it in the first place, my apologies, I didnt expect this line of argument). I hope Dino has no objections. I hope this satisfies your concern, Bob. Peace. Suresh --- rkebler@avici.com wrote: > Right, I don't think it should be called 'Suresh's > scheme' in that > case. Also, the removal of the new refresh message > type was my > suggestion also. > > Regards, > Bob > > > Bob, > > I thought we had gone past that stage. Based on > the discussions on this > > list, and based on the consensus that there was > not much interest in > > having regular refreshes (even if they were > condensed), I had modified > > my scheme to remove the Refresh message (the email > titled Summary that I > > originated a while back says so) and have only the > TLV for ACK purposes. > > I originally had both message ID and sequence > number in it, but I think > > it was your suggestion to have only one 32 bit > number. That's the only > > change. The intention was to give an update on > where we are at, not > > where we started at and everything that was > discussed. It seems like you > > are saying that this scheme should not be called > "Suresh's scheme". Are > > you? > > > > Suresh > > > >> -----Original Message----- > >> From: rkebler@avici.com > [mailto:rkebler@avici.com] > >> Sent: Tuesday, March 08, 2005 4:11 PM > >> To: suresh boddapati > >> Cc: pim-state@mountain2sea.com > >> Subject: Re: [Pim-state] Summary > >> > >> Suresh, > >> Under "Suresh's scheme" in your slides, it does > not appear that you > >> describe the proposal that you sent to the list. > Your > >> proposal had a 32-bit message-id and a 32 > sequence number with > >> message-id being refreshed periodically in a new > "refresh > >> message". Was your intention to descibe this > under Suresh's > >> scheme? Or was your intention to describe using > only a 32-bit > >> id with the normal JP refresh procedures, and > calling this > >> "Suresh's scheme". > >> > >> Thanks, > >> Bob > >> > >> > >> > >> > >> > Mike, > >> > > >> > I'm fine with both Albert and Venu presenting. > >> > > >> > I also think that while we need to get more > input from l3vpn, we > > also > >> > have enough experience with PIM to know some of > the problems we > > faced > >> > with the periodic refresh so this effort is > needed regardless. > >> > > >> > Thanks, > >> > Tom > >> > > >> > In message > > > you > >> > write: > >> >>I haven't synced up with Tom yet but the more I > think about it, I > > think > >> >>Tom and I should still give the general > overview and how l3vpn will > >> >>perhaps provide a requirements doc for us, but > also you guys have > > done > >> >> all > >> >>the work so far and should share it. Regardless > of what happens > > going > >> >>further. So unless Tom chimes in saying I'm > high, we'll plan on Venu > >> >>sharing your slides and Albert sharing his. I > think we'll have > > plenty of > >> >>time and to be honest, its the most interesting > thing we've got > > going > >> >>right now ;-) This work can continue even while > waiting for > >> requirements. > >> >>But we really did start solving the problem > before understanding > > what > >> the > >> >>scale of the problem is. Thats what I'm trying > to figure out. > >> >> > >> >>thanks, > >> >>mike > >> >> > >> >>On Mon, 7 Mar 2005, suresh boddapati wrote: > >> >> > >> >>> Mike, > >> >>> > >> >>> I was under the impression that the > presentation was gonna be only > >> >>> between t > >> >>he chairs like you suggested in your earlier > email. If the slides > > can be > >> >> prese > >> >>nted by someone else, Venu Hemige is there from > Alcatel and he has > > been > >> >> partic > >> >>ipating in the discussion as well from the > beginning. He can present > > my > >> >> slides > >> >>. Thanks. > >> >>> > >> >>> Suresh > >> >>> > >> >>> -----Original Message----- > >> >>> From: pim-state-bounces@mountain2sea.com on > behalf of Mike > > McBride > >> >>> Sent: Mon 3/7/2005 6:10 PM > >> >>> To: Albert Tian > >> >>> Cc: pim-state@mountain2sea.com > >> >>> Subject: Re: [Pim-state] Summary > >> >>> > >> >>> > >> >>> > >> >>> Since you are here (and since Suresh and > Dino are not) why don't > > you > >> >>> pl > >> >>an > >> >>> on taking a few minutes during the wg to > discuss this. Tom or I > > can > >> >>> giv > >> >>e > >> >>> an update on the work and you (and perhaps > Bob) can give the > > details > >> >>> of > >> >>> the proposed solutions. I have Suresh's > slides if you need them, > >> they > >> >>> a > >> >>re > >> >>> a good review. > >> >>> > >> >>> thanks, > >> >>> mike > >> >>> > >> >>> On Mon, 7 Mar 2005, Albert Tian wrote: > >> >>> > >> >>> > Hi, > >> >>> > > >> >>> > Here are some slides regarding the points > I raised. > >> >>> > > >> >>> > Thanks, > >> >>> > > >> >>> > Albert > >> >>> > > >> >>> > On Mon, 2005-03-07 at 15:07, Albert Tian > wrote: > >> >>> > > Hi Dino/Tom/Mike/Suresh, > >> >>> > > > >> >>> > > Here are a few issues that were not > mentioned in the > > summary: > >> >>> > > > >> >>> > > - One other problem for the TCP based > solution is that for > > MVPN, > >> >>> ea > >> >>ch of > >> >>> > > the PIM peering between C-instances > would === message truncated === From sboddapa@yahoo.com Wed Mar 9 01:12:40 2005 Received: from web81302.mail.yahoo.com (web81302.mail.yahoo.com [206.190.37.77]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j296CelD020242 for ; Wed, 9 Mar 2005 01:12:40 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050309061235.42566.qmail@web81302.mail.yahoo.com> Received: from [64.169.160.26] by web81302.mail.yahoo.com via HTTP; Tue, 08 Mar 2005 22:12:35 PST Date: Tue, 8 Mar 2005 22:12:35 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] consensus To: Dino Farinacci In-Reply-To: <200503090218.j292IPpK014175@dino-lnx.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 06:12:40 -0000 > > Having said that, let's put sequence numbers on > the above messages so you > have J1-P2-J3-P4-J5. So if a transmitter sends > J1 through J5 and only gets > an ack for J5 back, it should be happy (and can > remove any state or timers > associated with wanting to retransmit J1-P4). > Yes. In fact, since it is the same message that will get modified (you will have to keep the original message for retransmission anyway), the number of outstanding messages awaiting ACK in this example will always be 1. Suresh From tian@redback.com Wed Mar 9 01:27:32 2005 Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j296RVvY020274 for ; Wed, 9 Mar 2005 01:27:31 -0500 (EST) (envelope-from tian@redback.com) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 293FEDA86DF; Tue, 8 Mar 2005 22:27:24 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10967-07; Tue, 8 Mar 2005 22:27:24 -0800 (PST) Received: from oslo.redback.com (oslo.redback.com [155.53.44.173]) by prattle.redback.com (Postfix) with ESMTP id E249DDA86DE; Tue, 8 Mar 2005 22:27:23 -0800 (PST) Subject: Re: [Pim-state] sequence number and retransmission From: Albert Tian To: Dino Farinacci In-Reply-To: <200503090218.j292IPpK014175@dino-lnx.cisco.com> References: <20050308174627.7428.qmail@web81301.mail.yahoo.com> <200503090218.j292IPpK014175@dino-lnx.cisco.com> Content-Type: text/plain Message-Id: <1110349643.9115.16041.camel@oslo.redback.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 08 Mar 2005 22:27:23 -0800 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 06:27:32 -0000 Hi Dino, Now we all agreed that there needs to be a sequence number. I think one sequence number per message is sufficient. However there are two ways to do the re-transmission and two ways to use the sequence numbers. A) use a mini reliable transmission layer inside PIM. Each message can be queued and retransmitted using a sliding-window protocol(or the like). B) use J/P timer as the retransmission timer, and in each PIM entry keep track of the sequence number of the last outbound PIM J/P message that contained that PIM entry. When the ack comes back, the PIM entry is marked as "Acked" only when the sequene number in the Ack message matches the sequence number in the PIM entry. As you correctly observed, option A) would churn the tree if the downstream J/P state is flapping. Option B) would not, but at the cost of maintaining the sequence number in each PIM entry, even though the sequence number is incremented on a per message basis. The seq number in PIM entry is needed since the downstream needs to know that (in you example) J5 is the final sequence number that it is expecting( therefore after receiving the ACk for J5, it is happy). I'm more leaning towards B) as it is simpler in terms of implementation. Thanks, Albert On Tue, 2005-03-08 at 18:18, Dino Farinacci wrote: > >> as a clone of the original JP packet. The rationale > >> being (correct me Dino if I am wrong) 1)Sending acks > >> is easy since just the PDU type needs to be changed, > > True. > > >> 2)The downstream routers get a second chance to see > >> the Joins in order to suppress their own Joins. > > True. > > >> Squeezing the sequence number into the reserved field > >> was an add on after our discussions, but again the > >> motive here was that the JP ACK PDU should be a clone > >> of JP PDU. Note that even with a TLV at the end, > > Right. > > The point about should the sequence number go per route versus per message > in it's own right is not so important. My main concern is how flow-control > will be done. And if you build a transmission layer below the PIM topology > table, I'm worried about the additional buffering requirements in PIM. > > I've mentioned this before, but if you can suppress J-P-J-P-J events and > able to guarantee that the last J was received by the upstream router, > then this is a good scaling benefit. So by adding sequence numbers to > each of the routes above, could allow you to suppress and reliably deliver > the route state. > > Having said that, let's put sequence numbers on the above messages so you > have J1-P2-J3-P4-J5. So if a transmitter sends J1 through J5 and only gets > an ack for J5 back, it should be happy (and can remove any state or timers > associated with wanting to retransmit J1-P4). > > You will get a damping effect of not oscillating the tree branch. This is > a good thing. > > Dino > > > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state From rkebler@avici.com Wed Mar 9 01:31:14 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j296VEti020294 for ; Wed, 9 Mar 2005 01:31:14 -0500 (EST) (envelope-from rkebler@avici.com) Received: from webmail.avici.com (mailhost.avici.com [127.0.0.1]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id j296V87k003050; Wed, 9 Mar 2005 01:31:09 -0500 Received: from 10.2.2.223 (SquirrelMail authenticated user rkebler) by webmail.avici.com with HTTP; Wed, 9 Mar 2005 01:31:09 -0500 (EST) Message-ID: <60608.10.2.2.223.1110349869.squirrel@webmail.avici.com> In-Reply-To: <20050309053117.51483.qmail@web81308.mail.yahoo.com> References: <60123.10.2.2.223.1110341038.squirrel@webmail.avici.com> <20050309053117.51483.qmail@web81308.mail.yahoo.com> Date: Wed, 9 Mar 2005 01:31:09 -0500 (EST) Subject: RE: [Pim-state] Summary From: rkebler@avici.com To: "Suresh Boddapati" User-Agent: SquirrelMail/1.4.0-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 06:31:14 -0000 I considered "Suresh's scheme" as the proposal that you sent out on the list and "Dino's scheme" as the proposal that he sent. I think we are now somewhere in between since ideas are converging. I don't need the slide to change. The slide isn't what is important. I'm more curious on what you feel you have ownership of. I'm including the writeup I did on Sunday night. I'm curious if you read this and consider this "Suresh's scheme/proposal". -Bob ------------------ A new Hello Option will indicate if a PIM router implements this draft. Reliable PIM JP messages will be unicast to the upstream router if the upstream router supports this draft. Otherwise the existing JP messages will be sent. The upstream routers that implement this draft will keep track of all downstream routers which have joined (explicit tracking) so there will be no Join Suppressions or Prune Overrides. The Reliable JP messages will be unicast because the other downstream routers will have no use of receiving these messages. To make the JP messages reliable, a 32-bit sequence number will be added to the JP messages. For this, we can create a new JP message type that has a 32 bit sequence number or we can encode the sequence number at the end of the existing JP message (Suresh's JP TLV idea). Upstream routers will send a new JP ACK message with the 32-bit sequence number that it is ACKing. Multiple sequence numbers can be included in the same message. Downstream routers will retransmit the JP message (with exponential backoff) until the message is ACKed. Although there will be no need for refreshes, the holdtime field will be maintained in the Reliable JP messages. If the holdtime is set to MAX_HOLDTIME (0xffff), then the entries will not be refreshed or timed out. If the holdtime is set to anything else, then the entries will be refreshed periodically and removed if the holdtime expires. Legacy PIM Routers can coexist with PIM routers implementing this draft. The JP messages that the legacy routers send and receive will be the same. The new Reliable JP messages are only sent by routers implementing this draft to routers that are sending the new hello option. Upstream nodes implementing this draft will be able to receive legacy JP messages and treat them as defined in the PIM base spec. The only difference will be when the legacy Join State time out, the outgoing interface will only be removed if there are no other (reliable) joiners on the interface. That is, the upstream routers can treat the collection of legacy downstream routers like one downstream router that is being explicitly tracked. > Why? What am I missing here? I proposed something. > We had a discussion. I modified my proposal to say > that TLV will be used for ACK alone. I incorporated > your suggestion for a 32 bit sequence number instead > of Message ID and sequence number. Would that make it > your proposal? > > Dino made a proposal. We suggested sequence numbers. > He proposed using the reserved field for sequencing. > Are you saying therefore it would not be Dino's > scheme? > > Bob, I am not saying you have not contributed to the > discussion, but if you are saying that my scheme is > not mine, I dont get it. There were always two > proposals that we discussed, Dino's and mine. There > were suggestions made which were incorporated and of > course, everybody's contribution will be aptly > acknowledged when the final draft comes out. I hate to > get into this kind of discussion, but if you want > credit, I am not sure the right way is to take away > credit from someone else. That certainly was not my > intention when I put my name on the slide. > > Anyway, to put this to rest, I request the chairs to > modify the slides to call the schemes Scheme A and > Scheme B in the larger interest (in retrospect I wish > I had done it in the first place, my apologies, I > didnt expect this line of argument). I hope Dino has > no objections. I hope this satisfies your concern, > Bob. > > Peace. > > Suresh > > --- rkebler@avici.com wrote: > >> Right, I don't think it should be called 'Suresh's >> scheme' in that >> case. Also, the removal of the new refresh message >> type was my >> suggestion also. >> >> Regards, >> Bob >> >> > Bob, >> > I thought we had gone past that stage. Based on >> the discussions on this >> > list, and based on the consensus that there was >> not much interest in >> > having regular refreshes (even if they were >> condensed), I had modified >> > my scheme to remove the Refresh message (the email >> titled Summary that I >> > originated a while back says so) and have only the >> TLV for ACK purposes. >> > I originally had both message ID and sequence >> number in it, but I think >> > it was your suggestion to have only one 32 bit >> number. That's the only >> > change. The intention was to give an update on >> where we are at, not >> > where we started at and everything that was >> discussed. It seems like you >> > are saying that this scheme should not be called >> "Suresh's scheme". Are >> > you? >> > >> > Suresh >> > >> >> -----Original Message----- >> >> From: rkebler@avici.com >> [mailto:rkebler@avici.com] >> >> Sent: Tuesday, March 08, 2005 4:11 PM >> >> To: suresh boddapati >> >> Cc: pim-state@mountain2sea.com >> >> Subject: Re: [Pim-state] Summary >> >> >> >> Suresh, >> >> Under "Suresh's scheme" in your slides, it does >> not appear that you >> >> describe the proposal that you sent to the list. >> Your >> >> proposal had a 32-bit message-id and a 32 >> sequence number with >> >> message-id being refreshed periodically in a new >> "refresh >> >> message". Was your intention to descibe this >> under Suresh's >> >> scheme? Or was your intention to describe using >> only a 32-bit >> >> id with the normal JP refresh procedures, and >> calling this >> >> "Suresh's scheme". >> >> >> >> Thanks, >> >> Bob >> >> >> >> >> >> >> >> >> >> > Mike, >> >> > >> >> > I'm fine with both Albert and Venu presenting. >> >> > >> >> > I also think that while we need to get more >> input from l3vpn, we >> > also >> >> > have enough experience with PIM to know some of >> the problems we >> > faced >> >> > with the periodic refresh so this effort is >> needed regardless. >> >> > >> >> > Thanks, >> >> > Tom >> >> > >> >> > In message >> > >> > you >> >> > write: >> >> >>I haven't synced up with Tom yet but the more I >> think about it, I >> > think >> >> >>Tom and I should still give the general >> overview and how l3vpn will >> >> >>perhaps provide a requirements doc for us, but >> also you guys have >> > done >> >> >> all >> >> >>the work so far and should share it. Regardless >> of what happens >> > going >> >> >>further. So unless Tom chimes in saying I'm >> high, we'll plan on Venu >> >> >>sharing your slides and Albert sharing his. I >> think we'll have >> > plenty of >> >> >>time and to be honest, its the most interesting >> thing we've got >> > going >> >> >>right now ;-) This work can continue even while >> waiting for >> >> requirements. >> >> >>But we really did start solving the problem >> before understanding >> > what >> >> the >> >> >>scale of the problem is. Thats what I'm trying >> to figure out. >> >> >> >> >> >>thanks, >> >> >>mike >> >> >> >> >> >>On Mon, 7 Mar 2005, suresh boddapati wrote: >> >> >> >> >> >>> Mike, >> >> >>> >> >> >>> I was under the impression that the >> presentation was gonna be only >> >> >>> between t >> >> >>he chairs like you suggested in your earlier >> email. If the slides >> > can be >> >> >> prese >> >> >>nted by someone else, Venu Hemige is there from >> Alcatel and he has >> > been >> >> >> partic >> >> >>ipating in the discussion as well from the >> beginning. He can present >> > my >> >> >> slides >> >> >>. Thanks. >> >> >>> >> >> >>> Suresh >> >> >>> >> >> >>> -----Original Message----- >> >> >>> From: pim-state-bounces@mountain2sea.com on >> behalf of Mike >> > McBride >> >> >>> Sent: Mon 3/7/2005 6:10 PM >> >> >>> To: Albert Tian >> >> >>> Cc: pim-state@mountain2sea.com >> >> >>> Subject: Re: [Pim-state] Summary >> >> >>> >> >> >>> >> >> >>> >> >> >>> Since you are here (and since Suresh and >> Dino are not) why don't >> > you >> >> >>> pl >> >> >>an >> >> >>> on taking a few minutes during the wg to >> discuss this. Tom or I >> > can >> >> >>> giv >> >> >>e >> >> >>> an update on the work and you (and perhaps >> Bob) can give the >> > details >> >> >>> of >> >> >>> the proposed solutions. I have Suresh's >> slides if you need them, >> >> they >> >> >>> a >> >> >>re >> >> >>> a good review. >> >> >>> >> >> >>> thanks, >> >> >>> mike >> >> >>> >> >> >>> On Mon, 7 Mar 2005, Albert Tian wrote: >> >> >>> >> >> >>> > Hi, >> >> >>> > >> >> >>> > Here are some slides regarding the points >> I raised. >> >> >>> > >> >> >>> > Thanks, >> >> >>> > >> >> >>> > Albert >> >> >>> > >> >> >>> > On Mon, 2005-03-07 at 15:07, Albert Tian >> wrote: >> >> >>> > > Hi Dino/Tom/Mike/Suresh, >> >> >>> > > >> >> >>> > > Here are a few issues that were not >> mentioned in the >> > summary: >> >> >>> > > >> >> >>> > > - One other problem for the TCP based >> solution is that for >> > MVPN, >> >> >>> ea >> >> >>ch of >> >> >>> > > the PIM peering between C-instances >> would > === message truncated === > From ycai@cypher.cisco.com Wed Mar 9 01:34:27 2005 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j296YQtK020305 for ; Wed, 9 Mar 2005 01:34:27 -0500 (EST) (envelope-from ycai@cypher.cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 08 Mar 2005 23:51:31 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,148,1107734400"; d="scan'208"; a="232942027:sNHT19743128" Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j296YJZV025147; Tue, 8 Mar 2005 22:34:19 -0800 (PST) Received: (from ycai@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA03384; Tue, 8 Mar 2005 22:34:18 -0800 (PST) Date: Tue, 8 Mar 2005 22:34:18 -0800 (PST) Message-Id: <200503090634.WAA03384@cisco.com> X-Authentication-Warning: cypher.cisco.com: ycai set sender to ycai@cypher.cisco.com using -f From: Yiqun Cai To: rkebler@avici.com In-reply-to: <60102.10.2.2.223.1110340597.squirrel@webmail.avici.com> (rkebler@avici.com) Subject: Re: [Pim-state] Reason for multicasting JP-Acks References: <200503080644.j286ipgr027258@dino-lnx.cisco.com> <57620.10.2.2.223.1110300038.squirrel@webmail.avici.com> <200503090211.j292BgZ6014026@dino-lnx.cisco.com> <60102.10.2.2.223.1110340597.squirrel@webmail.avici.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list Reply-To: ycai@cisco.com List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 06:34:27 -0000 Bob, What you are aruing for is really whether explicit tracking is mandatory. > Importance: Normal > > >>> Dino, I think we can get rid of Join Suppression all together with > >>> reliable ACKS. The downstream nodes will not suppress their Joins > >>> at all which means they do not need to even process the message, > > > > On a multi-access network, where state is already created in an > > upstream > > router, and a downstream router gets a triggered Join from onen of > > it's > > downstream routers for the same state, wouldn't it be good to not have > > to send the Join? > > > > "Triggered Join Suppression" is one of the mechanisms to get the > > protocol > > to scale better. That is why I think we should continue to *want* Join > > suppression in the proposal. We are not talking about "Periodic Join > > Suppression" because periodic JPs will go away but "Triggered Join > > Suppression". > > > > Dino > > > > I think you have limited benefits of Join Suppression if the Joins > are reliable. One scenario that causes problems would be if a > Join is suppressed by downstream node A because it receives a > Join from downstream node B. If B sends a prune, then A must > override the prune with a Join. Now, what if this prune does > not reach A. Then A will not override and this interface > will be removed from the upstream router. There will not be > periodic Joins (or the refreshes will be few and far between) > to cleanup this state. > > I think it is nice to get rid of Join Suppression all together. > It is nice that other downstream nodes don't even have to receive > these messages and then they can be unicast. > > Regards, > Bob > > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state > -- Yiqun From dino@dino-lnx.cisco.com Wed Mar 9 01:39:35 2005 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j296dYwv020322 for ; Wed, 9 Mar 2005 01:39:34 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 08 Mar 2005 22:39:34 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,148,1107763200"; d="scan'208"; a="165989976:sNHT17423508" Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j296dPTM027506; Tue, 8 Mar 2005 22:39:27 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j296dOgn009741; Tue, 8 Mar 2005 22:39:24 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j296dOlQ009732; Tue, 8 Mar 2005 22:39:24 -0800 Date: Tue, 8 Mar 2005 22:39:24 -0800 Message-Id: <200503090639.j296dOlQ009732@dino-lnx.cisco.com> From: Dino Farinacci To: rkebler@avici.com In-reply-to: <60256.10.2.2.223.1110343853.squirrel@webmail.avici.com> (rkebler@avici.com) Subject: Re: [Pim-state] consensus References: <20050308174627.7428.qmail@web81301.mail.yahoo.com> <200503090218.j292IPpK014175@dino-lnx.cisco.com> <60256.10.2.2.223.1110343853.squirrel@webmail.avici.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 06:39:35 -0000 >> I agree with your comments that it will be important to >> collapse changing S,G state in JP messages. In your example, >> if we resend J1-P4 for an entry, it could also lead to Well it shouldn't because J5 is more current than J1-P4. So if a retransmission came out of order (VPN case), the sequence number should correct it. Dino From tian@redback.com Wed Mar 9 01:40:51 2005 Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j296eo0m020339 for ; Wed, 9 Mar 2005 01:40:50 -0500 (EST) (envelope-from tian@redback.com) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 45F93DA86DD; Tue, 8 Mar 2005 22:40:44 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12535-07; Tue, 8 Mar 2005 22:40:43 -0800 (PST) Received: from oslo.redback.com (oslo.redback.com [155.53.44.173]) by prattle.redback.com (Postfix) with ESMTP id 58AB4DA86DC; Tue, 8 Mar 2005 22:40:38 -0800 (PST) Subject: Re: [Pim-state] consensus From: Albert Tian To: Suresh Boddapati In-Reply-To: <20050309061235.42566.qmail@web81302.mail.yahoo.com> References: <20050309061235.42566.qmail@web81302.mail.yahoo.com> Content-Type: text/plain Message-Id: <1110350438.5157.16173.camel@oslo.redback.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 08 Mar 2005 22:40:38 -0800 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 06:40:51 -0000 Hi Suresh, On Tue, 2005-03-08 at 22:12, Suresh Boddapati wrote: > > > > Having said that, let's put sequence numbers on > > the above messages so you > > have J1-P2-J3-P4-J5. So if a transmitter sends > > J1 through J5 and only gets > > an ack for J5 back, it should be happy (and can > > remove any state or timers > > associated with wanting to retransmit J1-P4). > > > Yes. In fact, since it is the same message that will > get modified (you will have to keep the original > message for retransmission anyway), the number of > outstanding messages awaiting ACK in this example will > always be 1. In the retransmission option B) I mentioned in my previous mail, you don't have to keep the original message for retransmission. In fact you will not be able achieve what Dino has mentioned (basically only wait for the ack of the last state J5 and move on) if you retransmit the original messages, because there could be many groups in the same message. Thanks, Albert Thanks, Albert > > Suresh > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state From dino@dino-lnx.cisco.com Wed Mar 9 01:41:14 2005 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j296fEEF020350 for ; Wed, 9 Mar 2005 01:41:14 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2005 22:41:37 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j296f7YO015017; Tue, 8 Mar 2005 22:41:07 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j296f6wQ011493; Tue, 8 Mar 2005 22:41:06 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j296f6MN011489; Tue, 8 Mar 2005 22:41:06 -0800 Date: Tue, 8 Mar 2005 22:41:06 -0800 Message-Id: <200503090641.j296f6MN011489@dino-lnx.cisco.com> From: Dino Farinacci To: sboddapa@yahoo.com In-reply-to: <20050309061235.42566.qmail@web81302.mail.yahoo.com> (message from Suresh Boddapati on Tue, 8 Mar 2005 22:12:35 -0800 (PST)) Subject: Re: [Pim-state] consensus References: <20050309061235.42566.qmail@web81302.mail.yahoo.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 06:41:15 -0000 >> Yes. In fact, since it is the same message that will >> get modified (you will have to keep the original >> message for retransmission anyway), the number of >> outstanding messages awaiting ACK in this example will >> always be 1. But you have to go find J1-P4 in the queued messages and if they are different messages you have a gathering issue. I can understand if you want to put sequence number of messages, but changing the message with different contents depending on future events sounds dubious to me. Dino From dino@dino-lnx.cisco.com Wed Mar 9 01:46:11 2005 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j296kAd1020367 for ; Wed, 9 Mar 2005 01:46:10 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 08 Mar 2005 22:46:10 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,148,1107763200"; d="scan'208"; a="165990633:sNHT19930820" Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j296k0TM029596; Tue, 8 Mar 2005 22:46:00 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j296k0WM011600; Tue, 8 Mar 2005 22:46:00 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j296k0nH011596; Tue, 8 Mar 2005 22:46:00 -0800 Date: Tue, 8 Mar 2005 22:46:00 -0800 Message-Id: <200503090646.j296k0nH011596@dino-lnx.cisco.com> From: Dino Farinacci To: tian@redback.com In-reply-to: <1110349643.9115.16041.camel@oslo.redback.com> (message from Albert Tian on Tue, 08 Mar 2005 22:27:23 -0800) Subject: Re: [Pim-state] sequence number and retransmission References: <20050308174627.7428.qmail@web81301.mail.yahoo.com> <200503090218.j292IPpK014175@dino-lnx.cisco.com> <1110349643.9115.16041.camel@oslo.redback.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 06:46:11 -0000 >> I think one sequence number per message is sufficient. However there are >> two ways to do the re-transmission and two ways to use the sequence >> numbers. I believe you cannot implement what I want to achieve with message sequence numbers. Because you can't suppress older messages, especially if there is other state in there that should not be suppressed. And I think it is very dangerous (and misleading) to modify a message with a sequence number once it has been built. >> A) use a mini reliable transmission layer inside PIM. Each message can >> be queued and retransmitted using a sliding-window protocol(or the >> like). This is what I want to avoid. >> B) use J/P timer as the retransmission timer, and in each PIM entry keep >> track of the sequence number of the last outbound PIM J/P message that >> contained that PIM entry. When the ack comes back, the PIM entry is >> marked as "Acked" only when the sequene number in the Ack message >> matches the sequence number in the PIM entry. Right. >> I'm more leaning towards B) as it is simpler in terms of implementation. And think what it brings in terms of better scalability to the network. Dino From dino@dino-lnx.cisco.com Wed Mar 9 01:51:15 2005 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j296pF6g020384 for ; Wed, 9 Mar 2005 01:51:15 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2005 22:51:38 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j296p8TM000599; Tue, 8 Mar 2005 22:51:08 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j296p8oB014369; Tue, 8 Mar 2005 22:51:08 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j296p8Tt014365; Tue, 8 Mar 2005 22:51:08 -0800 Date: Tue, 8 Mar 2005 22:51:08 -0800 Message-Id: <200503090651.j296p8Tt014365@dino-lnx.cisco.com> From: Dino Farinacci To: rkebler@avici.com In-reply-to: <60102.10.2.2.223.1110340597.squirrel@webmail.avici.com> (rkebler@avici.com) Subject: Re: [Pim-state] Reason for multicasting JP-Acks References: <200503080644.j286ipgr027258@dino-lnx.cisco.com> <57620.10.2.2.223.1110300038.squirrel@webmail.avici.com> <200503090211.j292BgZ6014026@dino-lnx.cisco.com> <60102.10.2.2.223.1110340597.squirrel@webmail.avici.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 06:51:16 -0000 >> I think it is nice to get rid of Join Suppression all together. >> It is nice that other downstream nodes don't even have to receive >> these messages and then they can be unicast. Well if we require ET then Join Suppression cannot be done. Dino From sboddapa@yahoo.com Wed Mar 9 02:01:09 2005 Received: from web81305.mail.yahoo.com (web81305.mail.yahoo.com [206.190.37.80]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j29718Ln020421 for ; Wed, 9 Mar 2005 02:01:08 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050309070103.37623.qmail@web81305.mail.yahoo.com> Received: from [64.169.160.26] by web81305.mail.yahoo.com via HTTP; Tue, 08 Mar 2005 23:01:03 PST Date: Tue, 8 Mar 2005 23:01:03 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] sequence number and retransmission To: Albert Tian , Dino Farinacci In-Reply-To: <1110349643.9115.16041.camel@oslo.redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 07:01:09 -0000 > I think one sequence number per message is > sufficient. However there are > two ways to do the re-transmission and two ways to > use the sequence > numbers. > > A) use a mini reliable transmission layer inside > PIM. Each message can > be queued and retransmitted using a sliding-window > protocol(or the > like). > We really dont need a sliding window here, but it's upto the implementation if it wants to have no more than n messages on the rtx queue. > B) use J/P timer as the retransmission timer, and in > each PIM entry keep > track of the sequence number of the last outbound > PIM J/P message that > contained that PIM entry. When the ack comes back, > the PIM entry is > marked as "Acked" only when the sequene number in > the Ack message > matches the sequence number in the PIM entry. > > As you correctly observed, option A) would churn the > tree if the > downstream J/P state is flapping. > > Option B) would not, but at the cost of maintaining > the sequence number > in each PIM entry, even though the sequence number > is incremented on a > per message basis. The seq number in PIM entry is > needed since the > downstream needs to know that (in you example) J5 is > the final sequence > number that it is expecting( therefore after > receiving the ACk for J5, > it is happy). Albert, you would get the churn even with option B, wouldnt you? If (S1,G1) and (S2,G2) both had seq=1 and the message was sent, if (S1,G1) is pruned, the seq for (S1,G1) will be 2, (S2,G2) will be 1. Now if (S1,G1) Joins, (S1,G1) seq will be 3, (S2, G2) will be 1. Even if you got the ack back for the final state now, you still have sent the Join, Prune, Join combo for (S1,G1) causing a churn, havent you? Am I missing something? IMO, damping can be achieved only if you damp before scheduling for transmission. Once you sent it out, you have no control. > > I'm more leaning towards B) as it is simpler in > terms of implementation. > I see how it will be easy to extend (in terms of implementation) if every entry had a sequence number. But in terms of traffic on the wire, it will actually double, because the ACK will have to contain the entire JP PDU again. I think this is unnecessary and does not buy much. Yes, it is a little bit more code to associate a state with a message on the rtx queue, but not too much. Either a state is on the queue or not. If not, you add it to the queue in a new JP message. If it is already on the queue, we know which message it belongs to. The JP message would have to keep a list of states so that once the ACK comes back, all the states can be considered acked. The rtx timer also needs to run per Message. The (re)transmission stays separate from the state and its changes. If the protocol becomes more efficient, it is probably worth the extra code. BTW, we cannot use JP timer as a retransmission timer since we plan to make the JP timer much larger in order to reduce refreshes. We want the rtx timer much smaller with exponential backoff so that missed JP packets are detected faster. > Thanks, > > Albert > > > On Tue, 2005-03-08 at 18:18, Dino Farinacci wrote: > > >> as a clone of the original JP packet. The > rationale > > >> being (correct me Dino if I am wrong) 1)Sending > acks > > >> is easy since just the PDU type needs to be > changed, > > > > True. > > > > >> 2)The downstream routers get a second chance to > see > > >> the Joins in order to suppress their own Joins. > > > > True. > > > > >> Squeezing the sequence number into the reserved > field > > >> was an add on after our discussions, but again > the > > >> motive here was that the JP ACK PDU should be a > clone > > >> of JP PDU. Note that even with a TLV at the > end, > > > > Right. > > > > The point about should the sequence number go > per route versus per message > > in it's own right is not so important. My main > concern is how flow-control > > will be done. And if you build a transmission > layer below the PIM topology > > table, I'm worried about the additional > buffering requirements in PIM. > > > > I've mentioned this before, but if you can > suppress J-P-J-P-J events and > > able to guarantee that the last J was received > by the upstream router, > > then this is a good scaling benefit. So by > adding sequence numbers to > > each of the routes above, could allow you to > suppress and reliably deliver > > the route state. > > > > Having said that, let's put sequence numbers > on the above messages so you > > have J1-P2-J3-P4-J5. So if a transmitter sends > J1 through J5 and only gets > > an ack for J5 back, it should be happy (and > can remove any state or timers > > associated with wanting to retransmit J1-P4). > > > > You will get a damping effect of not > oscillating the tree branch. This is > > a good thing. > > > > Dino > > > > > > _______________________________________________ > > Pim-state mailing list > > Pim-state@mountain2sea.com > > > http://www.mountain2sea.com/mailman/listinfo/pim-state > > From tian@redback.com Wed Mar 9 02:07:17 2005 Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j2977Hf3020438 for ; Wed, 9 Mar 2005 02:07:17 -0500 (EST) (envelope-from tian@redback.com) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id DF8A4203131; Tue, 8 Mar 2005 23:07:11 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08350-10; Tue, 8 Mar 2005 23:07:11 -0800 (PST) Received: from oslo.redback.com (oslo.redback.com [155.53.44.173]) by prattle.redback.com (Postfix) with ESMTP id 9702D203130; Tue, 8 Mar 2005 23:07:11 -0800 (PST) Subject: Re: [Pim-state] sequence number and retransmission From: Albert Tian To: Dino Farinacci In-Reply-To: <200503090646.j296k0nH011596@dino-lnx.cisco.com> References: <20050308174627.7428.qmail@web81301.mail.yahoo.com> <200503090218.j292IPpK014175@dino-lnx.cisco.com> <1110349643.9115.16041.camel@oslo.redback.com> <200503090646.j296k0nH011596@dino-lnx.cisco.com> Content-Type: text/plain Message-Id: <1110352031.5161.16415.camel@oslo.redback.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 08 Mar 2005 23:07:11 -0800 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 07:07:17 -0000 Hi Dino, On Tue, 2005-03-08 at 22:46, Dino Farinacci wrote: > >> I think one sequence number per message is sufficient. However there are > >> two ways to do the re-transmission and two ways to use the sequence > >> numbers. > > I believe you cannot implement what I want to achieve with message > sequence numbers. Because you can't suppress older messages, especially > if there is other state in there that should not be suppressed. And I > think it is very dangerous (and misleading) to modify a message with > a sequence number once it has been built. Here is what I'm thinking to achieve the per message sequence number -- you could think of it as per PIM entry sequene number in a special way: all PIM entries in the same message get the same new sequence number, so you only need to inlcude one copy in the message. Albert > > >> A) use a mini reliable transmission layer inside PIM. Each message can > >> be queued and retransmitted using a sliding-window protocol(or the > >> like). > > This is what I want to avoid. > > >> B) use J/P timer as the retransmission timer, and in each PIM entry keep > >> track of the sequence number of the last outbound PIM J/P message that > >> contained that PIM entry. When the ack comes back, the PIM entry is > >> marked as "Acked" only when the sequene number in the Ack message > >> matches the sequence number in the PIM entry. > > Right. > > >> I'm more leaning towards B) as it is simpler in terms of implementation. > > And think what it brings in terms of better scalability to the network. > > Dino > From sboddapa@yahoo.com Wed Mar 9 02:11:59 2005 Received: from web81305.mail.yahoo.com (web81305.mail.yahoo.com [206.190.37.80]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j297Bxp7020455 for ; Wed, 9 Mar 2005 02:11:59 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050309071153.39172.qmail@web81305.mail.yahoo.com> Received: from [64.169.160.26] by web81305.mail.yahoo.com via HTTP; Tue, 08 Mar 2005 23:11:53 PST Date: Tue, 8 Mar 2005 23:11:53 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] consensus To: Dino Farinacci In-Reply-To: <200503090641.j296f6MN011489@dino-lnx.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 07:11:59 -0000 --- Dino Farinacci wrote: > >> Yes. In fact, since it is the same message that > will > >> get modified (you will have to keep the original > >> message for retransmission anyway), the number of > >> outstanding messages awaiting ACK in this example > will > >> always be 1. > > But you have to go find J1-P4 in the queued > messages and if they are > different messages you have a gathering issue. > Only if you allow a state to be in multiple messages at the same time. When you put a state in a message, if you remember which message it is in and per message if you remember which states it holds, there is no fetching, isnt it? Just pointer manipulation, rebuild the PDU with all its states (some of which are the modified ones), up the sequence number and send it out. If you get an ack back with a sequence number which does not match any on your rtx queue, you ignore it. > I can understand if you want to put sequence > number of messages, but > changing the message with different contents > depending on future events > sounds dubious to me. > I am not sure I understand. I am saying the message sequence number will change based on a current event that affects any state in the message, not any future event. Suresh From dino@dino-lnx.cisco.com Wed Mar 9 02:12:11 2005 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j297CAZH020466 for ; Wed, 9 Mar 2005 02:12:10 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2005 23:12:34 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j297C3YO020304; Tue, 8 Mar 2005 23:12:03 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j297C2gg029862; Tue, 8 Mar 2005 23:12:02 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j297C2so029858; Tue, 8 Mar 2005 23:12:02 -0800 Date: Tue, 8 Mar 2005 23:12:02 -0800 Message-Id: <200503090712.j297C2so029858@dino-lnx.cisco.com> From: Dino Farinacci To: tian@redback.com In-reply-to: <1110352031.5161.16415.camel@oslo.redback.com> (message from Albert Tian on Tue, 08 Mar 2005 23:07:11 -0800) Subject: Re: [Pim-state] sequence number and retransmission References: <20050308174627.7428.qmail@web81301.mail.yahoo.com> <200503090218.j292IPpK014175@dino-lnx.cisco.com> <1110349643.9115.16041.camel@oslo.redback.com> <200503090646.j296k0nH011596@dino-lnx.cisco.com> <1110352031.5161.16415.camel@oslo.redback.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 07:12:11 -0000 >> Here is what I'm thinking to achieve the per message sequence number -- >> you could think of it as per PIM entry sequene number in a special way: >> all PIM entries in the same message get the same new sequence number, so >> you only need to inlcude one copy in the message. I figrued that is the way it would be, but what if you want to suppress some state in that message because a new mesasge is about to be transmitted with newer state. But the previous message has other state in it that needs to be sent? Do you modify the previous message? Dino From dino@dino-lnx.cisco.com Wed Mar 9 02:15:40 2005 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j297FUeJ020483 for ; Wed, 9 Mar 2005 02:15:40 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 08 Mar 2005 23:15:31 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,149,1107763200"; d="scan'208"; a="165993046:sNHT18058520" Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j297FMTM004589; Tue, 8 Mar 2005 23:15:23 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j297FMgP029965; Tue, 8 Mar 2005 23:15:22 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j297FMQQ029961; Tue, 8 Mar 2005 23:15:22 -0800 Date: Tue, 8 Mar 2005 23:15:22 -0800 Message-Id: <200503090715.j297FMQQ029961@dino-lnx.cisco.com> From: Dino Farinacci To: sboddapa@yahoo.com In-reply-to: <20050309071153.39172.qmail@web81305.mail.yahoo.com> (message from Suresh Boddapati on Tue, 8 Mar 2005 23:11:53 -0800 (PST)) Subject: Re: [Pim-state] consensus References: <20050309071153.39172.qmail@web81305.mail.yahoo.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 07:15:40 -0000 >> Only if you allow a state to be in multiple messages >> at the same time. When you put a state in a message, >> if you remember which message it is in and per message That is no different than having per state sequence numbers. So where's the benefit? >> fetching, isnt it? Just pointer manipulation, rebuild >> the PDU with all its states (some of which are the >> modified ones), up the sequence number and send it >> out. If you get an ack back with a sequence number >> which does not match any on your rtx queue, you ignore >> it. I'm sorry that can't work. What if you multicast the JP and some routers get it and others don't, then the retransmitted one has different information in it? That will be a nightmare to debug and get right. KISS principle. You are trying to be too clever. ;-) Dino From dino@dino-lnx.cisco.com Wed Mar 9 02:18:25 2005 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j297IPRi020494 for ; Wed, 9 Mar 2005 02:18:25 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 08 Mar 2005 23:18:26 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,149,1107763200"; d="scan'208"; a="165993338:sNHT18829380" Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j297IHYO021849; Tue, 8 Mar 2005 23:18:18 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j297IHOK030070; Tue, 8 Mar 2005 23:18:17 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j297IHhn030066; Tue, 8 Mar 2005 23:18:17 -0800 Date: Tue, 8 Mar 2005 23:18:17 -0800 Message-Id: <200503090718.j297IHhn030066@dino-lnx.cisco.com> From: Dino Farinacci To: sboddapa@yahoo.com In-reply-to: <20050309070103.37623.qmail@web81305.mail.yahoo.com> (message from Suresh Boddapati on Tue, 8 Mar 2005 23:01:03 -0800 (PST)) Subject: Re: [Pim-state] sequence number and retransmission References: <20050309070103.37623.qmail@web81305.mail.yahoo.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 07:18:25 -0000 >> I see how it will be easy to extend (in terms of >> implementation) if every entry had a sequence number. >> But in terms of traffic on the wire, it will actually >> double, because the ACK will have to contain the >> entire JP PDU again. I think this is unnecessary and So what? It's only when JPs are sent. It's not periodic. >> the extra code. BTW, we cannot use JP timer as a >> retransmission timer since we plan to make the JP >> timer much larger in order to reduce refreshes. We >> want the rtx timer much smaller with exponential >> backoff so that missed JP packets are detected faster. Let the implementation choose to do it the way they see fit. Dino From tian@redback.com Wed Mar 9 02:22:36 2005 Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j297MaDH020511 for ; Wed, 9 Mar 2005 02:22:36 -0500 (EST) (envelope-from tian@redback.com) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id EA027203130; Tue, 8 Mar 2005 23:22:30 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10794-03; Tue, 8 Mar 2005 23:22:30 -0800 (PST) Received: from oslo.redback.com (oslo.redback.com [155.53.44.173]) by prattle.redback.com (Postfix) with ESMTP id 99D1C203135; Tue, 8 Mar 2005 23:22:29 -0800 (PST) Subject: Re: [Pim-state] sequence number and retransmission From: Albert Tian To: Dino Farinacci In-Reply-To: <200503090712.j297C2so029858@dino-lnx.cisco.com> References: <20050308174627.7428.qmail@web81301.mail.yahoo.com> <200503090218.j292IPpK014175@dino-lnx.cisco.com> <1110349643.9115.16041.camel@oslo.redback.com> <200503090646.j296k0nH011596@dino-lnx.cisco.com> <1110352031.5161.16415.camel@oslo.redback.com> <200503090712.j297C2so029858@dino-lnx.cisco.com> Content-Type: text/plain Message-Id: <1110352949.5157.16558.camel@oslo.redback.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 08 Mar 2005 23:22:29 -0800 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 07:22:36 -0000 On Tue, 2005-03-08 at 23:12, Dino Farinacci wrote: > >> Here is what I'm thinking to achieve the per message sequence number -- > >> you could think of it as per PIM entry sequene number in a special way: > >> all PIM entries in the same message get the same new sequence number, so > >> you only need to inlcude one copy in the message. > > I figrued that is the way it would be, but what if you want to suppress > some state in that message because a new mesasge is about to be > transmitted with newer state. But the previous message has other state > in it that needs to be sent? Do you modify the previous message? suppress old messages would be hard to do when there are other states in the same message, the benefit is probabaly not worth the effort. Thanks, Albert > > Dino From sboddapa@yahoo.com Wed Mar 9 02:24:18 2005 Received: from web81305.mail.yahoo.com (web81305.mail.yahoo.com [206.190.37.80]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j297OIa5020524 for ; Wed, 9 Mar 2005 02:24:18 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050309072412.40467.qmail@web81305.mail.yahoo.com> Received: from [64.169.160.26] by web81305.mail.yahoo.com via HTTP; Tue, 08 Mar 2005 23:24:12 PST Date: Tue, 8 Mar 2005 23:24:12 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] consensus To: Dino Farinacci In-Reply-To: <200503090715.j297FMQQ029961@dino-lnx.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 07:24:18 -0000 --- Dino Farinacci wrote: > >> Only if you allow a state to be in multiple > messages > >> at the same time. When you put a state in a > message, > >> if you remember which message it is in and per > message > > That is no different than having per state > sequence numbers. So where's > the benefit? > The benefit is that the ACK needs to have only the sequence number, not every state and its associated sequence number. The benefit is also that the receiver of the ACK does not have to go through the entire message to figure out if every state is ACKed or not. Get the ack, match the sequence number on the rtx list, consider all entries acked. Done. > >> fetching, isnt it? Just pointer manipulation, > rebuild > >> the PDU with all its states (some of which are > the > >> modified ones), up the sequence number and send > it > >> out. If you get an ack back with a sequence > number > >> which does not match any on your rtx queue, you > ignore > >> it. > > I'm sorry that can't work. What if you multicast > the JP and some routers > get it and others don't, then the retransmitted > one has different > information in it? That will be a nightmare to > debug and get right. > The problem of some routers getting some JPs and some not can happen today also. As long as the latest state is what is being sent and retransmitted on the wire always, it is no different from what happens today. What additional problems do you think this will cause? > KISS principle. You are trying to be too clever. > ;-) > Come on, it's just C :-) Suresh From rkebler@avici.com Wed Mar 9 11:56:23 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j29GuNHu021682 for ; Wed, 9 Mar 2005 11:56:23 -0500 (EST) (envelope-from rkebler@avici.com) Received: from webmail.avici.com (mailhost.avici.com [127.0.0.1]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id j29GuH7k022453; Wed, 9 Mar 2005 11:56:17 -0500 Received: from 10.2.2.223 (SquirrelMail authenticated user rkebler) by webmail.avici.com with HTTP; Wed, 9 Mar 2005 11:56:17 -0500 (EST) Message-ID: <34434.10.2.2.223.1110387377.squirrel@webmail.avici.com> In-Reply-To: <1110352031.5161.16415.camel@oslo.redback.com> References: <20050308174627.7428.qmail@web81301.mail.yahoo.com><200503090218.j292I PpK014175@dino-lnx.cisco.com><1110349643.9115.16041.camel@oslo.redback .com><200503090646.j296k0nH011596@dino-lnx.cisco.com> <1110352031.5161.16415.camel@oslo.redback.com> Date: Wed, 9 Mar 2005 11:56:17 -0500 (EST) Subject: Re: [Pim-state] sequence number and retransmission From: rkebler@avici.com To: "Albert Tian" User-Agent: SquirrelMail/1.4.0-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 16:56:23 -0000 Albert, I think the sequence numbers will be kept per neighbor, so that if we want to find the next sequence number, we will see what the last one was that we sent for that nbr. There is one added complication that I see with this method. An entry can be on more than one neighbor's retran list (if the entry had an iif change). In this case, the entry will be holding a list of sequence numbers. -Bob > Hi Dino, > > On Tue, 2005-03-08 at 22:46, Dino Farinacci wrote: >> >> I think one sequence number per message is sufficient. However there >> are >> >> two ways to do the re-transmission and two ways to use the sequence >> >> numbers. >> >> I believe you cannot implement what I want to achieve with message >> sequence numbers. Because you can't suppress older messages, >> especially >> if there is other state in there that should not be suppressed. And >> I >> think it is very dangerous (and misleading) to modify a message with >> a sequence number once it has been built. > > Here is what I'm thinking to achieve the per message sequence number -- > you could think of it as per PIM entry sequene number in a special way: > all PIM entries in the same message get the same new sequence number, so > you only need to inlcude one copy in the message. > > Albert > >> >> >> A) use a mini reliable transmission layer inside PIM. Each message >> can >> >> be queued and retransmitted using a sliding-window protocol(or the >> >> like). >> >> This is what I want to avoid. >> >> >> B) use J/P timer as the retransmission timer, and in each PIM entry >> keep >> >> track of the sequence number of the last outbound PIM J/P message >> that >> >> contained that PIM entry. When the ack comes back, the PIM entry is >> >> marked as "Acked" only when the sequene number in the Ack message >> >> matches the sequence number in the PIM entry. >> >> Right. >> >> >> I'm more leaning towards B) as it is simpler in terms of >> implementation. >> >> And think what it brings in terms of better scalability to the >> network. >> >> Dino >> > > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state > From dino@dino-lnx.cisco.com Wed Mar 9 13:58:09 2005 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j29Iw8FS021882 for ; Wed, 9 Mar 2005 13:58:09 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 09 Mar 2005 10:58:27 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j29IvjYO020244; Wed, 9 Mar 2005 10:57:46 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j29IvjtG013579; Wed, 9 Mar 2005 10:57:45 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j29IvjIQ013575; Wed, 9 Mar 2005 10:57:45 -0800 Date: Wed, 9 Mar 2005 10:57:45 -0800 Message-Id: <200503091857.j29IvjIQ013575@dino-lnx.cisco.com> From: Dino Farinacci To: sboddapa@yahoo.com In-reply-to: <20050309072412.40467.qmail@web81305.mail.yahoo.com> (message from Suresh Boddapati on Tue, 8 Mar 2005 23:24:12 -0800 (PST)) Subject: Re: [Pim-state] consensus References: <20050309072412.40467.qmail@web81305.mail.yahoo.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 18:58:09 -0000 >> sequence number. The benefit is also that the receiver >> of the ACK does not have to go through the entire >> message to figure out if every state is ACKed or not. There is not much of a problem here. In this incremental mode most JPs will be triggered and won't be large, modulo initialization sequences. So we actually reduced CPU time processing large periodic messages. I already mentioned the disadvantages, which I think outweight the benefits. >> The problem of some routers getting some JPs and some >> not can happen today also. As long as the latest state The JPs themself have no sequencing or retransmission logic. If you get a periodic JP today you don't know or care if it's a duplicate. With a reliable scheme with sequence numbers you have to sequence out of order messages and do duplicate detection (if multicasted). >> > KISS principle. You are trying to be too clever. >> > ;-) >> > >> Come on, it's just C :-) You have missed the point. We are not talking about the language which implements the algorithm, we are talking about algorithms people will have to use, manage, and debug. The issue for the implementor is only the tip of the iceberg, should be considered, but there are many more aspects that deserve consideration too. Dino From dino@dino-lnx.cisco.com Wed Mar 9 14:00:17 2005 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j29J0Hgw021908 for ; Wed, 9 Mar 2005 14:00:17 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 09 Mar 2005 10:59:47 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,151,1107763200"; d="scan'208"; a="166164622:sNHT17763952" Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j29IxBYO020670; Wed, 9 Mar 2005 10:59:11 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j29IxBP2013642; Wed, 9 Mar 2005 10:59:11 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j29IxBq5013638; Wed, 9 Mar 2005 10:59:11 -0800 Date: Wed, 9 Mar 2005 10:59:11 -0800 Message-Id: <200503091859.j29IxBq5013638@dino-lnx.cisco.com> From: Dino Farinacci To: tian@redback.com In-reply-to: <1110352949.5157.16558.camel@oslo.redback.com> (message from Albert Tian on Tue, 08 Mar 2005 23:22:29 -0800) Subject: Re: [Pim-state] sequence number and retransmission References: <20050308174627.7428.qmail@web81301.mail.yahoo.com> <200503090218.j292IPpK014175@dino-lnx.cisco.com> <1110349643.9115.16041.camel@oslo.redback.com> <200503090646.j296k0nH011596@dino-lnx.cisco.com> <1110352031.5161.16415.camel@oslo.redback.com> <200503090712.j297C2so029858@dino-lnx.cisco.com> <1110352949.5157.16558.camel@oslo.redback.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 19:00:17 -0000 >> suppress old messages would be hard to do when there are other states in >> the same message, the benefit is probabaly not worth the effort. Yes, it is hard in the sequence-number-per-message scheme. But in the sequence-number-per-route, there are no queued messages, the retransmission state is in the PIM topology table. Dino From dino@dino-lnx.cisco.com Wed Mar 9 14:01:35 2005 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j29J1ZPj021919 for ; Wed, 9 Mar 2005 14:01:35 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 09 Mar 2005 11:00:45 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,151,1107763200"; d="scan'208"; a="166165074:sNHT10023268132" Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j29J0CTM000553; Wed, 9 Mar 2005 11:00:12 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j29J0A5a013702; Wed, 9 Mar 2005 11:00:10 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j29J0Abm013698; Wed, 9 Mar 2005 11:00:10 -0800 Date: Wed, 9 Mar 2005 11:00:10 -0800 Message-Id: <200503091900.j29J0Abm013698@dino-lnx.cisco.com> From: Dino Farinacci To: rkebler@avici.com In-reply-to: <34434.10.2.2.223.1110387377.squirrel@webmail.avici.com> (rkebler@avici.com) Subject: Re: [Pim-state] sequence number and retransmission References: <20050308174627.7428.qmail@web81301.mail.yahoo.com><200503090218.j292I PpK014175@dino-lnx.cisco.com><1110349643.9115.16041.camel@oslo.redback .com><200503090646.j296k0nH011596@dino-lnx.cisco.com> <1110352031.5161.16415.camel@oslo.redback.com> <34434.10.2.2.223.1110387377.squirrel@webmail.avici.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 19:01:35 -0000 >> I think the sequence numbers will be kept per neighbor, so that if we >> want to find the next sequence number, we will see what the last one >> was that we sent for that nbr. There is one added complication that I >> see with this method. An entry can be on more than one neighbor's >> retran list (if the entry had an iif change). In this case, the entry >> will be holding a list of sequence numbers. I think you can have a number which means "the latest" and it can be neighbor independent. That is if you use per-route-sequence-numbers. Dino From tian@redback.com Wed Mar 9 14:05:29 2005 Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j29J5SFv021936 for ; Wed, 9 Mar 2005 14:05:28 -0500 (EST) (envelope-from tian@redback.com) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 2E9932A8AA4; Wed, 9 Mar 2005 11:05:23 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10500-09; Wed, 9 Mar 2005 11:05:23 -0800 (PST) Received: from nantes.redback.com (nantes.redback.com [155.53.44.171]) by prattle.redback.com (Postfix) with ESMTP id ED02C2A8AA3; Wed, 9 Mar 2005 11:05:22 -0800 (PST) Subject: Re: [Pim-state] sequence number and retransmission From: Albert Tian To: Dino Farinacci In-Reply-To: <200503091900.j29J0Abm013698@dino-lnx.cisco.com> References: <20050308174627.7428.qmail@web81301.mail.yahoo.com> <200503090218.j292I PpK014175@dino-lnx.cisco.com> <1110349643.9115.16041.camel@oslo.redback .com> <200503090646.j296k0nH011596@dino-lnx.cisco.com> <1110352031.5161.16415.camel@oslo.redback.com> <34434.10.2.2.223.1110387377.squirrel@webmail.avici.com> <200503091900.j29J0Abm013698@dino-lnx.cisco.com> Content-Type: text/plain Message-Id: <1110395122.7291.1594.camel@nantes.redback.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 09 Mar 2005 11:05:22 -0800 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 19:05:29 -0000 On Wed, 2005-03-09 at 11:00, Dino Farinacci wrote: > >> I think the sequence numbers will be kept per neighbor, so that if we > >> want to find the next sequence number, we will see what the last one > >> was that we sent for that nbr. There is one added complication that I > >> see with this method. An entry can be on more than one neighbor's > >> retran list (if the entry had an iif change). In this case, the entry > >> will be holding a list of sequence numbers. > > I think you can have a number which means "the latest" and it can be > neighbor independent. That is if you use per-route-sequence-numbers. In case of a serious of rpf neighbor changes, we do have to keep a list of previous upstream neighbors and latest sequence numbers for each. Thanks Alert > > Dino From dino@dino-lnx.cisco.com Wed Mar 9 14:15:06 2005 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j29JF5Tf021963 for ; Wed, 9 Mar 2005 14:15:06 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 09 Mar 2005 11:15:27 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j29JEoTM004546; Wed, 9 Mar 2005 11:14:51 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j29JEocs021768; Wed, 9 Mar 2005 11:14:50 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j29JEovk021764; Wed, 9 Mar 2005 11:14:50 -0800 Date: Wed, 9 Mar 2005 11:14:50 -0800 Message-Id: <200503091914.j29JEovk021764@dino-lnx.cisco.com> From: Dino Farinacci To: tian@redback.com In-reply-to: <1110395122.7291.1594.camel@nantes.redback.com> (message from Albert Tian on Wed, 09 Mar 2005 11:05:22 -0800) Subject: Re: [Pim-state] sequence number and retransmission References: <20050308174627.7428.qmail@web81301.mail.yahoo.com> <200503090218.j292I PpK014175@dino-lnx.cisco.com> <1110349643.9115.16041.camel@oslo.redback .com> <200503090646.j296k0nH011596@dino-lnx.cisco.com> <1110352031.5161.16415.camel@oslo.redback.com> <34434.10.2.2.223.1110387377.squirrel@webmail.avici.com> <200503091900.j29J0Abm013698@dino-lnx.cisco.com> <1110395122.7291.1594.camel@nantes.redback.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 19:15:06 -0000 >> In case of a serious of rpf neighbor changes, we do have to keep a list >> of previous upstream neighbors and latest sequence numbers for each. This is where we should put some brain-share towards. Figuring out how this can be simplified or eliminated completely. Dino From sboddapa@yahoo.com Wed Mar 9 14:33:32 2005 Received: from web81303.mail.yahoo.com (web81303.mail.yahoo.com [206.190.37.78]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j29JXWtJ022000 for ; Wed, 9 Mar 2005 14:33:32 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050309193327.37178.qmail@web81303.mail.yahoo.com> Received: from [64.47.51.130] by web81303.mail.yahoo.com via HTTP; Wed, 09 Mar 2005 11:33:26 PST Date: Wed, 9 Mar 2005 11:33:26 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] consensus To: Dino Farinacci In-Reply-To: <200503091857.j29IvjIQ013575@dino-lnx.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 19:33:32 -0000 --- Dino Farinacci wrote: > >> sequence number. The benefit is also that the > receiver > >> of the ACK does not have to go through the entire > >> message to figure out if every state is ACKed or > not. > > There is not much of a problem here. In this > incremental mode most JPs > will be triggered and won't be large, modulo > initialization sequences. So > we actually reduced CPU time processing large > periodic messages. > Your assumption is that triggered messages wont be large. RPF changes cause triggered messages, all entries could point to the same RPF nbr. That new nbr will need to get all the Joins. In MVPN scenario, you could have different VPNs coming up and going down, nbrs coming up and going down, routes changing. Wouldnt it be better if we reduced the CPU utilization without making such an assumption? Triggered or not, CPU utilization is much less if you just acked a message instead of acking every entry, isnt it? > I already mentioned the disadvantages, which I > think outweight the > benefits. > Sorry Dino, I still do not see what the disadvantages are of using a per message seq num. Can you clarify please? > >> The problem of some routers getting some JPs and > some > >> not can happen today also. As long as the latest > state > > The JPs themself have no sequencing or > retransmission logic. If > you get a periodic JP today you don't know or > care if it's a duplicate. > With a reliable scheme with sequence numbers you > have to sequence out > of order messages and do duplicate detection (if > multicasted). > Even with a reliable scheme, the upstream router does not have to care if it is a dup or not. The sender does not have to worry about out of order acks because you accept an ACK only if it matches what you have, and the sender always increments the sequence number when it sends out the JP. Anything less than it you will ignore. What is the out of order issue? Can you give an example? > >> > KISS principle. You are trying to be too > clever. > >> > ;-) > >> > > >> Come on, it's just C :-) > > You have missed the point. We are not talking > about the language which > implements the algorithm, we are talking about > algorithms people will have > to use, manage, and debug. The issue for the > implementor is only the tip > of the iceberg, should be considered, but there > are many more aspects that > deserve consideration too. > Exactly my point too (the C part was just a poor attempt at being funny, I guess). Our criterion should not be that if it is more code, we should not do it. If more code achieves efficiency, it might be worth it. What is the purpose of an ACK? Isnt it to say that a Message sent by D to U was received at U? Why do you need to ack individual contents? Suresh From rkebler@avici.com Wed Mar 9 14:46:53 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j29Jkq3p022072 for ; Wed, 9 Mar 2005 14:46:53 -0500 (EST) (envelope-from rkebler@avici.com) Received: from webmail.avici.com (mailhost.avici.com [127.0.0.1]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id j29Jke7k019740; Wed, 9 Mar 2005 14:46:40 -0500 Received: from 10.2.2.223 (SquirrelMail authenticated user rkebler) by webmail.avici.com with HTTP; Wed, 9 Mar 2005 14:46:40 -0500 (EST) Message-ID: <34934.10.2.2.223.1110397600.squirrel@webmail.avici.com> In-Reply-To: <200503091914.j29JEovk021764@dino-lnx.cisco.com> References: <20050308174627.7428.qmail@web81301.mail.yahoo.com> <200503090218.j292I PpK014175@dino-lnx.cisco.com> <1110349643.9115.16041.camel@oslo.redback .com> <200503090646.j296k0nH011596@dino-lnx.cisco.com> <1110352031.5161.16415.camel@oslo.redback.com> <34434.10.2.2.223.1110387377.squirrel@webmail.avici.com> <200503091900.j29J0Abm013698@dino-lnx.cisco.com> <1110395122.7291.1594.camel@nantes.redback.com> <200503091914.j29JEovk021764@dino-lnx.cisco.com> Date: Wed, 9 Mar 2005 14:46:40 -0500 (EST) Subject: Re: [Pim-state] sequence number and retransmission From: rkebler@avici.com To: "Dino Farinacci" User-Agent: SquirrelMail/1.4.0-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 19:46:53 -0000 Well, I think we would want to keep a list of neighbors to which an entry needs to be retransmitted in either case. >>> In case of a serious of rpf neighbor changes, we do have to keep a list >>> of previous upstream neighbors and latest sequence numbers for each. > > This is where we should put some brain-share towards. Figuring out how > this > can be simplified or eliminated completely. > > Dino > From dino@dino-lnx.cisco.com Wed Mar 9 14:58:10 2005 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j29Jw9u1022101 for ; Wed, 9 Mar 2005 14:58:10 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 09 Mar 2005 11:58:38 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j29Jw2YO013057; Wed, 9 Mar 2005 11:58:02 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j29Jw2YP023104; Wed, 9 Mar 2005 11:58:02 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j29Jw2Db023099; Wed, 9 Mar 2005 11:58:02 -0800 Date: Wed, 9 Mar 2005 11:58:02 -0800 Message-Id: <200503091958.j29Jw2Db023099@dino-lnx.cisco.com> From: Dino Farinacci To: rkebler@avici.com In-reply-to: <34934.10.2.2.223.1110397600.squirrel@webmail.avici.com> (rkebler@avici.com) Subject: Re: [Pim-state] sequence number and retransmission References: <20050308174627.7428.qmail@web81301.mail.yahoo.com> <200503090218.j292I PpK014175@dino-lnx.cisco.com> <1110349643.9115.16041.camel@oslo.redback .com> <200503090646.j296k0nH011596@dino-lnx.cisco.com> <1110352031.5161.16415.camel@oslo.redback.com> <34434.10.2.2.223.1110387377.squirrel@webmail.avici.com> <200503091900.j29J0Abm013698@dino-lnx.cisco.com> <1110395122.7291.1594.camel@nantes.redback.com> <200503091914.j29JEovk021764@dino-lnx.cisco.com> <34934.10.2.2.223.1110397600.squirrel@webmail.avici.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 19:58:14 -0000 >> Well, I think we would want to keep a list of neighbors to which >> an entry needs to be retransmitted in either case. Well, in most if not all cases, it is the RPF neighbor. It's only the RPF change case where the problem presents itself. Here is an excerpt from the design I had previously sent. Dino ------------------------------------------------------------------------------- [10] RPF Changes: o When an RPF neighbor change occurs, a JP with join-list entries is sent to the newly determined RPF neighbor. It is optional to also send a JP with prune-list entries to the previous RPF neighbor. In the later case, while the JP-prune-list sender is waiting for a JP-Ack from the previous RPF neighbor, other RPF change could occur. An implementation has to remember the previous RPF neighbors so it can make sure the prune-list JP gets reliably sent. ------------------------------------------------------------------------------- From sboddapa@yahoo.com Wed Mar 9 15:01:58 2005 Received: from web81304.mail.yahoo.com (web81304.mail.yahoo.com [206.190.37.79]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j29K1woM022127 for ; Wed, 9 Mar 2005 15:01:58 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050309200152.15257.qmail@web81304.mail.yahoo.com> Received: from [64.47.51.130] by web81304.mail.yahoo.com via HTTP; Wed, 09 Mar 2005 12:01:52 PST Date: Wed, 9 Mar 2005 12:01:52 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] sequence number and retransmission To: Dino Farinacci , tian@redback.com In-Reply-To: <200503091914.j29JEovk021764@dino-lnx.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 20:01:58 -0000 If we are increasing refresh interval to large values, and we dont want to make prunes reliable in the case of RPF changes (thereby eliminating lists of sequence numbers for older nbrs), we could be left with persistent state. We have no choice but to make sure that the Prunes sent to old nbrs are also reliable. But instead of keeping the state to sequence num association for older nbrs until they are acked, maybe we could say that after n retransmissions, we stop retxing even if we do not receive ACKS, the assumption being that it is more of an exception than a rule that such a situation will occur. Would that be acceptable? Suresh --- Dino Farinacci wrote: > >> In case of a serious of rpf neighbor changes, we > do have to keep a list > >> of previous upstream neighbors and latest > sequence numbers for each. > > This is where we should put some brain-share > towards. Figuring out how this > can be simplified or eliminated completely. > > Dino > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state > From dino@dino-lnx.cisco.com Wed Mar 9 15:10:11 2005 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j29KABpN022151 for ; Wed, 9 Mar 2005 15:10:11 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 09 Mar 2005 12:10:42 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,151,1107763200"; d="scan'208"; a="166192944:sNHT17969208" Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j29KA3TM027628; Wed, 9 Mar 2005 12:10:03 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j29KA3iZ023571; Wed, 9 Mar 2005 12:10:03 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j29KA3kB023567; Wed, 9 Mar 2005 12:10:03 -0800 Date: Wed, 9 Mar 2005 12:10:03 -0800 Message-Id: <200503092010.j29KA3kB023567@dino-lnx.cisco.com> From: Dino Farinacci To: sboddapa@yahoo.com In-reply-to: <20050309193327.37178.qmail@web81303.mail.yahoo.com> (message from Suresh Boddapati on Wed, 9 Mar 2005 11:33:26 -0800 (PST)) Subject: Re: [Pim-state] consensus References: <20050309193327.37178.qmail@web81303.mail.yahoo.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 20:10:11 -0000 >> Sorry Dino, I still do not see what the disadvantages >> are of using a per message seq num. Can you clarify >> please? Go back and think more about my issues with buffering and flow control. And how having another layer of messaging will cause congestion issues between the PIM topology table layer and the transmission layer. Both IS-IS and OSPF have this tightly coupled with rate-limiting of LSP generation. BGP does this by explicitly not having a transmission layer inside of it by using an external layer, TCP. Years ago, there were lessons learned doing EIGRP this way, having a transmission layer inside the protocol. >> Exactly my point too (the C part was just a poor Hmm, I did not see you make it. >> What is the purpose of an ACK? Isnt it to say that a >> Message sent by D to U was received at U? Why do you >> need to ack individual contents? See above. Dino From dino@dino-lnx.cisco.com Wed Mar 9 18:34:46 2005 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j29NYkDa022501 for ; Wed, 9 Mar 2005 18:34:46 -0500 (EST) (envelope-from dino@dino-lnx.cisco.com) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 09 Mar 2005 15:35:13 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j29NYTYO003295; Wed, 9 Mar 2005 15:34:29 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j29NYTMD023722; Wed, 9 Mar 2005 15:34:29 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j29NYSW7023718; Wed, 9 Mar 2005 15:34:28 -0800 Date: Wed, 9 Mar 2005 15:34:28 -0800 Message-Id: <200503092334.j29NYSW7023718@dino-lnx.cisco.com> From: Dino Farinacci To: sboddapa@yahoo.com In-reply-to: <20050309200152.15257.qmail@web81304.mail.yahoo.com> (message from Suresh Boddapati on Wed, 9 Mar 2005 12:01:52 -0800 (PST)) Subject: Re: [Pim-state] sequence number and retransmission References: <20050309200152.15257.qmail@web81304.mail.yahoo.com> Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Wed, 09 Mar 2005 23:34:47 -0000 >> persistent state. We have no choice but to make sure >> that the Prunes sent to old nbrs are also reliable. Old neighbors could be down where you will not know until the neighbor timeout. Before that point, the retransmision timers will be shorter and hence you will retransmit unnecessarily. >> association for older nbrs until they are acked, maybe >> we could say that after n retransmissions, we stop >> retxing even if we do not receive ACKS, the assumption A retransmission limit could fail for slow processing neighbors. Ones that are congested or have slower CPUs then the downstream sender. Dino From sboddapa@yahoo.com Thu Mar 10 16:13:18 2005 Received: from web81307.mail.yahoo.com (web81307.mail.yahoo.com [206.190.37.82]) by rock.mountain2sea.com (8.13.1/8.13.1) with SMTP id j2ALDHra025031 for ; Thu, 10 Mar 2005 16:13:17 -0500 (EST) (envelope-from sboddapa@yahoo.com) Message-ID: <20050310211311.72890.qmail@web81307.mail.yahoo.com> Received: from [64.47.51.130] by web81307.mail.yahoo.com via HTTP; Thu, 10 Mar 2005 13:13:11 PST Date: Thu, 10 Mar 2005 13:13:11 -0800 (PST) From: Suresh Boddapati Subject: Re: [Pim-state] sequence number and retransmission To: Dino Farinacci In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 10 Mar 2005 21:13:18 -0000 --- Dino Farinacci wrote: > >> persistent state. We have no choice but to make > sure > >> that the Prunes sent to old nbrs are also > reliable. > > Old neighbors could be down where you will not > know until the neighbor > timeout. Before that point, the retransmision > timers will be shorter and > hence you will retransmit unnecessarily. > True. But since the JPs are exponentially backed off, the number of rtxs sent before detection of nbr timeout should be small. Since you say that triggered messages are not going to be so many, even with RPF changes, this should be fine, right? > >> association for older nbrs until they are acked, > maybe > >> we could say that after n retransmissions, we > stop > >> retxing even if we do not receive ACKS, the > assumption > > A retransmission limit could fail for slow > processing neighbors. Ones that > are congested or have slower CPUs then the > downstream sender. > How much time do you think would be reasonable to account for such nbrs? A minute, 2 minutes? If we start the rxt interval say at 2 seconds, within 5 retries, we would have crossed a minute's time if we back off exponentially. Would that be bad? Suresh From rkebler@avici.com Thu Mar 10 18:31:54 2005 Received: from mailhost.avici.com (gateway.avici.com [208.246.215.5] (may be forged)) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j2ANVrnb025276 for ; Thu, 10 Mar 2005 18:31:54 -0500 (EST) (envelope-from rkebler@avici.com) Received: from webmail.avici.com (mailhost.avici.com [127.0.0.1]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id j2ANUj7k032489; Thu, 10 Mar 2005 18:30:45 -0500 Received: from 10.2.2.223 (SquirrelMail authenticated user rkebler) by webmail.avici.com with HTTP; Thu, 10 Mar 2005 18:30:46 -0500 (EST) Message-ID: <39317.10.2.2.223.1110497446.squirrel@webmail.avici.com> In-Reply-To: <20050310211311.72890.qmail@web81307.mail.yahoo.com> References: 6667 <20050310211311.72890.qmail@web81307.mail.yahoo.com> Date: Thu, 10 Mar 2005 18:30:46 -0500 (EST) Subject: Re: [Pim-state] sequence number and retransmission From: rkebler@avici.com To: "Suresh Boddapati" User-Agent: SquirrelMail/1.4.0-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Avici-MailScanner-Information: Please contact the ISP for more information Cc: pim-state@mountain2sea.com X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.3 Precedence: list List-Id: IETF PIM state refresh reduction list. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , X-List-Received-Date: Thu, 10 Mar 2005 23:31:54 -0000 I would say that the messages should be retransmitted as long as the adjacency is up. I don't think we want to leave it in inconsistent state with the adjacency staying up. I'm not crazy about these messages doing the job of the hello messages, but I realize implementations have done similar things for other protocols. We could suggest a config option and bring down the adjacency if the configured threshold is reached, with the default being retry forever. -Bob > > --- Dino Farinacci wrote: >> >> persistent state. We have no choice but to make >> sure >> >> that the Prunes sent to old nbrs are also >> reliable. >> >> Old neighbors could be down where you will not >> know until the neighbor >> timeout. Before that point, the retransmision >> timers will be shorter and >> hence you will retransmit unnecessarily. >> > True. But since the JPs are exponentially backed off, > the number of rtxs sent before detection of nbr > timeout should be small. Since you say that triggered > messages are not going to be so many, even with RPF > changes, this should be fine, right? > >> >> association for older nbrs until they are acked, >> maybe >> >> we could say that after n retransmissions, we >> stop >> >> retxing even if we do not receive ACKS, the >> assumption >> >> A retransmission limit could fail for slow >> processing neighbors. Ones that >> are congested or have slower CPUs then the >> downstream sender. >> > How much time do you think would be reasonable to > account for such nbrs? A minute, 2 minutes? If we > start the rxt interval say at 2 seconds, within 5 > retries, we would have crossed a minute's time if we > back off exponentially. Would that be bad? > > Suresh > > _______________________________________________ > Pim-state mailing list > Pim-state@mountain2sea.com > http://www.mountain2sea.com/mailman/listinfo/pim-state > From mmcbride@cisco.com Mon Jul 11 19:26:12 2005 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j6BNQBiq027665 for ; Mon, 11 Jul 2005 19:26:12 -0400 (EDT) (envelope-from mmcbride@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 11 Jul 2005 16:26:07 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6BNPxp3028645; Mon, 11 Jul 2005 16:26:01 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 16:25:48 -0700 Received: from irp-view7.cisco.com ([171.70.65.144]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 16:25:48 -0700 Date: Mon, 11 Jul 2005 16:25:48 -0700 (PDT) From: Mike McBride To: Thomas Morin In-Reply-To: <1119367666.14878.46.camel@wintermute> Message-ID: References: <1119367666.14878.46.camel@wintermute> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 11 Jul 2005 23:25:48.0240 (UTC) FILETIME=[DE80C500:01C5866F] Cc: pim-state@mountain2sea.com Subject: [Pim-state] Re: Multicast VPN Survey X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF PIM state refresh reduction list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2005 23:26:12 -0000 Please keep Tom and I in the loop on results you get back from this survey. We initiated a pim refresh design team but we've had zero discussion on the list since the last ietf. We are waiting for more direction from l3vpn to decide on whether we want to go down the road of enhancing pim. If it turns out that there is a significant, near term, mvpn scalability problem, we'll need to determine if an enhancement to pim is the answer or if l3vpn wg needs to otherwise figure it out within mvpn design. thanks, mike On Tue, 21 Jun 2005, Thomas Morin wrote: > Hi, > > As suggested last IETF in march, we are proposing a short survey about > multicast VPN uses. > The survey results would be used in draft-ietf-l3vpn-ppvpn-mcast-reqts, > to express use cases and their corresponding requirements, especially in > terms of scalability numbers. > > Here is the draft version of the survey that already was discussed on > the multicast VPN requirements mailing list. > We'd like to have the WG feedback about this document before proceeding > (i.e before sending it to those who may answer it). > > Thank you for your feedback, > > -Thomas > > ------------------->8---------------------->8---------------------- > > ***************************************************************************** > DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - > DRAFT > FT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - > DRAFT - > ***************************************************************************** > > Multicast VPN Survey - 2005-06 > > 1. Presentation > > 1.1 Context and goal > > Current work in the l3vpn IETF Working group include the > definition > of requirements for Multicast in L3 VPNs and specification of a > multicast VPN solution. In this perspective, the authors of the > requirement draft [draft-ietf-l3vpn-ppvpn-mcast-reqts] are > initiating a survey to better express requirements, and > especially > scalability requirements. > > A summary of the results of this survey will be included in > the requirements document which should serve as guidelines for > solution design. > > The scope of this survey is multicast in L3VPNs: the mechanisms > setup by a VPN provider to carry customer multicast traffic of > customers. > > 1.2 Answering this survey > > This survey will hopefuly be answered by ISPs planing to offer > a multicast VPN service, and possibly by VPN customers having a > need for such a service (not all questions of this survey will > be relevant in that later case). > > The answers should relate not to what you'd expect today, > but more to what you see as a longer term target for such a > service. For scalability figures, please answer what you think > you may need/like to support in the longer term. > Please answer as much questions as possible, but feel free to > ommit answers if the question aren't relevant for you. > > If you expectd different kinds of significantly different > deployments, it is better to answer the survey multiple times. > > 1.3 Sending the results > > Once completed, we'd appreciate that you send the document > to . > > [or, depending on the degree of anonymization required...] > > Once completed, we'd appreciate that you send the document > to , which will anonymize the survey result before > forwarding > them to the L3VPN WG multicast VPN requirement drafts authors. > > 2. Questions > > This survey is divided into three parts. > > The first one relates to quantitative questions that can be quickly > answered by a simple figure (numbers of multicast PEs, of multicast > VPNs,...), and the second one is made of qualitative questions > regarding the expected use of the service (features, dynamicity, > client application use case patterns...). > > In the last part you can express more in detail considerations you > may have about multicast VPN deployments, including for instance > specific use cases you think may highlight specific important > points. > > 2.1 Quantitative questions > > Here, we are just expecting rough figures and orders of > magnitude, > such as: 20k, tens of thousands, hundreds, O(10^2), etc. > > 2.1.1 Deployment and offer > > 1. Number of VPNs for which multicast is made available > > * total: ....... > > * per PE: ....... > > * per AS, per provider : ...... > (inter-AS or inter-provider context) > > 2. CEs per VPN per PE, for which multicast is enabled: > > .......... > > 3. number of PEs per VPN with multicast enabled (source or > receiver): > > .......... > > 4. number of PEs with multicast service enabled: > > .......... > > 2.1.2 Parameters related to customer applications and usage > patterns > > 1. Number of PEs connected to multicast receivers: > > .......... > > 2. Number of PEs connected to multicast sources: > > .......... > > 3. Number of multicast (*,G) or (S,G) sourced ... > > * ...per VPN: .......... > > * ...per PE: .......... > > * ...per CE: .......... > > 2.2 Qualitative questions > > 2.2.1 Expected VPN customer applications > > 1. Type of multicast applications > > Mutlicast applications deployed over a multicast VPN can > be differentiated depending on many criterias, such as, > for instance: real-time or not, bandwidth, > receiver-source > structure (one-to-many, many-to-many, many-to-few...), > sensitivity to packet loss, number of streams... > > Please give examples of some possible application, in > the form of eg.: > > o "real-time / few-to-many / tens of Mbps" > o "non real time / multiple few-to-few streams / known > sources, unknown receivers / hundreds of Mbps" > > a) ........ > > b) ........ > > c) ......... > > ... > > 2. Dynamics > > * Do you expect customer applications that are sensitive > to > multicast join/latency (time to receive/leave a stream) ? > > ........ > > * What kind of frequency do you expect for mcast routing > changes, at the PE level ? (eg. "not more than XX leave > and > joins per hour") > > ........ > > * Predictability of sources and receivers locations: do > you > expect to be able, for each said multicast VPN customer, > to > have an a priori on the location of customer sources > and/or > receivers ? > > ........ > > 3. Customer side protocols: among the following, please > chose which you'd expect to support at the CE-PE level > (y/n) ? > > * PIM-SM: > * PIM-SSM: > * Bidir PIM: > * IGMP(v2/v3): > * MLDv2: > * PIM-DM: > > 4. Would you plan to support multicast in a carrier's > carrier > context ? > > ........ > > 2.2.1 Network Considerations > > 1. Do you have PE for which reachability is less good than > others (costly or scarce bandwidth) ? > > ........ > > 2. Do you think some VPNs of your customers may have same > or close sets of PEs, and may thus possibly benefit from > using the same PE-to-PE point to multipoint tunnels ? > > ........ > > 3. Do you plan to deploy multicast VPNs in a multi-AS > context ? > > ........ > > 4. Do you plan to deploy multicast VPNs in a multi-provider > context ? > > ........ > > 2.2.1 Relative Importance on different aspects > > Please rate the following items according to their relative > importance - from 1 (Unimportant) to 5 (Important). > > * Seem-less interoperability with the current unicast > model: ... > > * Multicast VPN must not impose additional > requirements on CE devices: ... > > * Re-use of existing multicast protocols for multcast > traffic > transport over the provider core network: ... > > * Support of TE features such as bandwidth reservation and > admission control: ... > > * Provide the same level of security for both the customer > and > the SP as available with unicast VPNs: ... > > * Support for global Internet multicast > (emission/reception): ... > > * Support for Extranet (having a VRF in more than one > multicast VPN): ... > > 3. Specific considerations you may want to express > > ........... > > > Thank you very much ! > > > From thomas.morin@francetelecom.com Tue Jul 12 09:49:58 2005 Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by rock.mountain2sea.com (8.13.1/8.13.1) with ESMTP id j6CDnvrm029315 for ; Tue, 12 Jul 2005 09:49:57 -0400 (EDT) (envelope-from thomas.morin@francetelecom.com) Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 15:49:54 +0200 Received: from l-dhcp-5342-2.rd.francetelecom.fr ([10.193.15.80]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 15:49:53 +0200 From: Thomas Morin To: Mike McBride In-Reply-To: References: <1119367666.14878.46.camel@wintermute> Content-Type: multipart/alternative; boundary="=-rQUpZ2Vp4X/yWqv5gD0D" Organization: France Telecom R&D CORE-CPN-MTM Date: Tue, 12 Jul 2005 15:49:53 +0200 Message-Id: <1121176193.7474.80.camel@wintermute> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-OriginalArrivalTime: 12 Jul 2005 13:49:53.0838 (UTC) FILETIME=[94E334E0:01C586E8] Cc: Yuji KAMITE , pim-state@mountain2sea.com, mvpn-authors@external.cisco.com Subject: [Pim-state] Re: Multicast VPN Survey X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF PIM state refresh reduction list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2005 13:49:59 -0000 --=-rQUpZ2Vp4X/yWqv5gD0D Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Mike, Mike McBride : > Please keep Tom and I in the loop on results you get back from this > survey. Sure, I'll keep you in the loop for the survey results. > We initiated a pim refresh design team but we've had zero > discussion on the list since the last ietf. We are waiting for more > direction from l3vpn to decide on whether we want to go down the road > of enhancing pim. If it turns out that there is a significant, > near term, mvpn scalability problem, we'll need to determine if > an enhancement to pim is the answer or if l3vpn wg needs to otherwise > figure it out within mvpn design. About the pim refresh effort and its relation to 2547 multicast solution design : discussions about draft-ietf-l3vpn-2547bis-mcast orientations are still in their first steps, so I think its too early yet to give strong directions. But I guess we can keep you updated (mailing list CC'd). Also, it's probably worth mentioning that the pim refresh reduction effort also makes sense in the multicast L2VPN context (solution drafts and draft-kamite-l2vpn-vpls-mcast-reqts). Regards, -Thomas > On Tue, 21 Jun 2005, Thomas Morin wrote: > > > Hi, > > > > As suggested last IETF in march, we are proposing a short survey about > > multicast VPN uses. > > The survey results would be used in draft-ietf-l3vpn-ppvpn-mcast-reqts, > > to express use cases and their corresponding requirements, especially in > > terms of scalability numbers. > > > > Here is the draft version of the survey that already was discussed on > > the multicast VPN requirements mailing list. > > We'd like to have the WG feedback about this document before proceeding > > (i.e before sending it to those who may answer it). > > > > Thank you for your feedback, > > > > -Thomas > > > > ------------------->8---------------------->8---------------------- > > > > ***************************************************************************** > > DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - > > DRAFT > > FT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - > > DRAFT - > > ***************************************************************************** > > > > Multicast VPN Survey - 2005-06 > > > > 1. Presentation > > > > 1.1 Context and goal > > > > Current work in the l3vpn IETF Working group include the > > definition > > of requirements for Multicast in L3 VPNs and specification of a > > multicast VPN solution. In this perspective, the authors of the > > requirement draft [draft-ietf-l3vpn-ppvpn-mcast-reqts] are > > initiating a survey to better express requirements, and > > especially > > scalability requirements. > > > > A summary of the results of this survey will be included in > > the requirements document which should serve as guidelines for > > solution design. > > > > The scope of this survey is multicast in L3VPNs: the mechanisms > > setup by a VPN provider to carry customer multicast traffic of > > customers. > > > > 1.2 Answering this survey > > > > This survey will hopefuly be answered by ISPs planing to offer > > a multicast VPN service, and possibly by VPN customers having a > > need for such a service (not all questions of this survey will > > be relevant in that later case). > > > > The answers should relate not to what you'd expect today, > > but more to what you see as a longer term target for such a > > service. For scalability figures, please answer what you think > > you may need/like to support in the longer term. > > Please answer as much questions as possible, but feel free to > > ommit answers if the question aren't relevant for you. > > > > If you expectd different kinds of significantly different > > deployments, it is better to answer the survey multiple times. > > > > 1.3 Sending the results > > > > Once completed, we'd appreciate that you send the document > > to . > > > > [or, depending on the degree of anonymization required...] > > > > Once completed, we'd appreciate that you send the document > > to , which will anonymize the survey result before > > forwarding > > them to the L3VPN WG multicast VPN requirement drafts authors. > > > > 2. Questions > > > > This survey is divided into three parts. > > > > The first one relates to quantitative questions that can be quickly > > answered by a simple figure (numbers of multicast PEs, of multicast > > VPNs,...), and the second one is made of qualitative questions > > regarding the expected use of the service (features, dynamicity, > > client application use case patterns...). > > > > In the last part you can express more in detail considerations you > > may have about multicast VPN deployments, including for instance > > specific use cases you think may highlight specific important > > points. > > > > 2.1 Quantitative questions > > > > Here, we are just expecting rough figures and orders of > > magnitude, > > such as: 20k, tens of thousands, hundreds, O(10^2), etc. > > > > 2.1.1 Deployment and offer > > > > 1. Number of VPNs for which multicast is made available > > > > * total: ....... > > > > * per PE: ....... > > > > * per AS, per provider : ...... > > (inter-AS or inter-provider context) > > > > 2. CEs per VPN per PE, for which multicast is enabled: > > > > .......... > > > > 3. number of PEs per VPN with multicast enabled (source or > > receiver): > > > > .......... > > > > 4. number of PEs with multicast service enabled: > > > > .......... > > > > 2.1.2 Parameters related to customer applications and usage > > patterns > > > > 1. Number of PEs connected to multicast receivers: > > > > .......... > > > > 2. Number of PEs connected to multicast sources: > > > > .......... > > > > 3. Number of multicast (*,G) or (S,G) sourced ... > > > > * ...per VPN: .......... > > > > * ...per PE: .......... > > > > * ...per CE: .......... > > > > 2.2 Qualitative questions > > > > 2.2.1 Expected VPN customer applications > > > > 1. Type of multicast applications > > > > Mutlicast applications deployed over a multicast VPN can > > be differentiated depending on many criterias, such as, > > for instance: real-time or not, bandwidth, > > receiver-source > > structure (one-to-many, many-to-many, many-to-few...), > > sensitivity to packet loss, number of streams... > > > > Please give examples of some possible application, in > > the form of eg.: > > > > o "real-time / few-to-many / tens of Mbps" > > o "non real time / multiple few-to-few streams / known > > sources, unknown receivers / hundreds of Mbps" > > > > a) ........ > > > > b) ........ > > > > c) ......... > > > > ... > > > > 2. Dynamics > > > > * Do you expect customer applications that are sensitive > > to > > multicast join/latency (time to receive/leave a stream) ? > > > > ........ > > > > * What kind of frequency do you expect for mcast routing > > changes, at the PE level ? (eg. "not more than XX leave > > and > > joins per hour") > > > > ........ > > > > * Predictability of sources and receivers locations: do > > you > > expect to be able, for each said multicast VPN customer, > > to > > have an a priori on the location of customer sources > > and/or > > receivers ? > > > > ........ > > > > 3. Customer side protocols: among the following, please > > chose which you'd expect to support at the CE-PE level > > (y/n) ? > > > > * PIM-SM: > > * PIM-SSM: > > * Bidir PIM: > > * IGMP(v2/v3): > > * MLDv2: > > * PIM-DM: > > > > 4. Would you plan to support multicast in a carrier's > > carrier > > context ? > > > > ........ > > > > 2.2.1 Network Considerations > > > > 1. Do you have PE for which reachability is less good than > > others (costly or scarce bandwidth) ? > > > > ........ > > > > 2. Do you think some VPNs of your customers may have same > > or close sets of PEs, and may thus possibly benefit from > > using the same PE-to-PE point to multipoint tunnels ? > > > > ........ > > > > 3. Do you plan to deploy multicast VPNs in a multi-AS > > context ? > > > > ........ > > > > 4. Do you plan to deploy multicast VPNs in a multi-provider > > context ? > > > > ........ > > > > 2.2.1 Relative Importance on different aspects > > > > Please rate the following items according to their relative > > importance - from 1 (Unimportant) to 5 (Important). > > > > * Seem-less interoperability with the current unicast > > model: ... > > > > * Multicast VPN must not impose additional > > requirements on CE devices: ... > > > > * Re-use of existing multicast protocols for multcast > > traffic > > transport over the provider core network: ... > > > > * Support of TE features such as bandwidth reservation and > > admission control: ... > > > > * Provide the same level of security for both the customer > > and > > the SP as available with unicast VPNs: ... > > > > * Support for global Internet multicast > > (emission/reception): ... > > > > * Support for Extranet (having a VRF in more than one > > multicast VPN): ... > > > > 3. Specific considerations you may want to express > > > > ........... > > > > > > Thank you very much ! > > > > > > -- == Thomas MORIN - France Telecom R&D CORE-CPN == Tel.: +33(0) 2 96 05 37 34 - www.francetelecom.com/rd -- --=-rQUpZ2Vp4X/yWqv5gD0D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Mike,

Mike McBride : 
Please keep Tom and I in the loop on results you get back from this
survey.

Sure, I'll keep you in the loop for the survey results.

 We initiated a pim refresh design team but we've had zero
discussion on the list since the last ietf. We are waiting for more
direction from l3vpn to decide on whether we want to go down the road
of enhancing pim. If it turns out that there is a significant,
near term, mvpn scalability problem, we'll need to determine if
an enhancement to pim is the answer or if l3vpn wg needs to otherwise
figure it out within mvpn design.


About the pim refresh effort and its relation to 2547 multicast solution design : discussions about draft-ietf-l3vpn-2547bis-mcast orientations are still in their first steps, so I think its too early yet to give strong directions. But I guess we can keep you updated (mailing list CC'd).

Also, it's probably worth mentioning that the pim refresh reduction effort also makes sense in the multicast L2VPN context (solution drafts and  draft-kamite-l2vpn-vpls-mcast-reqts).

Regards,

-Thomas


On Tue, 21 Jun 2005, Thomas Morin wrote:

> Hi,
>
> As suggested last IETF in march, we are proposing a short survey about
> multicast VPN uses.
> The survey results would be used in draft-ietf-l3vpn-ppvpn-mcast-reqts,
> to express use cases and their corresponding requirements, especially in
> terms of scalability numbers.
>
> Here is the draft version of the survey that already was discussed on
> the multicast VPN requirements mailing list.
> We'd like to have the WG feedback about this document before proceeding
> (i.e before sending it to those who may answer it).
>
> Thank you for your feedback,
>
> -Thomas
>
> ------------------->8---------------------->8----------------------
>
> *****************************************************************************
> DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT -
> DRAFT
> FT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT - DRAFT -
> DRAFT -
> *****************************************************************************
>
> Multicast VPN Survey - 2005-06
>
>   1. Presentation
>
>       1.1 Context and goal
>
>          Current work in the l3vpn IETF Working group include the
> definition
>          of requirements for Multicast in L3 VPNs and specification of a
>          multicast VPN solution. In this perspective, the authors of the
>          requirement draft [draft-ietf-l3vpn-ppvpn-mcast-reqts] are
>          initiating a survey to better express requirements, and
> especially
>          scalability requirements.
>
>          A summary of the results of this survey will be included in
>          the requirements document which should serve as guidelines for
>          solution design.
>
>          The scope of this survey is multicast in L3VPNs: the mechanisms
>          setup by a VPN provider to carry customer multicast traffic of
>          customers.
>
>       1.2 Answering this survey
>
>          This survey will hopefuly be answered by ISPs planing to offer
>          a multicast VPN service, and possibly by VPN customers having a
>          need for such a service (not all questions of this survey will
>          be relevant in that later case).
>
>          The answers should relate not to what you'd expect today,
>          but more to what you see as a longer term target for such a
>          service. For scalability figures, please answer what you think
>          you may need/like to support in the longer term.
>          Please answer as much questions as possible, but feel free to
>          ommit answers if the question aren't relevant for you.
>
>          If you expectd different kinds of significantly different
>          deployments, it is better to answer the survey multiple times.
>
>       1.3 Sending the results
>
>          Once completed, we'd appreciate that you send the document
>          to <thomas.morin@rd.francetelecom.com>.
>
> [or, depending on the degree of anonymization required...]
>
>          Once completed, we'd appreciate that you send the document
>          to <x@x>, which will anonymize the survey result before
> forwarding
>          them to the L3VPN WG multicast VPN requirement drafts authors.
>
>    2. Questions
>
>      This survey is divided into three parts.
>
>      The first one relates to quantitative questions that can be quickly
>      answered by a simple figure (numbers of multicast PEs, of multicast
>      VPNs,...), and the second one is made of qualitative questions
>      regarding the expected use of the service (features, dynamicity,
>      client application use case patterns...).
>
>      In the last part you can express more in detail considerations you
>      may have about multicast VPN deployments, including for instance
>      specific use cases you think may highlight specific important
> points.
>
>       2.1 Quantitative questions
>
>          Here, we are just expecting rough figures and orders of
> magnitude,
>          such as: 20k, tens of thousands, hundreds, O(10^2), etc.
>
>          2.1.1 Deployment and offer
>
>             1. Number of VPNs for which multicast is made available
>
>               * total:   .......
>
>               * per PE:  .......
>
>               * per AS, per provider : ......
>                (inter-AS or inter-provider context)
>
>             2. CEs per VPN per PE, for which multicast is enabled:
>
>             ..........
>
>             3. number of PEs per VPN with multicast enabled (source or
>             receiver):
>
>             ..........
>
>             4. number of PEs with multicast service enabled:
>
>             ..........
>
>          2.1.2 Parameters related to customer applications and usage
>          patterns
>
>             1. Number of PEs connected to multicast receivers:
>
>             ..........
>
>             2. Number of PEs connected to multicast sources:
>
>             ..........
>
>             3. Number of multicast (*,G) or (S,G) sourced ...
>
>               * ...per VPN:  ..........
>
>               * ...per PE:   ..........
>
>               * ...per CE:   ..........
>
>       2.2 Qualitative questions
>
>          2.2.1 Expected VPN customer applications
>
>             1. Type of multicast applications
>
>                Mutlicast applications deployed over a multicast VPN can
>                be differentiated depending on many criterias, such as,
>                for instance: real-time or not, bandwidth,
> receiver-source
>                structure (one-to-many, many-to-many, many-to-few...),
>                sensitivity to packet loss, number of streams...
>
>                Please give examples of some possible application, in
>                the form of eg.:
>
>                  o "real-time / few-to-many / tens of Mbps"
>                  o "non real time / multiple few-to-few streams / known
>                     sources, unknown receivers / hundreds of Mbps"
>
>                a) ........
>
>                b) ........
>
>                c) .........
>
>                ...
>
>             2. Dynamics
>
>               * Do you expect customer applications that are sensitive
> to
>                multicast join/latency (time to receive/leave a stream) ?
>
>                ........
>
>               * What kind of frequency do you expect for mcast routing
>                changes, at the PE level ?  (eg. "not more than XX leave
> and
>                joins per hour")
>
>                ........
>
>               * Predictability of sources and receivers locations: do
> you
>                expect to be able, for each said multicast VPN customer,
> to
>                have an a priori on the location of customer sources
> and/or
>                receivers ?
>
>                ........
>
>             3. Customer side protocols: among the following, please
>             chose which you'd expect to support at the CE-PE level
> (y/n) ?
>
>               * PIM-SM:
>               * PIM-SSM:
>               * Bidir PIM:
>               * IGMP(v2/v3):
>               * MLDv2:
>               * PIM-DM:
>
>             4. Would you plan to support multicast in a carrier's
> carrier
>             context ?
>
>             ........
>
>         2.2.1 Network Considerations
>
>             1. Do you have PE for which reachability is less good than
>             others (costly or scarce bandwidth) ?
>
>             ........
>
>             2. Do you think some VPNs of your customers may have same
>             or close sets of PEs, and may thus possibly benefit from
>             using the same PE-to-PE point to multipoint tunnels ?
>
>             ........
>
>             3. Do you plan to deploy multicast VPNs in a multi-AS
>             context ?
>
>             ........
>
>             4. Do you plan to deploy multicast VPNs in a multi-provider
>             context ?
>
>             ........
>
>         2.2.1 Relative Importance on different aspects
>
>             Please rate the following items according to their relative
>             importance - from 1 (Unimportant) to 5 (Important).
>
>             * Seem-less interoperability with the current unicast
> model: ...
>
>             * Multicast VPN must not impose additional
>              requirements on CE devices: ...
>
>             * Re-use of existing multicast protocols for multcast
> traffic
>               transport over the provider core network: ...
>
>             * Support of TE features such as bandwidth reservation and
>               admission control: ...
>
>             * Provide the same level of security for both the customer
> and
>              the SP as available with unicast VPNs: ...
>
>             * Support for global Internet multicast
> (emission/reception): ...
>
>             * Support for Extranet (having a VRF in more than one
>               multicast VPN): ...
>
>    3. Specific considerations you may want to express
>
>    ...........
>
>
> Thank you very much !
>
>
>

--
== Thomas MORIN - France Telecom R&D CORE-CPN
== Tel.: +33(0) 2 96 05 37 34 - www.francetelecom.com/rd
--
--=-rQUpZ2Vp4X/yWqv5gD0D-- From pusateri@bangj.com Fri Nov 11 15:47:33 2005 Return-Path: X-Original-To: pim-state@mountain2sea.com Delivered-To: pim-state@mountain2sea.com Received: from jj.bangj.com (jj.bangj.com [198.86.89.5]) by rock.mountain2sea.com (Postfix) with ESMTP id C8F992281B for ; Fri, 11 Nov 2005 15:47:33 -0500 (EST) Received: from jj.bangj.com (localhost.bangj.com [127.0.0.1]) by jj.bangj.com (Postfix) with ESMTP id 48A54B82F; Fri, 11 Nov 2005 15:48:16 -0500 (EST) To: pim-state@mountain2sea.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18558.1131742096.1@jj.bangj.com> Date: Fri, 11 Nov 2005 15:48:16 -0500 From: Tom Pusateri Message-Id: <20051111204816.48A54B82F@jj.bangj.com> Cc: pim@ietf.org Subject: [Pim-state] pim-state mailing list shutting down X-BeenThere: pim-state@mountain2sea.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: "IETF PIM state refresh reduction list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 20:47:34 -0000 The pim-state mailing list was created for a small design team to work on pim state refresh reductions. That team now needs more input from the PIM working group and L3VPN working group. To encourage this and allow others to stay in touch with the continued effort, I have decided to close down the pim-state mailing list and move all of its traffic over to the main pim@ietf.org list. All further discussion about the PIM State Refresh should take place on the PIM mailing list (pim@ietf.org). The archives will remain available for a long while in case anyone wants to peruse them. They can be found at: http://www.mountain2sea.com/pipermail/pim-state/ Thanks, Tom