Nabble - IETF - Softwires

Note to presenters

2008-11-19T20:39:04Z

We have not received all your slides. Please do so asap so we can upload
them on the web.

- Alain.

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

IETF73 agenda

2008-11-16T07:17:51Z

I've updated the agenda.

Note to presenters: the agenda is pretty full, please keep your
presentations short, attendees are supposed to have read the drafts. No more
than 10-15min for each presentation. Also, please sent David & I your slides
NO LATER THAN WEDNESDAY so we have a chance to post them.

- Alain.

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

Re: Drafts on Agenda?

2008-11-14T12:35:16Z

Margaret,

I've updated the agenda on the web to point to the documents to be
discussed.

- Alain.

On 11/14/08 3:00 PM, "Margaret Wasserman" <mrw@...> wrote:

> The softwires agenda for MN says:
>
> - administrativia
> - Composite Transport Groups (Verizon)
> - DS-lite draft (Alain)
> - port restricted IPv4 addresses (Gabor)
> - SAM (Remy)
> - A+P (Randy)
> - NAT-PMP proxy (James W.)
> - synthesis, open issues & moving forward (Alain)
>
> Could you send a list of drafts that would be discussed? I'm
> particularly interested in pointers to Verizon, Gabor and James W.
> drafts, as I am not sure which drafts those are referring to... But,
> it might be good to send the whole list in case others are having
> trouble finding different drafts.
>
> Thanks,
> Margaret
>
> _______________________________________________
> Softwires mailing list
> Softwires@...
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

Drafts on Agenda?

2008-11-14T12:00:29Z

The softwires agenda for MN says:

- administrativia
- Composite Transport Groups (Verizon)
- DS-lite draft (Alain)
- port restricted IPv4 addresses (Gabor)
- SAM (Remy)
- A+P (Randy)
- NAT-PMP proxy (James W.)
- synthesis, open issues & moving forward (Alain)

Could you send a list of drafts that would be discussed? I'm
particularly interested in pointers to Verizon, Gabor and James W.
drafts, as I am not sure which drafts those are referring to... But,
it might be good to send the whole list in case others are having
trouble finding different drafts.

Thanks,
Margaret

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

Re: [BEHAVE] v4v6 coexistence reading list for IETF73

2008-11-13T00:39:03Z

Ed Jankiewicz (1-12/1-31/200x) 11/13/08 12:01 AM:

more for my own purposes reading through the alternative drafts, however this may be of use to those interested in current work in IPv4-IPv6 coexistence tools. The work is going on in 3 working groups and some drafts will be on on each agenda (some I am guessing will be) are in bold. There will also be some general discussion in the intarea meeting. The drafts in italic may be obsolete, either merged into other work or dropped. And don't forget the paper presented by Randy Bush on Address Plus Port <https://mice.cs.columbia.edu/getTechreport.php?techreportID=560> that may become a draft.

I did not include some related work on tunneling, that maybe should be.
Please comment if I have missed any drafts, or mis-characterized any of these as to WG, status or category. Or any other suggestions to make it more useful.

Thanks for the list, and the opportunity to update it.

1) Draft-despres-sam-scenarios is now obsolete

2) The right document on SAM is draft-despres-sam-01
- Its sections on Problem Statement and SAM Specification are IMO very relevant.
- Its section on Application Examples is unfortunately still seriously bugged (rather than going through the details, waiting for the slides under preparation is advisable).

o Port-range and privacy-protection aspects or the draft are planned for presentation in Behave
o Address-mapping and encapsulation aspects are expected to be planned for presentation in Softwire.

Regards,
RD

v6ops WG



Behave WG



Softwires WG



Other or unspecified WG

Framework, scenarios, comparison





*Draft-baker-behave-v4v6-framework*





Draft-arkko-townsley-coexistence



Draft-wing-nat-pt-replacement-comparison



Draft-despres-sam-scenarios

Problem Statements, requirements



*Draft-ietf-v6ops-nat64-pb-statement-req*



Draft-miyata-behave-prefix64







Draft-jennings-behave-nat6











Solutions



/Draft-despres-v6ops-apbp/



*draft-baker-behave-v4v6-translation*



*Draft-durand-softwire-dual-stack-lite*



Draft-despres-sam



*draft-bagnulo-behave-dns64*







*draft-bagnulo-behave-nat64*







Draft-baker-behave-ivi
/Draft-xli-behave-ivi/







*draft-vogt-durand-virtual-ip6-connectivity*





“helpers”





*Draft-denis-behave-v4v6exthdr*





Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch
732-389-1003 or ed.jankiewicz@...
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave
  

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

Bugged examples in draft-despres-sam-01

2008-11-12T09:11:31Z

For some strange reason (but for which I am completely responsible),
application examples of draft-despres-sam-01 are seriously bugged.

Please accept my apologies.
In Minneapolis, I will have slides with correct parameter values.

A new draft will also be posted when again possible.

RD
_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

http://tools.ietf.org/id/draft-xu-idr-tunnel-00.txt

2008-11-10T07:59:47Z

This draft written by Xiaohu Xu and myself exploits the Tunnel Encapsulation
Attribute from draft-ietf-softwire-encaps-safi-03 to allow routers to
advertise themselves as tunnel endpoints for reachable NLRI across multiple
ASes. We posted it initially to IDR because it impacts inter-domain routing,
but we'd be very interested in getting comments back from softwires, and
possibly presenting it in Minn.

Thanks,

PF
_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

Dual-stack-lite-01

2008-11-07T09:20:10Z

I have finally gone through the latest revision of the ds-lite draft and
overall I think it looks good. I only have two small comments/questions:

Section 4.2 and 4.4 defines an addressing scheme for the ds-lite tunnel and
also talks about the addressing of the home network but I have a problem
understanding the reasoning behind it and the conclusion. Why does the
tunnel addresses have to be well defined while the home network doesn't have
to, or does it? Since the NAT state always will be based on the IPv6 source
address the IPv4 addresses shouldn't really matter as long as it is a 1918
address.

Section 6 seems very ambiguous and more about saying that in more complex
cases you might want to consider a different solution rather than defining
encapsulation methods. It needs more explanation and has to be a bit clearer
on what actually is expected when supporting other types encapsulation.
Right now I don't see what the benefit there would be in having multiple
encapsulation methods.

