Re: [Softwires] Ops-dir review of draft-ietf-softwire-mesh-framework-05

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
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires