Last Call: 'Softwire Problem Statement' to Informational RFC (draft-ietf-softwire-problem-statemen

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
iesgietf.org or ietfietf.org mailing lists by 2006-09-28.

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


_______________________________________________
Softwires mailing list
Softwiresietf.org
http
s://www1.ietf.org/mailman/listinfo/softwires

Hi,

> 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
> iesgietf.org or ietfietf.org 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.

_______________________________________________
Softwires mailing list
Softwiresietf.org
http
s://www1.ietf.org/mailman/listinfo/softwires

Yakov -

Thanks for your fast turnaround and comments.


On 9/15/06 7:04 AM, "Yakov Rekhter"
<yakovjuniper.net> wrote:

> Hi,
> 
>> 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
>> iesgietf.org or ietfietf.org 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.
> 

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.


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

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


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

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.


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

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


> Yakov.
> 
> _______________________________________________
> Softwires mailing list
> Softwiresietf.org
> http
s://www1.ietf.org/mailman/listinfo/softwires


_______________________________________________
Softwires mailing list
Softwiresietf.org
http
s://www1.ietf.org/mailman/listinfo/softwires

Yakov -

Thanks for your fast turnaround and comments.


On 9/15/06 7:04 AM, "Yakov Rekhter"
<yakovjuniper.net> wrote:

> Hi,
> 
>> 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
>> iesgietf.org or ietfietf.org 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.
> 

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.


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

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


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

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.


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

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


> Yakov.
> 
> _______________________________________________
> Softwires mailing list
> Softwiresietf.org
> http
s://www1.ietf.org/mailman/listinfo/softwires


_______________________________________________
Softwires mailing list
Softwiresietf.org
http
s://www1.ietf.org/mailman/listinfo/softwires