A small nit is that the terminology changes throughout the document, which I
guess is due to the merger with the snat draft. This makes it look somewhat
like two different solutions. It is mainly chapter 5 that need to be changed
to be more in line with the rest of the document.

-Mikael

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

Re: [BEHAVE] Stateless Address Mappings (SAMs) - new draft

2008-11-07T06:14:43Z

Dave,

Thanks for your detailed comments, and for the useful pointers to relevant RFCs and I-Ds.

More comments below.

Regards,

RD

Dave Thaler (1-12/1-31/200x) 11/5/08 9:47 PM:

I have read this draft.  In my opinion, it is within the scope of Softwires
but may be of interest to some Behave folks.  The only real part I can see
that might be within the scope of Behave is section 3.6 where it discusses
scrambling IPv6 addresses as packets flow through a SAM.

Yes, section 3.6 is clearly in the scope of Behave.

IMU, this is also the case for section 3.2.3 on the port-prefix based extended IPv4 addresses: it concerns "Division of port space to share one IPv4 addresses among multiple endpoints at the same time", which Magnus Westerlund announced to be in Behave's scope (e-mail attached).

  I'd suggest this
be separated into its own draft since it's largely orthogonal to the rest
of the document (which is more about encapsulation, not translation).

As this has strong relationship with Margaret's NAT66 draft, trying to regroup the contents could IMHO make sense, but to be discussed more.

Technical comments:

1) The draft doesn't say what will break and probably should (ping,
   well-known ports, etc).  Some of the same problems that occur with
   multilink subnets (RFC 4903) occur in this proposal too, since
   not everything will be aware that the "subnet" isn't an IP prefix.
   Similarly, the required Subnet-Router Anycast addresses (RFC
   4291 section 2.6.1) may not work correctly.

- With extended IPv4 addresses, pings are indeed impossible (like across NATs or any address sharing mechanism).
- I agree that a sentence on it is appropriate (I even had one at some stage, but lost it later on.)

- Whether a problem related to multilink subnets does appear with the proposal is still unclear to me.
- It seems unnecessary that "everything" be aware that a subnet IT is longer than 64 to keep the rule of only one link per subnet. Note that in 3.2.3 the mentioned prefix is that of a "subnetwork", not that of a "subnet" as defined for IPv6. Instead of "subnetwork", "local routing domain" should be better .

2) The draft assumes that the first fragment always arrives first.
   As discussed in draft-iab-ip-model-evolution-01.txt section 3.1.7,
   this is not a safe assumption today.

- I tried not to assume completely that it was that way, but I agree that the point should be developped.
- Would you have details on a real case where a provider routinely disorders packets having same source and same destination (the only case of concern here). IMU, this would be _very bad_ for many TCP implementations.

3) The use of the "u" bit in IIDs seems problematic for several reasons.
   One, it only applies to IPv6 addresses that don't start with binary 000.

Right, the next version should clarify that what is said about the "u" bit only applies to addresses that don't start with 000.

   Two, the semantics of the bit defined in RFC 4291 have to do with
   making it easy to configure non-conflicting addresses, and are not
   about privacy demands; overloading this bit for a second purpose
   seems problematic.

Right. Saying it as I did in section 3.6 is a bug. Thanks for seeing it.

Actually, the SAM privacy protection should rather be applicable only to v6E addresses. The level of privacy achieved with the SAA privacy extension of RFC 4941 would then stands for itself in global addresses.

4) Regarding the IPv6 address scrambling in section 3.6, not defining
   the scrambling (or at least not providing requirements for it) would be
   problematic in two regards.  1) If you allow asymmetric paths then
   you need the same algorithm in each SAM at the edge of your network;
   2) some implementations may pick a weak method that allows an
   outsider to guess the algorithm.

Yes, all external edge SAMs must obviously have the same scrambling method.
At least for this reason, standardizing a default scrambling is useful, I agree (coexistence of edge SAMs from different suppliers etc.)

It remains that vendors may propose, as options, whatever scrambling method they feel may be better .

Comments inline (along with a bunch of editorial nits) in PDF attached.

-Dave

-----Original Message-----
From: behave-bounces@... [behave-bounces@...] On
Behalf Of Rémi Després
Sent: Wednesday, November 05, 2008 8:46 AM
To: Softwires WG; Behave WG
Cc: v4v6interim-bounces@...
Subject: [BEHAVE] Stateless Address Mappings (SAMs) - new draft

The new draft on SAMs is at
http://www.ietf.org/internet-drafts/draft-despres-sam-01.txt.

It deal with global connectivity, in IPv4, IPv6,  and extended IPv4,
across local domains where routing is different.

- Its automatic tunneling aspects are in the new scope of Softwires
- Its IPv4 address extension aspects, based on dynamic-port prefixes,
are in the scope of Behave.

Regards
RD

_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

IETF Community,

There has been a lot of activity on the topic of improving IPv4 and IPv6
coexistence, deployment of IPv6, and coping with the increasing shortage
of unassigned IPv4 addresses. This work crosses a number of layer and
area boundaries, which has led to new lists, cross-posting, etc. In
order to limit confusion, we'd like to give some guidance on where
to discuss what on which lists. The intent is not to declare any work
as in or out of charter with this message, only to try and direct list
discussion. These are only general guidelines, so please don't be
alarmed if we missed something in particular. Our hope is that this will
help everyone to continue the rich dialog on this important topic.

1. softwires@...

Softwires is chartered to work on combinations of IPv4/IPv6 and
IPv6/IPv4, including "dual-stack lite" functionality. This includes
discussion related to:

- All types of IPv4/IPv6 tunnels, including encapsulation, control
plane, etc.
- Affects of tunnel endpoints terminating into a concentrator performing
IPv4 to IPv4 NAT
- Discovery of tunnel endpoints
- Tunnels initiated by hosts or gateways
- Tunnels automatically setup by routing and special prefixes

Thus, if it involves a tunnel or encapsulation of IPvX over IPvY,
softwires is the place to go.

2. behave@...

The Behave WG is currently being rechartered. If the new charter is
approved, behave will work on various types of IPv4<->IPv6 translation.
Please direct all discussion related to:

- IPv4 to IPv6 and IPv6 to IPv4 translation
- IPv6 to IPv6 NAT
- Division of port space to share one IPv4 addresses among multiple
endpoints at the same time
- Affects on applications and transport protocols
- ALGs
- IPv4 to IPv4 NAT functionality, including for ISP deployments

Thus, if discussion involves an IP translator or the internal function
of a NAT, behave is the place to go.

3. v6ops@...

- Operational discussions on the topic of coexistence in general
- IPv6-only deployment

Thus, if it involves operational issues of IPv6 or IPv4 exhaustion, go
to v6ops.

4. The v4v6interim@... list will be removed after the Minneapolis
IETF meeting.

Jari Arkko
Ron Bonica
Lars Eggert
Mark Townsley
Magnus Westerlund

Resources:

WGs
Behave: http://www.ietf.org/html.charters/behave-charter.html
Softwire: http://www.ietf.org/html.charters/softwire-charter.html
v6ops: http://www.ietf.org/html.charters/v6ops-charter.html

_______________________________________________
v4v6interim mailing list
v4v6interim@...
https://www.ietf.org/mailman/listinfo/v4v6interim

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

Re: [BEHAVE] Stateless Address Mappings (SAMs) - new draft

2008-11-05T12:47:37Z

I have read this draft. In my opinion, it is within the scope of Softwires
but may be of interest to some Behave folks. The only real part I can see
that might be within the scope of Behave is section 3.6 where it discusses
scrambling IPv6 addresses as packets flow through a SAM. I'd suggest this
be separated into its own draft since it's largely orthogonal to the rest
of the document (which is more about encapsulation, not translation).

Technical comments:

1) The draft doesn't say what will break and probably should (ping,
well-known ports, etc). Some of the same problems that occur with
multilink subnets (RFC 4903) occur in this proposal too, since
not everything will be aware that the "subnet" isn't an IP prefix.
Similarly, the required Subnet-Router Anycast addresses (RFC
4291 section 2.6.1) may not work correctly.

2) The draft assumes that the first fragment always arrives first.
As discussed in draft-iab-ip-model-evolution-01.txt section 3.1.7,
this is not a safe assumption today.

3) The use of the "u" bit in IIDs seems problematic for several reasons.
One, it only applies to IPv6 addresses that don't start with binary 000.
Two, the semantics of the bit defined in RFC 4291 have to do with
making it easy to configure non-conflicting addresses, and are not
about privacy demands; overloading this bit for a second purpose
seems problematic.

4) Regarding the IPv6 address scrambling in section 3.6, not defining
the scrambling (or at least not providing requirements for it) would be
problematic in two regards. 1) If you allow asymmetric paths then
you need the same algorithm in each SAM at the edge of your network;
2) some implementations may pick a weak method that allows an
outsider to guess the algorithm.

Comments inline (along with a bunch of editorial nits) in PDF attached.

-Dave

> -----Original Message-----
> From: behave-bounces@... [mailto:behave-bounces@...] On
> Behalf Of Rémi Després
> Sent: Wednesday, November 05, 2008 8:46 AM
> To: Softwires WG; Behave WG
> Cc: v4v6interim-bounces@...
> Subject: [BEHAVE] Stateless Address Mappings (SAMs) - new draft
>
> The new draft on SAMs is at
> http://www.ietf.org/internet-drafts/draft-despres-sam-01.txt.
>
> It deal with global connectivity, in IPv4, IPv6, and extended IPv4,
> across local domains where routing is different.
>
> - Its automatic tunneling aspects are in the new scope of Softwires
> - Its IPv4 address extension aspects, based on dynamic-port prefixes,
> are in the scope of Behave.
>
> Regards
> RD
>
> _______________________________________________
> Behave mailing list
> Behave@...
> https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

draft-despres-sam-01.pdf (397K) Download Attachment

Stateless Address Mappings (SAMs) - new draft

2008-11-05T08:45:31Z

The new draft on SAMs is at
http://www.ietf.org/internet-drafts/draft-despres-sam-01.txt.

It deal with global connectivity, in IPv4, IPv6, and extended IPv4,
across local domains where routing is different.

- Its automatic tunneling aspects are in the new scope of Softwires
- Its IPv4 address extension aspects, based on dynamic-port prefixes,
are in the scope of Behave.

Regards
RD

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

IETF 73, call for agenda items

2008-10-31T10:22:23Z

According to the latest agenda, we will be meeting Thursday, Nov. 20th,
1740-1930.

Please send presentation requests & slides to David & me asap.

- Alain.

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

I-D Action:draft-ietf-softwire-hs-framework-l2tpv2-10.txt

2008-10-29T14:30:01Z

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Softwires Working Group of the IETF.

Title : Softwire Hub & Spoke Deployment Framework with L2TPv2
Author(s) : B. Storer, et al.
Filename : draft-ietf-softwire-hs-framework-l2tpv2-10.txt
Pages : 45
Date : 2008-10-29

This document describes the framework of the Softwire "Hub and Spoke"
solution with the Layer 2 Tunneling Protocol version 2 (L2TPv2). The
implementation details specified in this document should be followed
to achieve interoperability among different vendor implementations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-softwire-hs-framework-l2tpv2-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

draft-ietf-softwire-hs-framework-l2tpv2-10.txt (73 bytes) Download Attachment

Re: draft-pmohapat-softwire-lb-00.txt

2008-10-27T16:11:04Z

I think this is an appropriate item for the WG.

Regards,

Bill

>
>
> -----Original Message-----
> From: softwires-bounces@... [mailto:softwires-bounces@...]
On Behalf Of Pradosh Mohapatra (pmohapat)

> Sent: Saturday, October 04, 2008 11:01 AM
> To: softwires@...; alain_durand@...; David Ward
> Cc: idr; l3vpn@...; Clarence Filsfils (cfilsfil)
> Subject: [Softwires] draft-pmohapat-softwire-lb-00.txt
>
> We presented this draft at the Softwires WG last IETF and there was
> good support in the room.
>
> Review comments are most welcome.
>
> We would like to ask that the draft be adopted as a WG item.
>
> http://www.ietf.org/internet-drafts/draft-pmohapat-softwire-lb-00.txt
> _______________________________________________
> Softwires mailing list
> Softwires@...
> https://www.ietf.org/mailman/listinfo/softwires
>

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

