David (document shepherd), Jari, all,
In can answer to the technical questions, but before that let
position this discussion in its context in the overall process
(softwire should follow the ietf process). Below a reminder of the
main steps for the adoption of this document:
o First of all, this document is the proprietary of the working group
and should reflect the consensus of the working group not the
opinions of the authors neither the chairs.
o The working group reached a consensus on the version, available at
http://tools.ietf.org/html/
draft-ietf-softwire-ds-lite-tunnel-option-03. During the last
call I didn't remember comments about the name option.
o Dave Ward who is the document shepherd mentioned the following in
his note (available on the tracker):
(1) "We saw evidence of extensive review on the mailing list.
The documents has been presented in softwires, v6ops, and dhc
working groups."
(2) "the document has strong support in the WG."
(3) "This is strictly a protocol specification. We believe
that an operational document discussing some of the various
tradeoffs and choices when deploying DS-Lite would be
valuable."
o According to the IETF tracker, a "Go Ahead" has been received from
R. Droms on August, 5th. I understand this as Ralph has no
technical issue with the content of the document.
o According to the IETF tracker, Jari raised the following comment:
"This document is ready to move forward. However, there is one
issue that I would like to briefly discuss before recommending
the final approval of the RFC. We have been pushing back in
other cases when people defined both FQDN and IP address
information for the same configuration item in DHCP. Why are
two options and configuration mechanisms absolutely necessary
in this case? Wouldn't IP-address based configuration suffice?
"
o The comment from Jari is valid and the document should justify why
two options are needed. This is even surprising because D.
Hankins is also the author of
http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines since
2007. This is issue in not new for him.
o The authors on their own (or with the document shepherd, I don't
know) decided to remove the name option **without** asking the
working group's opinion. No notification has been sent on the
mailing list to notify or to justify this IMPORTANT change to the
document.
At least two representatives of service providers reiterated the need
of the name option for high availability and load balancing reasons.
We can provide Jari with more details if required. Since the authors
already maintained the IP address I believe they have strong
arguments to maintain also the IP address option.
The question should whether this feedback solves the issue raised by
Jari during the IESG review.
Jari, do you need more justification?
Cheers,
Med
-----Message d'origine-----
De : [email protected] [mailto:[email protected]] De la part
de Alain Durand
Envoyé : jeudi 14 octobre 2010 18:59
À : Softwires list
Cc : Ralph Droms
Objet : Re: [Softwires] DHCP option for DS-lite
I went back to the other thread on this topic "DHCPv6 AFTR name option is
needed".
The only technical argument brought forward is that some ISPs would like to use
a level of indirection via DNS
to achieve load balancing (where the DNS has some form of measurement of the
current load of the system).
They point at VoIP for a precedent in that space.
I would like to offer several remarks:
1) In the current DS-Lite model, the B4 element would only find out the tunnel
end-point at config (boot) time.
There is no provision in the spec to regularly refresh this information.
This means that whatever is configured
is going to stay that way for possibly a very long time.
2) It is unclear that the load information that the DNS was using at the time
of the AAAA resolution is a good indicator of what the load will be hours
or days later.
3) Thus, it is unclear that such a system provide any better load distribution
that a simple round-robin
that can trivially be implemented in a DHCP server
4) If one follows that logic, the DNS redirection just add a round trip time
for no benefits.
5) The analogy with VoIP does not hold here because the VoIP client can do the
AAAA query
just before placing a call. The load information coming from the DNS has a
better chance of being accurate for the next few minutes.
I would like to invite the proponents of the DNS indirection to provide
technical arguments as why the above remarks are incorrect.
- Alain.
On Oct 12, 2010, at 12:00 PM, Alain Durand wrote:
> Dear wg:
>
> draft-ietf-softwire-ds-lite-tunnel-option<mailto:[email protected]>
> has been reviewed by the IESG with input from the dhc wg. Their conclusion
> was that having both an IP option and an FQDN option
> to describe the tunnel-end-point was redundant. After many discussion between
> the IESG and the authors, the authors decided to remove the FQDN option,
> leaving only
> the IP address option in place.
>
> The rationale is that the B4 element should remain as simple as possible and
> presenting multiple tunnel-end point alternative would seriously complicate
> the implementation on the client side. For example, the client would have to
> keep track which end-point is currently the best alternative and we would
> have to develop
> a complex mechanism to do that. Load balancing is better achieve by the DHCP
> server sending the proper tunnel end-point to the B4 element. There are cases
> where
> more complex B4 elements could benefits from having multiple tunnel endpoint
> to choose from, but those are not expected to be the common case and they
> should
> be dealt with differently.
>
> Our AD, Ralph Droms, asked us to verify there is consensus in the wg to do
> this.
>
>> David, Alain - The authors made a significant change to
>> draft-ietf-softwire-ds-lite-tunnel-option, deleting the FQDN option based on
>> IESG review and input from the dhc WG. The -05 rev is getting de facto >
>> review now, but you'll need to determine WG consensus for the changes in the
>> -05 rev.
>>
>> - Ralph
>
> If you have a strong opinion that the decision of the authors is the wrong
> one, please speak up now. This window for comments will end in 7 days, on
> 10/19.
>
> - Alain.
> _______________________________________________
> Softwires mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
*********************************
This message and any attachments (the "message") are confidential and intended
solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, changed or
falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender.
********************************
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
