Subject: [shara] SHARA preliminary agenda posted

From: "Dan Wing" <[email-masked]>
Date: Thu, 5 Nov 2009 10:18:11 -0800

This is still subject to change, as Christian is traveling, but I believe this
is close to our agenda for the APLUSP BoF,

  http://www.ietf.org/proceedings/09nov/agenda/aplusp.html

-d

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 5 Nov 2009 13:30:24 -0500

Hi Dan,

There doesn't seem to be an A+P document on the agenda...

When we talk about A+P, are we specifically discussing http://www.ietf.org/id/draft-ymbk-aplusp-05.txt?

Thanks,
Margaret

On Nov 5, 2009, at 1:18 PM, Dan Wing wrote:

> _______________________________________________
> shara mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/shara

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 5 Nov 2009 10:58:44 -0800

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]] 
> Sent: Thursday, November 05, 2009 10:30 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [shara] SHARA preliminary agenda posted
> 
> 
> Hi Dan,
> 
> When we talk about A+P, are we specifically discussing 
> http://www.ietf.org/id/draft-ymbk-aplusp-05.txt?

No, by "A+P" we are generalizing to include solutions that
provide TCP/UDP ports to a subscriber, including so far:

  A+P, draft-ymbk-aplusp
  Port Range, draft-boucadair-port-range
  Port Range + IPv6, draft-boucadair-behave-ipv6-portrange
  SAM, draft-despres-softwire-mesh-sam
  Dual IVI, draft-xli-behave-divi

Pierre Levis's presentation provides a high level overview 
of A+P without going into the differences of those I-Ds 
on the wire.

-d

---

From: Randy Bush <[email-masked]>
Date: Thu, 05 Nov 2009 13:29:43 -0600

>   Dual IVI, draft-xli-behave-divi

i guess you don't need the nokia drafts at the france telecom bof

randy

---

From: mkarir <[email-masked]>
Date: Thu, 5 Nov 2009 16:21:40 -0500

Hi Dan,

Though we wont be able to make it to the BoF in Hiroshima, I thought  
we would let folks
know about our L2 based approach to implementing port sharing.
Both the paper description as well as working code are at:

http://software.merit.edu/pe-arp/

We recently also presented our work at the NANOG meeting:

http://www.nanog.org/meetings/nanog47/presentations/Tuesday/Karir_pearp_N47_Tues.pdf

We do not have an IETF draft yet, but expect to have one ready for the  
next IETF mtg.

-manish

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 5 Nov 2009 17:24:10 -0500

Hi Manish,

I read the white paper available on the website. Section V mentions that A+P
requires NAT-like middle device but PE-ARP does not. I am not 100% following
this statement. The reason why A+P proposes to implement the feature in a
NAT box is to make sure all the existing applications which use random
source ports can continue to function. This is not a requirement one must
use A+P NAT. In A+P host model, the host can be given a port-range and
initiate sessions without using any middle device. The host model will
require the OS to understand A+P.

A+P does require its upstream router (Port-Range Router) aware of
port-range. In PE-ARP, this is similar. There must be a middle device
(PE-ARP Enabled Router) that implements the PE-ARP so that the it can send
the PE-ARP request.

In the end, I see A+P and PE-ARP share the same concept but implement it in
different layer.

Cheers,
Yiu

---

From: Randy Bush <[email-masked]>
Date: Thu, 05 Nov 2009 16:27:54 -0600

> port-range.

exactly, and only that.  collusion with a mid-isp nat is only in the
ds-lite transition application.

randy

---

From: Ralph Droms <[email-masked]>
Date: Fri, 6 Nov 2009 09:42:03 +0800

Randy - I'm confused.  Is draft-ymbk-aplusp-05.txt one of the "nokia  
drafts"?

- Ralph

---

From: Randy Bush <[email-masked]>
Date: Thu, 05 Nov 2009 21:40:08 -0600

> Randy - I'm confused.  Is draft-ymbk-aplusp-05.txt one of the "nokia  

a+p was independently and simultaneously invented by nokia and our gang
(smb, olaf, luca, ...).  you will see that nokia is listed as co-authors
of current a+p draft.  they have a very different application of a+p
than ds-lite/softwires.

we reached a reasonable accord with alain, nokia, ...

the iesg/iab players have not even bothered to do their homework.  e.g.
limiting the bof to the ds-lite application, which completely leaves out
the nokia mode of use and many others.  therefore, it then becomes
unclear why this ds-lite discussion is not in softwires, as i said a
month or more ago when the st00pid ds-lite limit was announced.

randy

---

From: Ralph Droms <[email-masked]>
Date: Fri, 6 Nov 2009 15:08:24 +0800

Randy - you wrote:

To respond to that statement, I need to know what the nokia drafts  
are.  I asked you a while ago which drafts are the nokia drafts and  
this time I asked if draft-ymbk-aplusp-05.txt is one of the nokia  
drafts.  In neither case did you give me an answer I can translate  
into being able to identify the nokia drafts you referred to up  
above.  So, that's OK, I'll resign myself to remaining in the dark  
about your comment.

I also wasn't able to identify the Nokia mode of use from the A+P  
documents I read, so I don't know what you're concerned about us  
ruling out of scope for the BOF.  Because of concerns about the impact  
of A+P on hosts, on processing other protocols, on fragmentation and  
on the deployment of IPv6, I decided it made the most sense to discuss  
A+P in the context of an IGD using DS-lite.  Perhaps that constraint  
could be generalized to other IPv6-transport softwires.

However, A+P remains a function distinct from DS-lite, and at least  
deserves review in its own BOF.  I think there is significant work to  
do to get the details right, so my current opinion is that A+P needs  
its own WG.

- Ralph

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 5 Nov 2009 23:30:18 -0800

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of mkarir
> Sent: Thursday, November 05, 2009 1:22 PM
> To: [email-masked]
> We do not have an IETF draft yet, but expect to have one 
> ready for the next IETF mtg.

Interesting, thanks for forwarding.

Slide 6, "DNS Support for Service Location" talks about
enhancing DNS to do port lookups.  You might look at
http://tools.ietf.org/html/draft-jennings-http-srv which
proposes a new URI scheme "http+srv:"

-d

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 6 Nov 2009 00:03:51 -0800

Hello Dan,

>   Dual IVI, draft-xli-behave-divi

How about the RSIP [1,2,3,4] protocol?

[1] RFC 3102 (rfc3102) - Realm Specific IP: Framework
    http://tools.ietf.org/html/rfc3102
[2] RFC 3103 - Realm Specific IP: Protocol Specification
    http://tools.ietf.org/html/rfc3103
[3] RFC 3104 - RSIP Support for End-to-end IPsec
    http://tools.ietf.org/html/rfc3104
[4] RFC 3105 (rfc3105) - Finding an RSIP Server with SLP
    http://tools.ietf.org/html/rfc3105

--julien

---

From: Randy Bush <[email-masked]>
Date: Fri, 06 Nov 2009 04:25:57 -0600

> are.

the one referenced in a+p draft is draft-bajko-pripaddrassign-01.txt

> ruling out of scope for the BOF. 

again, from the a+p draft

4.2.  A+P for Mobile Providers

   In the case of mobile service provider the situation is slightly
   different.  The A+P border is assumed to be the gateway (e.g., GGSN/
   PDN GW of 3GPP, or ASN GW of WiMAX).  The need to extend the address
   is not within the provider network, but on the edge between the
   mobile phone devices and the gateway.  While desirable, IPv6
   connectivity may or may not be provided.

   ...

> deserves review in its own BOF.

then why did the iesg/iab say the bof was limited to the ds-lite
application?

randy

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 7 Nov 2009 13:44:33 -0800

> From: Laganier, Julien [mailto:[email-masked]] 
> Sent: Friday, November 06, 2009 12:04 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: RE: [shara] SHARA preliminary agenda posted
> 
> Hello Dan,
> 
> > > Hi Dan,
> > >

RSIP essentially borrows an IPv4 address from another network.  A+P isn't
doing that; it is using IPv4 addresses from the same access network as usual,
but instead of giving every host full use of an IPv4 address (any protocol,
all ports), it restricts the use to UDP, TCP, and ICMP, and a certain range of
UDP and TCP ports.  A+P doesn't borrow IPv4 addressees (or addresses and
ports) from far-away network domains.  Of course with tunneling such a thing
could be achieved with A+P - controlled only by where an A+P tunnel is
terminated.

-d

---

From: Ralph Droms <[email-masked]>
Date: Sun, 8 Nov 2009 12:58:57 +0900

> the one referenced in a+p draft is draft-bajko-pripaddrassign-01.txt

OK, thanks.

>   connectivity may or may not be provided.

That last sentence - which I think is in conflict with constraint 10  
in section 2.1 - is why I'm concerned about this scenario.  It has the  
potential to provide more support to the continued use of IPv4 than is  
desirable.

> then why did the iesg/iab say the bof was limited to the ds-lite

I'm willing to consider an extension to other tunnel/IPv6  
deployments.  But the basic technology needs  the development of  
details, as I expect we'll discuss in the BoF, that are unrelated to  
the specific tunneling technology.

- Ralph

---

From: mkarir <[email-masked]>
Date: Thu, 12 Nov 2009 11:32:09 -0500

Hi Yiu,

Sorry for the delayed response.  I think the earlier A+P draft that we  
read was not clear on this issue.
Yes I agree that A+P does not require NAT if host only mode is used,  
but as you said, that is
just one mode of operation and other modes of operation do require NAT.

The difference I believe is that in host mode A+P uses a tunnel to get  
packets to the right
end-host from the PRR, while PE-ARP uses ARP or some other hardware  
address resolution protocol
to get the packets to the right end host.  In our view PE-ARP  
addresses the problem at the right
layer, but then again we are biased on this :)

-manish

> From: "Lee, Yiu" <[email-masked]>
> Date: November 5, 2009 5:24:10 PM EST
> To: "mkarir" <[email-masked]>, <[email-masked]>
> I read the white paper available on the website. Section V mentions  
> that A+P requires NAT-like middle device but PE-ARP does not. I am  
> not 100% following this statement. The reason why A+P proposes to  
> implement the feature in a NAT box is to make sure all the existing  
> applications which use random source ports can continue to function.  
> This is not a requirement one must use A+P NAT. In A+P host model,  
> the host can be given a port-range and initiate sessions without  
> using any middle device. The host model will require the OS to  
> understand A+P.
>
> port-range. In PE-ARP, this is similar. There must be a middle  
> device (PE-ARP Enabled Router) that implements the PE-ARP so that  
> the it can send the PE-ARP request.
>
> In the end, I see A+P and PE-ARP share the same concept but  
> implement it in different layer.
>
> Cheers,
> Yiu
>
>