Status of IPv4-IPv6 Coexistence Work

2008-10-27T05:54:38Z

IETF Community,

There has been a lot of activity on the topic of improving IPv4 and IPv6
coexistence, deployment of IPv6, and coping with the increasing shortage
of unassigned IPv4 addresses. This work crosses a number of layer and
area boundaries, which has led to new lists, cross-posting, etc. In
order to limit confusion, we'd like to give some guidance on where
to discuss what on which lists. The intent is not to declare any work
as in or out of charter with this message, only to try and direct list
discussion. These are only general guidelines, so please don't be
alarmed if we missed something in particular. Our hope is that this will
help everyone to continue the rich dialog on this important topic.

1. softwires@...

Softwires is chartered to work on combinations of IPv4/IPv6 and
IPv6/IPv4, including "dual-stack lite" functionality. This includes
discussion related to:

- All types of IPv4/IPv6 tunnels, including encapsulation, control
plane, etc.
- Affects of tunnel endpoints terminating into a concentrator performing
IPv4 to IPv4 NAT
- Discovery of tunnel endpoints
- Tunnels initiated by hosts or gateways
- Tunnels automatically setup by routing and special prefixes

Thus, if it involves a tunnel or encapsulation of IPvX over IPvY,
softwires is the place to go.

2. behave@...

The Behave WG is currently being rechartered. If the new charter is
approved, behave will work on various types of IPv4<->IPv6 translation.
Please direct all discussion related to:

- IPv4 to IPv6 and IPv6 to IPv4 translation
- IPv6 to IPv6 NAT
- Division of port space to share one IPv4 addresses among multiple
endpoints at the same time
- Affects on applications and transport protocols
- ALGs
- IPv4 to IPv4 NAT functionality, including for ISP deployments

Thus, if discussion involves an IP translator or the internal function
of a NAT, behave is the place to go.

3. v6ops@...

- Operational discussions on the topic of coexistence in general
- IPv6-only deployment

Thus, if it involves operational issues of IPv6 or IPv4 exhaustion, go
to v6ops.

4. The v4v6interim@... list will be removed after the Minneapolis
IETF meeting.

Jari Arkko
Ron Bonica
Lars Eggert
Mark Townsley
Magnus Westerlund

Resources:

WGs
Behave: http://www.ietf.org/html.charters/behave-charter.html
Softwire: http://www.ietf.org/html.charters/softwire-charter.html
v6ops: http://www.ietf.org/html.charters/v6ops-charter.html

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

WG Action: RECHARTER: Softwires (softwire)

2008-10-10T05:00:01Z

The Softwires (softwire) working group in the Internet Area of the IETF
has been rechartered. For additional information, please contact the
Area Directors or the working group Chairs.

Softwires (softwire)
----------------------

Last Modified: 2008-09-10

Current Status: Active Working Group

Additional information is available at tools.ietf.org/wg/softwire

Chair(s):
Alain Durand [alain_durand@...]
David Ward [dward@...]

Internet Area Director(s):
Jari Arkko [jari.arkko@...]
Mark Townsley [townsley@...]

Internet Area Advisor:
Mark Townsley [townsley@...]

Technical Advisor(s):
Xing Li [xing@...]

Mailing Lists:
General Discussion: softwires@...
To Subscribe: softwires-request@...
In Body: With a subject line: subscribe
Archive: http://www.ietf.org/mail-archive/web/softwires/current/index.html

Description of Working Group:

The Softwires Working Group is specifying the standardization of
discovery, control and encapsulation methods for connecting IPv4
networks across IPv6 networks and IPv6 networks across IPv4 networks in
a way that will encourage multiple, inter-operable implementations.

For various reasons, native IPv4 and/or IPv6 transport may not be
available in all cases, and there is a need to tunnel IPv4 in IPv6 or
IPv6 in IPv4 to cross a part of the network which is not IPv4 or IPv6
capable. The Softwire Problem Statement, RFC 4925, identifies two distinct
topological scenarios that the WG will provide solutions for,
"Hubs and Spokes" and "Mesh." In the former case, hosts or "stub" networks
are attached via individual, point-to-point, IPv4 over IPv6 or IPv6 over
IPv4 softwires to a centralized Softwire Concentrator. In the latter case
(Mesh), network islands of one Address Family (IPv4 or IPv6) are connected
over a network of another Address Family via point to multi-point
softwires among Address family Border Routers (AFBRs).

The focus of this WG is to:

Document the softwire encapsulation and control protocol usage for
one Address Family (IPv6 or IPv4) over another within the defined
problem spaces set out in RFC 4925.

Define "Dual-Stack Lite" which uses softwires and IPv4 NAT functions
to reduce the amount of Global and RFC 1918 Local IPv4 addressing
necessary for a Service Provider with an IPv6-enabled network to
continue delivering IPv4 reachability to its customers.

The WG will reuse existing technologies as much as possible and
only when necessary, create additional protocol building blocks.

For generality, all base SOFTWIRE encapsulation mechanisms should
support all combinations of IP versions over one other (IPv4 over IPv6,
IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6
translation mechanisms (NAT-PT), new addressing schemes, and block
address assignments are out of scope. DHCP options developed in this
group will be reviewed jointly with the DHC WG. BGP and other routing
and signaling protocols developed in this group will be reviewed jointly
with the proper working groups and other workings that may take interest
(e.g. IDR, L3VPN, PIM, LDP, SAAG, etc) .

Goals and Milestones:

Done Submit a softwires problem statement to the IESG to be considered as
an Informational RFC

Nov 2008 Submit H&S softwire encapsulation and control protocol to the
IESG to be considered as a Proposed Standard

Nov 2008 Submit Mesh softwire encapsulation and control protocol to the
IESG to be considered as a Proposed Standard

Mar 2009 Submit dual-stack lite to the IESG to be considered as a
Proposed Standard. The initial basis for this solution is described in
draft-durand-dual-stack-lite-00.txt and draft-droms-softwires-snat-01.txt.

Dec 2009 Submit softwires MIB to the IESG to be considered as Proposed
Standard
_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

draft-pmohapat-softwire-lb-00.txt

2008-10-04T11:01:27Z

We presented this draft at the Softwires WG last IETF and there was
good support in the room.

Review comments are most welcome.

We would like to ask that the draft be adopted as a WG item.

http://www.ietf.org/internet-drafts/draft-pmohapat-softwire-lb-00.txt
_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

Fwd: Softwire Implementation

2008-10-01T00:02:39Z

---------- Forwarded message ----------
From: Sarika Manepalli <msarika15@...>
Date: Wed, Oct 1, 2008 at 1:57 AM
Subject: Softwire Implementation
To: softwires@...

Hi Friends,
I am Sarika trying to learn about the Softwires and
its implementation. I read the RFCs related to Softwires and its
advantages. But I am unable to find any information related to
softwire's implementation. I want to know what devices are needed for
implementation of Softwires. Can anyone provide me details ( where can
I get the information) regarding this implementation. Please help me
out!!!

Any help on this is greatly appreciated!!

Thank you for your time and patience.

Regards,
Sarika.

--
There is no key to happiness, the door is always open...!! ;-)

--
There is no key to happiness, the door is always open...!! ;-)
_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

Re: v4v6interim@ietf.org Mailing list

2008-09-30T04:48:51Z

See the "Remote Participation" section at:
http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim

Please register for remote participation, so we have a feeling of how many
people are supposed to be in the jabber room and on the conference bridge.

-d

> -----Original Message-----
> From: Narayanan, Vidya [mailto:vidyan@...]
> Sent: Tuesday, September 30, 2008 12:04 AM
> To: Mark Townsley; Margaret Wasserman
> Cc: Brian Haberman; Internet Area; softwires@...; Dan
> Wing; 'IPv6 Operations'; ipv6@...; Behave WG
> Subject: RE: v4v6interim@... Mailing list
>
> Mark,
> Please share the remote particpation info (jabber room, audio
> link, etc.) when you have it.
>
> Thanks,
> vidya
>
> > -----Original Message-----
> > From: ipv6-bounces@... [mailto:ipv6-bounces@...] On
> > Behalf Of Mark Townsley
> > Sent: Wednesday, September 17, 2008 10:28 AM
> > To: Margaret Wasserman
> > Cc: Brian Haberman; Internet Area; softwires@...; Dan
> > Wing; 'IPv6 Operations'; ipv6@...; Behave WG
> > Subject: Re: v4v6interim@... Mailing list
> >
> >
> > We are discussing the situation with the host, and any
> > volunteers we can muster up.
> >
> > Our goal is to have streaming audio and video for the
> > presentations, with the ability to ask questions or make
> > statements to the speaker remotely over jabber (via a local
> > moderator, speaking on the remote participants behalf). I'm
> > afraid we probably will not have the right infrastructure for
> > effective real-time, multipoint, participation among remote
> > and local participants.
> >
> > It looks like there will be a good bit of alpha code running
> > no matter what we do, so don't bet that there will be no
> > problems. We'll make the experience as good as we can for
> > remote folks based on what we have though.
> >
> > - Mark
> >
> > Margaret Wasserman wrote:
> > >
> > > Has there been any resolution on how/if it will be possible
> > to attend
> > > this meeting remotely (conference bridge, web conference,
> > jabber room,
> > > etc.)?
> > >
> > > I will not be able to travel to Montreal, but would like to
> > attend all
> > > or part of the meeting remotely, if possible.
> > >
> > > Thanks,
> > > Margaret
> > >
> > > On Sep 15, 2008, at 6:53 PM, Mark Townsley wrote:
> > >
> > >>
> > >> We have setup an email list for discussion leading up to
> > the interim
> > >> v4v6 coexistence meeting on October 1-2, 2008 in Montréal,
> > Canada. If
> > >> you are registered to attend the meeting, you should
> already be on
> > >> the list.
> > >>
> > >> The list is open, please subscribe and begin using it for
> > all interim
> > >> meeting related discussion (technical as well as
> > >> administrative/logistical). For now, please consider this a
> > >> short-lived list focused on agenda items for discussion at this
> > >> interim meeting alone. We should know better after the
> > meeting how to
> > >> best divide discussion back among the individual WG lists,
> > or whether
> > >> a long-lived list of this nature is warranted.
> > >>
> > >> If you are attending and haven't registered, please do:
> > >>
> > >>
> >
> http://trac.tools.ietf.org/area/int/trac/wiki/RegistrationForv4v6inte
> > >> rim
> > >>
> > >> Tentative agenda, etc. can be found here:
> > >>
> > >> http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim
> > >>
> > >> Thanks,
> > >>
> > >> - Mark, Jari, Dan and Brian
> > >>
> > >>
> > >>
> > >>
> > >>
> > --------------------------------------------------------------------
> > >> IETF IPv6 working group mailing list
> > >> ipv6@...
> > >> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> > >>
> > --------------------------------------------------------------------
> > >
> > >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@...
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

Re: v4v6interim@ietf.org Mailing list

2008-09-30T04:09:03Z

Narayanan, Vidya wrote:
> Mark,
> Please share the remote particpation info (jabber room, audio link, etc.) when you have it.
>
Hi Vidya,

Gunter will be sending that out before tomorrow.

Thanks,

- Mark

> Thanks,
> vidya
>
>
>> -----Original Message-----
>> From: ipv6-bounces@... [mailto:ipv6-bounces@...] On
>> Behalf Of Mark Townsley
>> Sent: Wednesday, September 17, 2008 10:28 AM
>> To: Margaret Wasserman
>> Cc: Brian Haberman; Internet Area; softwires@...; Dan
>> Wing; 'IPv6 Operations'; ipv6@...; Behave WG
>> Subject: Re: v4v6interim@... Mailing list
>>
>>
>> We are discussing the situation with the host, and any
>> volunteers we can muster up.
>>
>> Our goal is to have streaming audio and video for the
>> presentations, with the ability to ask questions or make
>> statements to the speaker remotely over jabber (via a local
>> moderator, speaking on the remote participants behalf). I'm
>> afraid we probably will not have the right infrastructure for
>> effective real-time, multipoint, participation among remote
>> and local participants.
>>
>> It looks like there will be a good bit of alpha code running
>> no matter what we do, so don't bet that there will be no
>> problems. We'll make the experience as good as we can for
>> remote folks based on what we have though.
>>
>> - Mark
>>
>> Margaret Wasserman wrote:
>>
>>> Has there been any resolution on how/if it will be possible
>>>
>> to attend
>>
>>> this meeting remotely (conference bridge, web conference,
>>>
>> jabber room,
>>
>>> etc.)?
>>>
>>> I will not be able to travel to Montreal, but would like to
>>>
>> attend all
>>
>>> or part of the meeting remotely, if possible.
>>>
>>> Thanks,
>>> Margaret
>>>
>>> On Sep 15, 2008, at 6:53 PM, Mark Townsley wrote:
>>>
>>>
>>>> We have setup an email list for discussion leading up to
>>>>
>> the interim
>>
>>>> v4v6 coexistence meeting on October 1-2, 2008 in Montréal,
>>>>
>> Canada. If
>>
>>>> you are registered to attend the meeting, you should already be on
>>>> the list.
>>>>
>>>> The list is open, please subscribe and begin using it for
>>>>
>> all interim
>>
>>>> meeting related discussion (technical as well as
>>>> administrative/logistical). For now, please consider this a
>>>> short-lived list focused on agenda items for discussion at this
>>>> interim meeting alone. We should know better after the
>>>>
>> meeting how to
>>
>>>> best divide discussion back among the individual WG lists,
>>>>
>> or whether
>>
>>>> a long-lived list of this nature is warranted.
>>>>
>>>> If you are attending and haven't registered, please do:
>>>>
>>>>
>>>>
>> http://trac.tools.ietf.org/area/int/trac/wiki/RegistrationForv4v6inte
>>
>>>> rim
>>>>
>>>> Tentative agenda, etc. can be found here:
>>>>
>>>> http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim
>>>>
>>>> Thanks,
>>>>
>>>> - Mark, Jari, Dan and Brian
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>> --------------------------------------------------------------------
>>
>>>> IETF IPv6 working group mailing list
>>>> ipv6@...
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>
>>>>
>> --------------------------------------------------------------------
>>
>>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@...
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
>
>

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

Re: v4v6interim@ietf.org Mailing list

2008-09-30T00:03:50Z

Mark,
Please share the remote particpation info (jabber room, audio link, etc.) when you have it.

Thanks,
vidya

> -----Original Message-----
> From: ipv6-bounces@... [mailto:ipv6-bounces@...] On
> Behalf Of Mark Townsley
> Sent: Wednesday, September 17, 2008 10:28 AM
> To: Margaret Wasserman
> Cc: Brian Haberman; Internet Area; softwires@...; Dan
> Wing; 'IPv6 Operations'; ipv6@...; Behave WG
> Subject: Re: v4v6interim@... Mailing list
>
>
> We are discussing the situation with the host, and any
> volunteers we can muster up.
>
> Our goal is to have streaming audio and video for the
> presentations, with the ability to ask questions or make
> statements to the speaker remotely over jabber (via a local
> moderator, speaking on the remote participants behalf). I'm
> afraid we probably will not have the right infrastructure for
> effective real-time, multipoint, participation among remote
> and local participants.
>
> It looks like there will be a good bit of alpha code running
> no matter what we do, so don't bet that there will be no
> problems. We'll make the experience as good as we can for
> remote folks based on what we have though.
>
> - Mark
>
> Margaret Wasserman wrote:
> >
> > Has there been any resolution on how/if it will be possible
> to attend
> > this meeting remotely (conference bridge, web conference,
> jabber room,
> > etc.)?
> >
> > I will not be able to travel to Montreal, but would like to
> attend all
> > or part of the meeting remotely, if possible.
> >
> > Thanks,
> > Margaret
> >
> > On Sep 15, 2008, at 6:53 PM, Mark Townsley wrote:
> >
> >>
> >> We have setup an email list for discussion leading up to
> the interim
> >> v4v6 coexistence meeting on October 1-2, 2008 in Montréal,
> Canada. If
> >> you are registered to attend the meeting, you should already be on
> >> the list.
> >>
> >> The list is open, please subscribe and begin using it for
> all interim
> >> meeting related discussion (technical as well as
> >> administrative/logistical). For now, please consider this a
> >> short-lived list focused on agenda items for discussion at this
> >> interim meeting alone. We should know better after the
> meeting how to
> >> best divide discussion back among the individual WG lists,
> or whether
> >> a long-lived list of this nature is warranted.
> >>
> >> If you are attending and haven't registered, please do:
> >>
> >>
> http://trac.tools.ietf.org/area/int/trac/wiki/RegistrationForv4v6inte
> >> rim
> >>
> >> Tentative agenda, etc. can be found here:
> >>
> >> http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim
> >>
> >> Thanks,
> >>
> >> - Mark, Jari, Dan and Brian
> >>
> >>
> >>
> >>
> >>
> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@...
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>
> --------------------------------------------------------------------
> >
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@...
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

I-D Action:draft-ietf-softwire-mesh-framework-05.txt

2008-09-18T10:30:01Z

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Softwires Working Group of the IETF.

Title : Softwire Mesh Framework
Author(s) : J. Wu, et al.
Filename : draft-ietf-softwire-mesh-framework-05.txt
Pages : 33
Date : 2008-09-18

The Internet needs to be able to handle both IPv4 and IPv6 packets.
However, it is expected that some constituent networks of the
Internet will be "single protocol" networks. One kind of single
protocol network can parse only IPv4 packets and can process only
IPv4 routing information; another kind can parse only IPv6 packets
and can process only IPv6 routing information. It is nevertheless
required that either kind of single protocol network be able to
provide transit service for the "other" protocol. This is done by
passing the "other kind" of routing information from one edge of the
single protocol network to the other, and by tunneling the "other
kind" of data packet from one edge to the other. The tunnels are
known as "Softwires". This framework document explains how the
routing information and the data packets of one protocol are passed
through a single protocol network of the other protocol. The
document is careful to specify when this can be done with existing
technology, and when it requires the development of new or modified
technology.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-softwire-mesh-framework-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

draft-ietf-softwire-mesh-framework-05.txt (73 bytes) Download Attachment

Re: v4v6interim@ietf.org Mailing list

2008-09-17T10:27:41Z

We are discussing the situation with the host, and any volunteers we can
muster up.

Our goal is to have streaming audio and video for the presentations,
with the ability to ask questions or make statements to the speaker
remotely over jabber (via a local moderator, speaking on the remote
participants behalf). I'm afraid we probably will not have the right
infrastructure for effective real-time, multipoint, participation among
remote and local participants.

It looks like there will be a good bit of alpha code running no matter
what we do, so don't bet that there will be no problems. We'll make the
experience as good as we can for remote folks based on what we have though.

- Mark

Margaret Wasserman wrote:

>
> Has there been any resolution on how/if it will be possible to attend
> this meeting remotely (conference bridge, web conference, jabber room,
> etc.)?
>
> I will not be able to travel to Montreal, but would like to attend all
> or part of the meeting remotely, if possible.
>
> Thanks,
> Margaret
>
> On Sep 15, 2008, at 6:53 PM, Mark Townsley wrote:
>
>>
>> We have setup an email list for discussion leading up to the interim
>> v4v6 coexistence meeting on October 1-2, 2008 in Montréal, Canada. If
>> you are registered to attend the meeting, you should already be on
>> the list.
>>
>> The list is open, please subscribe and begin using it for all interim
>> meeting related discussion (technical as well as
>> administrative/logistical). For now, please consider this a short-lived
>> list focused on agenda items for discussion at this interim meeting
>> alone. We should know better after the meeting how to best divide
>> discussion back among the individual WG lists, or whether a long-lived
>> list of this nature is warranted.
>>
>> If you are attending and haven't registered, please do:
>>
>> http://trac.tools.ietf.org/area/int/trac/wiki/RegistrationForv4v6interim
>>
>> Tentative agenda, etc. can be found here:
>>
>> http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim
>>
>> Thanks,
>>
>> - Mark, Jari, Dan and Brian
>>
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@...
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

Re: v4v6interim@ietf.org Mailing list

2008-09-17T10:08:26Z

Has there been any resolution on how/if it will be possible to attend
this meeting remotely (conference bridge, web conference, jabber room,
etc.)?

I will not be able to travel to Montreal, but would like to attend all
or part of the meeting remotely, if possible.

Thanks,
Margaret

On Sep 15, 2008, at 6:53 PM, Mark Townsley wrote:

>
> We have setup an email list for discussion leading up to the interim
> v4v6 coexistence meeting on October 1-2, 2008 in Montréal, Canada. If
> you are registered to attend the meeting, you should already be on
> the list.
>
> The list is open, please subscribe and begin using it for all interim
> meeting related discussion (technical as well as
> administrative/logistical). For now, please consider this a short-
> lived
> list focused on agenda items for discussion at this interim meeting
> alone. We should know better after the meeting how to best divide
> discussion back among the individual WG lists, or whether a long-lived
> list of this nature is warranted.
>
> If you are attending and haven't registered, please do:
>
> http://trac.tools.ietf.org/area/int/trac/wiki/RegistrationForv4v6interim
>
> Tentative agenda, etc. can be found here:
>
> http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim
>
> Thanks,
>
> - Mark, Jari, Dan and Brian
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@...
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

WG Review: Recharter of Softwires (softwire)

2008-09-16T14:38:32Z

A modified charter has been submitted for the Softwires working group in
the Internet Area of the IETF. The IESG has not made any determination
as yet. The modified charter is provided below for informational purposes
only. Please send your comments to the IESG mailing list (iesg@...)
by Tuesday, September 23, 2008.

Softwires (softwire)
----------------------

Last Modified: 2008-09-10

Current Status: Active Working Group

Additional information is available at tools.ietf.org/wg/softwire

Chair(s):
Alain Durand alain_durand@...
David Ward dward@...

Internet Area Director(s):
Jari Arkko jari.arkko@...
Mark Townsley townsley@...

Internet Area Advisor:
Mark Townsley townsley@...

Technical Advisor(s):
Xing Li xing@...

Mailing Lists:
General Discussion: softwires@...
To Subscribe: softwires-request@...
In Body: With a subject line: subscribe
Archive: http://www.ietf.org/mail-archive/web/softwires/current/index.html

Description of Working Group:

The Softwires Working Group is specifying the standardization of
discovery, control and encapsulation methods for connecting IPv4
networks across IPv6 networks and IPv6 networks across IPv4 networks in
a way that will encourage multiple, inter-operable implementations.

For various reasons, native IPv4 and/or IPv6 transport may not be
available in all cases, and there is a need to tunnel IPv4 in IPv6 or
IPv6 in IPv4 to cross a part of the network which is not IPv4 or IPv6
capable. The Softwire Problem Statement, RFC 4925, identifies two distinct
topological scenarios that the WG will provide solutions for,
"Hubs and Spokes" and "Mesh." In the former case, hosts or "stub" networks
are attached via individual, point-to-point, IPv4 over IPv6 or IPv6 over
IPv4 softwires to a centralized Softwire Concentrator. In the latter case
(Mesh), network islands of one Address Family (IPv4 or IPv6) are connected
over a network of another Address Family via point to multi-point
softwires among Address family Border Routers (AFBRs).

The focus of this WG is to:

Document the softwire encapsulation and control protocol usage for
one Address Family (IPv6 or IPv4) over another within the defined
problem spaces set out in RFC 4925.

Define "Dual-Stack Lite" which uses softwires and IPv4 NAT functions
to reduce the amount of Global and RFC 1918 Local IPv4 addressing
necessary for a Service Provider with an IPv6-enabled network to
continue delivering IPv4 reachability to its customers.

The WG will reuse existing technologies as much as possible and
only when necessary, create additional protocol building blocks.

