Re: [shara] Summary and outcomes from aplusp BoF at IETF 76

[<[e-mail]>]

Dear Ralph,

Thank you for your answers but I still have some objections.

Please see in line.


-----Message d'origine-----
De : Ralph Droms [mailto:[e-mail]] 
Envoyé : mercredi 9 décembre 2009 15:29
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [e-mail]; IESG IESG; Softwire Chairs
Objet : Re: [shara] Summary and outcomes from aplusp BoF at IETF 76

Responses in line...

On Dec 7, 2009, at 9:04 AM 12/7/09, <[e-mail] 
 > <[e-mail]> wrote:

> Dear Ralph,
>
> You mentioned that "a+p has too many side effects, not all of which  
> are known at this
>   point, to be a useful mechanism to meet that need."
>
> - Could you enumerate these "too many side effects"? BTW, It is  
> strange to have an objection to work an A+P because "not all of  
> which are known at this
>   point"?!

Let me clarify.  Dave Thaler's presentation pointed out enough side  
effects specific to A+P to lead to the conclusion.  I assume other  
side effects would be discovered in the course of developing an a+p  
specification.

Med: I'm afraid to disagree here since D. Thaler's presentation is mostly a collection of issues which are not specific to
A+P (Please refer to http://www.ietf.org/mail-archive/web/shara/current/msg00196.html).
Particularly, the "Long-term impact" slide from D. Thaler prezo is not so that true since the proposed A+P solutions allow a smooth migration
to IPv6 while solving the IPv4 address exhaustion. 
- A+P solutions encourage the deployment of IPv6 in local domain without requiring universal agreement
to move to IPv6 since interconnection functions at the boundaries are stateless. 
- A+P allows also to shorten the lifetime of the dual-stack plans in
the network and only IPv6 is required for the delivery of IPv4 and IPv6 connectivity services. 
- Services are not broken since we don't need any ALG to be deployed in the core network. 
- A+P is not a hurdle for the introduction of new services since there is no need to update intermediary nodes (such as CGNs). 
- A+P does not need any state synchronisation for robustness reasons since now per-flow data is maintained in intermediary nodes.
- A+P allows to offer subscriber-hosted services with current practices. No need to define new protocols (some modifications
are required to avoid port conflict)
- Already defined tools and techniques (e.g., URL, SRV records, redirection, etc.) allows to specify a port number in the host part
- Etc.


> - Are these issues specific to A+P?
> - Should we do the same exercise for other forms of shared address  
> schemes?
> - Should we understand that the underlying message from the IESG is  
> to go for a CGN-based solution? Quid of maintaining ALGs, service  
> brokenness, lawful data storage, robustness, etc.? If CGN are  
> massively deployed, what will be the motivation to move to IPv6?  
> Again: what is the exit strategy proposed by the IESG. I'm afraid to  
> say that DS is not a viable one!

There is no silver bullet to be found anywhere.  We have some  
solutions, which we need to deploy as judiciously as possible while we  
move the Internet to IPv6.  The existing interim technologies have  
known problems; I interpret the response in the BoF to indicate that a 
+p is not considered to be less problematic or otherwise advantageous  
relative to the existing technologies.

Med: I wasn't in the BoF, but reading the mail from M. Wasserman makes me think that there was something "wrong"
(http://www.ietf.org/mail-archive/web/shara/current/msg00195.html).
So, why not give us a second chance to better explain the problem we are targeting and explain the rationale of the solutions we are proposing?


> You mentioned "I will
> ask the softwire WG to consider the issue of inbound connections to
> subscriber-provided services as part of their work on DS-lite. "
>
> - Does it mean that only port forwarding policies and configuration  
> of static mappings in the AFTR (BTW, the AFTR terminology is  
> misleading since the ds-lite CGN is not an AF translator) will be in  
> scope?

If I understand your question correctly, yes, I will ask the softwire  
WG to develop control mechanisms for forwarding in the AFTR.

> - Does it mean that A+P features MAY be supported in B4 and AFTR? Or  
> a+p is explicitly out of scope of the solution candidates to solve  
> "connections to
> subscriber-provided services"?

a+p is out of scope for the softwire WG and no work is chartered  
elsewhere.

> Cheers,
> Med

- Ralph


>
> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]] De la  
> part de Ralph Droms
> Envoyé : vendredi 4 décembre 2009 17:59
> À : [e-mail]
> Cc : IESG IESG; Softwire Chairs
> Objet : [shara] Summary and outcomes from aplusp BoF at IETF 76
>
> Thanks to Dan and Christian for chairing the BoF and to everyone who
> participated.  I especially thank the participants for staying on
> topic and having a constructive and useful discussion of the issues
> during the BoF.
>
> There were a couple of aspects of the BoF that I wish I had handled
> better.  In particular, I didn't intend to exclude any of the
> proponents of the various a+p proposals related to dual-stack lite
> (DS-lite) and, in retrospect, we could have done a better job with the
> initial formulation of the questions asked at the end of the BoF.
> I'll reiterate that I think the chairs did a great job with the BoF,
> considering the history and context of the topic, and the shortcomings
> of the BoF are really my responsibility.
>
> However, I think that this BoF, considered with the outcome of the
> previous shara BoF, came to a couple of useful conclusions:
>
> * there is a need to provide inbound connections to
>   subscriber-provided services, and
>
> * a+p has too many side effects, not all of which are known at this
>   point, to be a useful mechanism to meet that need.
>
> Comments on these conclusions is encouraged...
>
> Considering this outcome, no work on a+p will be chartered.  I will
> ask the softwire WG to consider the issue of inbound connections to
> subscriber-provided services as part of their work on DS-lite.  Other
> working groups may take on development of techniques for providing
> inbound connections in other technologies and scenarios.
>
> - Ralph
>
> _______________________________________________
> shara mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/shara
>
> *********************************
> 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.
> ********************************
>


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