Nimrod for IPv6?

2010-08-18 Thread Fernando Gont
Hi, folks, Routing Header Type 1, and option 0x8a (Endpoint Identification), are related to the Nimrod routing system. Has Nimrod for IPv6 ever been specified? If so, has there ever been any deployments? Put another way: should one expect to find occurrences of RHT1 and/or option 0x8a? Thanks!

RE: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt

2010-08-18 Thread Alan Kavanagh
Hi Ole I believe its also true in that the host tx the RS and Edge node then responds with the RA as oppose to the Edge node txing the RA. This is really a BBF issue on how the BNG operates and should be taken up in BBF. Alan -Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6

Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt

2010-08-18 Thread Ole Troan
Suresh, >> that wasn't quite the question I asked. DHCPv6 has a well defined mechanism >> to periodically retry, while RS client sending simply timeout. This would >> seemingly leave such clients in the proposed scheme with no connectivity. > > I do see your problem, but that problem is common

Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt

2010-08-18 Thread Suresh Krishnan
Hi Woj, On 10-08-18 11:01 AM, Wojciech Dec wrote: Hi Alan, that wasn't quite the question I asked. DHCPv6 has a well defined mechanism to periodically retry, while RS client sending simply timeout. This would seemingly leave such clients in the proposed scheme with no connectivity. I do se

Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt

2010-08-18 Thread Ole Troan
> Its the same issue for DHCPv6, if the client dont send a DHCP_Solicit you > dont get an address. Also, the RS similar to the DHCP_Solicit is used to > "kick_start" the IP Sub session and as you know there are lots of hosts whom > dont have a DHCPv6 client and will not have a DHCPv6 client. >

Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt

2010-08-18 Thread Wojciech Dec
Hi Alan, that wasn't quite the question I asked. DHCPv6 has a well defined mechanism to periodically retry, while RS client sending simply timeout. This would seemingly leave such clients in the proposed scheme with no connectivity. -Woj. On 18 August 2010 16:51, Alan Kavanagh wrote: > Hi Woj

RE: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt

2010-08-18 Thread Alan Kavanagh
Hi Woj Its the same issue for DHCPv6, if the client dont send a DHCP_Solicit you dont get an address. Also, the RS similar to the DHCP_Solicit is used to "kick_start" the IP Sub session and as you know there are lots of hosts whom dont have a DHCPv6 client and will not have a DHCPv6 client. Th

Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt

2010-08-18 Thread Wojciech Dec
Hi Suresh, thanks for your reply. Continued inline... On 18 August 2010 16:03, Suresh Krishnan wrote: > Hi Woj, > Thanks for your comments. > > > On 10-08-18 07:11 AM, Wojciech Dec wrote: > >> Hi, >> >> I have a question or two to the draft authors who can hopefully clarify >> the expected cont

Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt

2010-08-18 Thread Suresh Krishnan
Hi Woj, Thanks for your comments. On 10-08-18 07:11 AM, Wojciech Dec wrote: Hi, I have a question or two to the draft authors who can hopefully clarify the expected context and working of this scheme, which at the moment is a bit unclear. In essence the problem this draft appears to be tryi

Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt

2010-08-18 Thread Wojciech Dec
Hi, I have a question or two to the draft authors who can hopefully clarify the expected context and working of this scheme, which at the moment is a bit unclear. In essence the problem this draft appears to be trying to solve is using RS/RA messages to induce state into intermediate or IP edge de

Re: draft-ietf-ipngwg-p2p-pingpong-00.txt vs RFC4443

2010-08-18 Thread Mark Smith
On Tue, 17 Aug 2010 11:20:56 +0300 (EEST) Pekka Savola wrote: > Hi, > > I changed the subject, because the original intent was lost in the > weeds. > > On Mon, 16 Aug 2010, Olivier Vautrin wrote: > > It is clear that there is one more action done on the packet with > > RFC4443. But this has n