For generality, all base SOFTWIRE encapsulation mechanisms should
support all combinations of IP versions over one other (IPv4 over IPv6,
IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6
translation mechanisms (NAT-PT), new addressing schemes, and block
address assignments are out of scope. DHCP options developed in this
group will be reviewed jointly with the DHC WG. BGP and other routing
and signaling protocols developed in this group will be reviewed jointly
with the proper working groups and other workings that may take interest
(e.g. IDR, L3VPN, PIM, LDP, SAAG, etc) .

Goals and Milestones:

Done Submit a softwires problem statement to the IESG to be considered as
an Informational RFC

Nov 2008 Submit H&S softwire encapsulation and control protocol to the
IESG to be considered as a Proposed Standard

Nov 2008 Submit Mesh softwire encapsulation and control protocol to the
IESG to be considered as a Proposed Standard

Mar 2009 Submit dual-stack lite to the IESG to be considered as a
Proposed Standard. The initial basis for this solution is described
in draft-durand-dual-stack-lite-00.txt and
draft-droms-softwires-snat-01.txt.

Dec 2009 Submit softwires MIB to the IESG to be considered as Proposed
Standard
_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

Re: v4v6interim@ietf.org Mailing list

2008-09-16T12:32:22Z

Marshall,

Several people have indeed indicated desire to participate remotely, and
we are doing everything we can to make that possible.

I think we will at least have a voice stream coming out of the meeting,
jabber scribing (participants, please volunteer to scribe!), and
possibility for questions from jabber. But we are still organizing those
services and I don't want to promise anything more at this stage. See
also some additional information below, copied from Mark's e-mail to the
v4v6interim list. And this discussion should probably continue on that
list as well :-)

By the way -- if there is someone who has not registered for the
physical meeting yet but plans to come, please try to register before
Saturday, September 20th.

Jari

Mark Townsley wrote:

> The ADs are working with the meeting host to see what can be done based
> on what the facility has to offer. Cisco has offered webex hosting so
> that remote participants can at least see what is being presented on the
> projector and what is being said into a microphone, accessible over a
> web and/or PSTN interface for voice (with recording of all this for
> later viewing). But, without good microphones and discipline to use
> them, the experience might be limited. Same for folks that want to chime
> in over the phone, its nice to have some level of "floor control" to
> help moderate the interaction. We could setup a camera as well, but
> without real funding or exceptional volunteer efforts (not to mention
> lending of equipment and good connectivity outside the building), I'm
> not all that optimistic. We will do the best we can with the resources
> available, wish I could say more - perhaps Suresh can jump in and give
> more insight.

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

Re: v4v6interim@ietf.org Mailing list

2008-09-16T11:12:30Z

> -----Original Message-----
> From: Marshall Eubanks [mailto:tme@...]
> Sent: Tuesday, September 16, 2008 9:54 AM
> To: Jeroen Massar
> Cc: Mark Townsley; ipv6@...; 'IPv6 Operations'; Internet
> Area; Behave WG; softwires@...; Brian Haberman; Jari
> Arkko; Dan Wing
> Subject: Re: v4v6interim@... Mailing list
>
> Is there going to be a audio broadcast and jabber room for this
> interim ?

At this time, we are not sure of the audio broadcast capabilities
that are available in the meeting room.

> If so, how to join ?

Such specifics will be announced on the v4v6interim@... mailing
list.

-d

> If not, aren't these aids now part of the "open participation"
> required of IETF interims ?
>
> Regards
> Marshall
>
> On Sep 16, 2008, at 5:01 AM, Jeroen Massar wrote:
>
> > Mark Townsley wrote:
> >> We have setup an email list for discussion leading up to
> the interim
> >> v4v6 coexistence meeting on October 1-2, 2008 in Montréal,
> Canada. If
> >> you are registered to attend the meeting, you should
> already be on
> >> the list.
> >>
> >> The list is open, please subscribe and begin using it for
> all interim
> >> meeting related discussion (technical as well as
> >> administrative/logistical).
> >
> > For people, like me, who are not going to the meeting, but
> do want to
> > follow the discussions and possibly contribute to them, the list,
> > signup
> > and archives can be found here:
> >
> > https://www.ietf.org/mailman/listinfo/v4v6interim
> >
> > I couldn't find a reference to it from those URL's posted,
> might be
> > good
> > to put the ref there too.
> >
> > Greets,
> > Jeroen
> >
>

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

Re: v4v6interim@ietf.org Mailing list

2008-09-16T02:38:50Z

Jeroen Massar wrote:

> Mark Townsley wrote:
>
>> We have setup an email list for discussion leading up to the interim
>> v4v6 coexistence meeting on October 1-2, 2008 in Montréal, Canada. If
>> you are registered to attend the meeting, you should already be on the list.
>>
>> The list is open, please subscribe and begin using it for all interim
>> meeting related discussion (technical as well as
>> administrative/logistical).
>>
>
> For people, like me, who are not going to the meeting, but do want to
> follow the discussions and possibly contribute to them, the list, signup
> and archives can be found here:
>
> https://www.ietf.org/mailman/listinfo/v4v6interim
>

Thank you, I intended to include that in the email when drafting it, but
somehow it got left out. This list is definitely not only for attendees.
> I couldn't find a reference to it from those URL's posted, might be good
> to put the ref there too.
>
It is on the wiki now, but thank you for posting the direct link.

- Mark
> Greets,
> Jeroen
>
>

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

Re: v4v6interim@ietf.org Mailing list

2008-09-16T02:01:01Z

Mark Townsley wrote:
> We have setup an email list for discussion leading up to the interim
> v4v6 coexistence meeting on October 1-2, 2008 in Montréal, Canada. If
> you are registered to attend the meeting, you should already be on the list.
>
> The list is open, please subscribe and begin using it for all interim
> meeting related discussion (technical as well as
> administrative/logistical).

For people, like me, who are not going to the meeting, but do want to
follow the discussions and possibly contribute to them, the list, signup
and archives can be found here:

https://www.ietf.org/mailman/listinfo/v4v6interim

I couldn't find a reference to it from those URL's posted, might be good
to put the ref there too.

Greets,
Jeroen

_______________________________________________
Softwires mailing list
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires

signature.asc (194 bytes) Download Attachment