Following up is going to be difficult due to the time of the year, but..
On Thu, 18 Dec 2008, Eric Rosen wrote:
My main concern here is with the O&M implication of dynamically
created and used softwires, which do not run any routing protocol and
there is no IETF protocol or management framework which could be used
to verify the correct operation of these tunnels.
In fact, we have over a decade of experience with softwires, implemented as
MPLS tunnels. We also have many years of experience with softwires
implemented as L2TPv3 tunnels, and I believe there are also deployments of
softwires implemented as GRE tunnels. So it's a little late to claim that
these constructs pose insuperable management difficulties.
All that's really new here is that the framework for signaling the tunnels
and for determining which packets get tunneled has been stated in a general
way, and the use of softwires is discussed in the context of a v6/v4
Internet, rather than in the context of L3VPN.
The application of OAM to softwires (particularly when realized as MPLS
LSPs) has been quite extensively discussed over the years and I don't think
anything new needs to be mandated by the framework document.
I did not say these problems are insurmountable. The problems can be
addressed by each operator deploying their own solution that addresses
at least some of this. but these problems are not addressed in the
IETF framework. We're creating a solution that is more fragile than
status quo (a network which has not deployed MPLS and/or L2TPv3 for
similar purpose) and IETF is doing disservice to the community if it
doesn't clearly describe these problems (not done currently) and
provide solutions to them.
It would be interesting to get more references on L2TPv3 deployments,
but I don't consider MPLS a very good comparison point here; the
charter looks for IPx over IPy solution, as does the problem
statement; it would seem to be that the MPLS-specific parts of this
framework are redundant. For similar reasons, MPLS OAM techniques
(such as LSP ping) are not AFAIK applicable here as the softwires
framework is targeting non-MPLS deployments.
In S 5 (this is also bordering on architectural issue):
This leads to the following softwires deployment
restriction: if a BGP Capability is defined for the case
in which an E-IP NLRI has an I-IP NH, all the AFBRs in a
given transit core MUST advertise that capability.
... is there any way an implementation could verify if this deployment
restriction holds or not?
I don't think a service provider with an I-IP core would start offering E-IP
transit service unless all its AFBRs were capable of providing the service.
This not only includes having the appropriate BGP capabilities, but also the
appropriate hardware/software capabilities to do the encapsulation and
decapsulation, support for E-IP and I-IP on appropriate interfaces, etc.
One could imagine configuring the BGP speakers (including route reflectors)
so that IBGP connections are not accepted unless some particular set of BGP
capabilities are advertised, but that's only one small piece of the overall
set of deployment requirements.
This does not help much in preventing misconfigurations. For example,
the document might say that the BGP Capability MUST NOT be advertised
unless manually configured to do so (so that if an implementation
would support this but the operator does not want to use it, it
wouldn't be used). This still would not detect partial-mesh
misconfigurations (I guess this would be similar to non-full ibgp
mesh), but would reduce unintended effects.
At some point, a client might want to upgrade to dual stack. Then,
client-interface may use both E-IP and I-IP. This solution should be
applicable then as well
Depending on policy, one might or might not want to do, e.g., v6/v6 or v4/v4
encapsulation. However, covering these cases is not within the scope of the
WG charter.
I was not referring to v6/v6 or v4/v4 encapsulation. If a client
upgrades from v4-only to dual-stack, does it need to switch provider
to be able to use v6, or would v6 traffic be dropped on the floor?
Obviously this should not be the case, but the framework does not say
so. I believe it should, even if it is trivial. For example,
enabling this method for v4 E-IP must not prevent the ISP from also
providing v6 E-IP (without tunneling) to the user.
I.e., the longest-prefix matching is no longer sufficient with
softwires (i.e.: when deciding whether a packet to a particular E-IP
destination prefix should be tunneled through a softwire or forwarded
natively).
I'm not sure what made you think that longest-prefix matching is not
sufficient.
I was trying to figure out how 'show ip route [prefix]' or similar for
an E-IP prefix would look like at an AFBR router, and I couldn't
figure out how BGP could populate the routes in RIB without any
softwire-specific mechanism, and conclused that the text in S 7 and
later on policy referred to this.
If you'd implement this with longest-prefix matching, but with
modifications to BGP, what I guess could happen is that for a BGP
message for an E-IP prefix, the system where this is configured would
need to install the E-IP prefix to RIB, change the next-hop to to be a
dynamically created point-to-point tunnel interface. This next-hop
would only be changed for "softwire-enabled" BGP sessions. Each BGP
I-IP nexthop would be associated with its own unnumbered tunnel
interface. Or it could point to a pseudo-tunnel interface, which
would have a separate routing table where it looked up where to tunnel
packets.
If above kind of operation is assumed, instead of talking about policy
etc., some text on what's actually going on, even if non-normative,
would help the reader grasp the content of what needs to happen and
which mechanisms require modification in the process.
missing standardization [in the area of tunneling multicasts]
In the unicast area, most of the technology needed is already standardized
or in LC, hence the framework document makes normative references. In the
multicast area, the situation is different, and the framework document lays
out options without making normative references to specified technology.
I'd say this is a problem; the problem statement calls rather strongly
for the solution to support multicast, and it currently does not do
so.
Have these two things [BGP next hop resolution and stacking of
encapsulations] been specified somewhere? This calls for a reference.
I think "recursive route resolution" and "stacking encapsulations" are "terms
of the art" which do not need to be defined in this document, but for which
there is not a standard reference.
Did you mean "do not need", because 'but' seems strange here (with
this phrasing, I'd have expected 'and')? Nonetheless, I'd still say
more specific text is needed, at the minimum clearly naming what is
required and how to interoperate it.
.. I believe this could result in two kinds of attacks which could be
emphasized better (more below) Above uses "policy violations" which
may be read to refer to a policy described in Section 7. For example,
the focus of the second quoted sentence is odd -- and makes this seem like
an issue in transmitting endpoints while to me the major issue seems to be
unauthorized endpoints.
The problem referred to is that if unauthorized nodes masquerade as
authorized transmitting endpoints, there may be a way to side-step the
authorized policies. I'm not quite sure what you are objecting to here.
It seems to be emphasizing the wrong thing -- that different kinds of
packets may or may not be encapsulated by authorized endpoints, and
that unauthorized endpoints are not bound to these policies. The
problem is the unauthorized endpoints, the policy (or lack thereof) of
authorized endpoints doesn't really matter, because even if it didn't
exist, we could think of various kinds of packets sent by unauthorized
endpoints that would need to be blocked. The key point here is
analyzing how to prevent unauthorized endpoints and what kind of
impact failing to do so would cause.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
