Subject: [Softwires] Last Call: 'Softwire Problem Statement' to Informational RFC (draft-ietf-softwire-problem-statement)

From: The IESG <[email-masked]>
Date: Thu, 14 Sep 2006 11:45:18 -0400

The IESG has received a request from the Softwires WG to consider the 
following document:

- 'Softwire Problem Statement '
   <draft-ietf-softwire-problem-statement-02.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-09-28.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-softwire-problem-statement-02.txt

_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 15 Sep 2006 05:04:20 -0700

Hi,

> [email-masked] or [email-masked] mailing lists by 2006-09-28.

One general comment: the document needs to clearly articulate the
differences between the softwire requirements and the requirements
for VPNs (as specified in rfc4031), as doing this will help in
understanding what additional technologies need to be developed in
support of softwires requirements.

Few specific comments...

>From the document:

   It should also be noted that the mesh problem can be considered as a
   derivative of L3VPN, where the core provides transit in one address
   family and the islands are connected via L3VPN of another address
   family.  This analogy only holds true if the islands can to be
   represented as VPNs.  In general, the diagrams frequently used for
   L3VPNs is very similar.  The key point is that the reachability
   information that is to be exchanged must not be limited to VPNs or
   any single AF or SAF or combination of AF/SAF.  The solution must be
   generic enough to carry any AF or SAF.

First of all, the above text implies that in the context of softwires
"the islands" can not be represented as VPNs. If that is indeed the
case, then the document needs to clearly spell out why this is so.

Second, the statement that "the reachability information that is
to be exchange must not be limited to VPNs" needs to be elaborated,
and specifically the document needs to state what kind of reachability
information needs to be exchanged that is beyond of what is exchanged
in the VPN case.

Third, the above text implies that in the VPN case the reachability
information is limited to a single AF or SAF or combination of
AF/SAF. This is incorrect, as for example in the case of IP VPNs
the reachability information could be either IPv4 or IPv6.

Yakov.

---

From: David Ward <[email-masked]>
Date: Fri, 15 Sep 2006 08:42:13 -0500

Yakov -

Thanks for your fast turnaround and comments.

> support of softwires requirements.

Isn't stating that softwires isn't a VPN only solution enough? We have had
many presentations in the time we have been a WG demonstrating VPN
requirements and non-requirements. Our doc is not a requirements doc but, a
problem statement. Clearly we want to specific but, since softwires is a
generic transition mechanism; we don't want to put ourselves into a corner.

> case, then the document needs to clearly spell out why this is so.

The text attempts to state that the "the islands" MUST NOT be represented
only as VPNs. The islands could be VPNs or not.

> information needs to be exchanged that is beyond of what is exchanged

Would a full enumeration help? We cut the full enumeration trying to keep
both VPN and non-VPN scoped islands possible (individually and in
combination) and keep it readable. We may have cut too much.

> the reachability information could be either IPv4 or IPv6.

The key is that we wanted to limit our first solution of IPvX over IPvY (and
vice versa) and not focus on IPvY over IPvY, X over X, as those cases have
been solved.

-DWard

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 15 Sep 2006 07:14:51 -0700

Dave,

> Isn't stating that softwires isn't a VPN only solution enough? 

No it is not enough, for the reasons I mentioned above. 
 
> We have had

If they are not represented as VPNs, then what are they ?

> combination) and keep it readable. We may have cut too much.

Yes, a full enumeration would be very useful.
  
> vice versa) and not focus on IPvY over IPvY, X over X, as those cases have

That still does not make the text I quoted correct.

Yakov.

---

From: David Ward <[email-masked]>
Date: Fri, 15 Sep 2006 09:33:33 -0500

Yakov -

inline

On 9/15/06 9:14 AM, "Yakov Rekhter" <[email-masked]> wrote:
...snip...

> If they are not represented as VPNs, then what are they ?

As an example, they could be islands representing global connectivity that
can only peer across the core of another AF. Thus, there could be no VPNs in
the islands or need to represent the global table as a VPN.

> Yes, a full enumeration would be very useful.

Ok.

> That still does not make the text I quoted correct.

Ok. I thought you were implying something else. Your quote is suggesting
that the text is overly constraining for our intentions.

-DWard

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 15 Sep 2006 07:56:09 -0700

Dave,

> the islands or need to represent the global table as a VPN.

Then the document should explicitly state that the islands are
either part of a VPN, or part of the Internet. Moreover, the document
should state that even if the islands are part of the Internet,
then one option would be to realized it as a VPN.

Yakov.