Re: [v6ops] FW: latest copy of rfc6204bis included

[Wuyts Carl <[e-mail]>]

+1, we've finally come to a stage to be able to roll-out a solid IPv6 residential CPE, so indeed some extra corrections to this RFC seems unavoidable.


Carl Wuyts
GCD System Architect Networking
CONNECT DIVISION
[e-mail]
tel.: [phone]


Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium
Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpen

Help preserve the color of our world - Think before you print.





-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Victor Kuarsingh
Sent: woensdag 16 november 2011 3:22
To: Brzozowski, John; Hemant Singh (shemant); [e-mail]
Cc: W. Mark Townsley
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included

I will need to concur with John here.

Ignoring real world problems is a mistake.  It has taken considerable effort for key operators to move IPv6 programs forward.  Having these programs hampered by avoidable issues risks both those deployments from moving forward (bad for all of us), and may dampen others from starting and moving forward.

IPv6 needs to go in.. And it needs to work well.  If we cannot attain this, and have operational issues related to this it just puts undue pressure operators in the forefront.

Regards,

Victor K



On 11-11-16 10:17 AM, "Brzozowski, John"
<[e-mail]> wrote:

>Mistakes with RFC6204 were made from the earliest versions, there is no 
>harm admitting where mistakes were made.  In fact, this is healthy to 
>ensure we do not make them again.
>
>The DHCPv6 client problem is a mistake in RFC6204 and my concern is 
>that we are/were actively discussing allow it to live on in BIS.
>
>Ignoring real world experience and feedback is not part of this process 
>last time I checked.
>
>John
>=========================================
>John Jason Brzozowski
>Comcast Cable
>e) mailto:[e-mail]
>o) 609-377-6594
>m) 484-962-0060
>w) http://www.comcast6.net
>=========================================
>
>
>
>
>On 11/16/11 10:06 AM, "Hemant Singh (shemant)" <[e-mail]> wrote:
>
>>Re: latest copy of rfc6204bis includedMark,
>> 
>>We should stop harking at rfc6204 that the document made quite a few 
>>mistake.  Doesn¹t fly ­ the delta between rfc6204 and rfc6204bis that 
>>is not transition tech is minor tweaks.  The DHCPv6 server storm 
>>problem raised recently by Comcast is a not any mistake in RFC 6204.  
>>What can an
>>IPv6 CE router document do changing the DHC or the ND protocols?
>>Further, I, Wes Beebee and Ole have already said several times the M 
>>and the O bits in the RA just can¹t be used to signal start/stop to a 
>>DHCv6 client.  See use case below.
>> 
>>Also, at the last IETF it was v6ops who told us to fasttrack 
>>transition tech in rfc6204bis and ship a new copy out ASAP.  So why 
>>are we thrashing at this IETF for this goal?
>> 
>>Further, the rfc6204bis  document is already good for 6rd sunsetting, 
>>so what specifically do we need from your new draft?  You new draft is also
>>in conflict with rfc6204bis.   Your document includes the text below
>>shown between squared braces.
>> 
>>[A 6rd CE MUST assign a forwarding metric such that native IPv6egress 
>>is preferred for traffic outside the 6rd domain when 6rd and native 
>>IPv6 interfaces are active.]
>> 
>>Sunsetting 6rd involves concurrent operation of 6rd and native IPv6.  
>>In such an operation the switching in the IPv6 CE router is source-based
>>routing while your text above speaks of destination based routing.   Our
>>document says
>> 
>>[5.  Selection of 6rd tunnel or native IPv6 output interface on the CE  
>>router is determined by the source IPv6 address of the packet
>>     from a host.]
>> 
>>Hemant
>> 
>>From: [e-mail] [mailto:[e-mail]] On Behalf 
>>Of Hemant Singh (shemant)
>>Sent: Wednesday, November 16, 2011 8:32 AM
>>To: [e-mail]
>>Subject: [v6ops] FW: latest copy of rfc6204bis included
>>
>>
>> 
>>For anyone who thinks the IPv6 ND RA¹s M or the O bits can signal 
>>start/stop DHCPv6 to a client, please see this email from our IPv6 CE 
>>router design team discussion.  It¹s is bad idea.
>> 
>>Hemant
>> 
>>From: Wes Beebee (wbeebee)
>>Sent: Wednesday, November 09, 2011 3:19 AM
>>To: Lorenzo Colitti; Hemant Singh (shemant)
>>Cc: Wojciech Dec (wdec); [e-mail]; Erik Kline; 
>>John Jason Brzozowski
>>Subject: Re: latest copy of rfc6204bis included
>>
>>
>> 
>>Lorenzo -
>>
>>>> I don't see any text that requires the CE router not to do DHCPv6 
>>>>PD if M=0  and O=0. Where is it?
>>
>>The reason you do not see such text is that we don¹t want to introduce 
>>anything deliberately in RFC 6204bis that will explicitly break in the 
>>multi-homing case.  Even though it¹s ³out of scope² - we don¹t want to 
>>invalidate the whole document when it becomes ³in scope².
>>
>>For example, imagine a case where a home router is connected to a hub 
>>and to two modems which go to two different service providers.  One 
>>provider sets M=O=0 and the other provider sets M=O=1.  If setting 
>>M=O=0 turns off
>>DHCPv6 and M=O=1 triggers a reinitialization, then imagine the case 
>>where each service provider sets the RA interval to 1 second and the 
>>RA¹s come in alternating every 0.5 second.  In that case, the CE 
>>router will be re-doing DHCPv6 every second and will create a DHCPv6 
>>storm for the service provider.
>>
>>That¹s why we explicitly don¹t re-trigger or turn off/on DHCPv6 based 
>>on some trigger.  All that we say is that in the case of M=O=1, the CE 
>>router MUST do DHCPv6 by default.  That¹s all that needs to be said, 
>>and that¹s all that can be said.
>>
>>- Wes
>>
>>_______________________________________________
>>v6ops mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/v6ops
>
>_______________________________________________
>v6ops mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/v6ops


_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops