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

[Eric Rosen <[e-mail]>]

Pekka> My main concern here is with the O&M implication of dynamically
Pekka> created and used softwires, which do not run any routing protocol and
Pekka> there is no IETF protocol or management framework which could be used
Pekka> to verify the correct operation of these tunnels.

Pekka> We're creating a solution that is more fragile than 
Pekka> status quo (a network which has not deployed MPLS and/or L2TPv3 for 
Pekka> similar purpose) and IETF is doing disservice to the community if it 
Pekka> doesn't clearly describe these problems (not done currently) and 
Pekka> provide solutions to them.

The notion of "disservice to  the community" is highly subjective, and hence
is not a  meaningful criticism.  It seems to me that  the mesh framework doc
falls within  the charter of the  WG, and a comprehensive  discussion of the
OAM issues  is not a prerequisite  for either the framework  or the protocol
documents. 

Pekka> the document might say that the BGP Capability MUST NOT be advertised 
Pekka> unless manually configured to do so (so that if an implementation 
Pekka> would support this but the operator does not want to use it, it 
Pekka> wouldn't be used)

I don't see the point of this,  as the document makes it very clear that the
decision to  forward through a  softwire is always  a matter of  policy, and
determined by  the ingress AFBR.   Thus the presence  or absence of  the BGP
capability does not force the operator to do anything.

Pekka> If a client  upgrades from v4-only to dual-stack, does it need to
Pekka> switch provider  to be able to use v6, or would v6 traffic be dropped
Pekka> on the floor?

That is a business issue between the client and the provider.

Pekka> Obviously this should not be the case, but the framework does not say
Pekka> so.  I believe it should, even if it is trivial. 

The framework should not tell providers how to do business with their clients.

Pekka> For example, enabling this method for v4 E-IP must not prevent the
Pekka> ISP from also providing v6 E-IP (without tunneling) to the user.

I don't think anything in the framework could be interpreted as preventing a
provider from doing anything.  

Pekka> If you'd implement this with longest-prefix matching, but with 
Pekka> modifications to BGP, what I guess could happen is that for a BGP 
Pekka> message for an E-IP prefix, the system where this is configured would 
Pekka> need to install the E-IP prefix to RIB, change the next-hop to to be a 
Pekka> dynamically created point-to-point tunnel interface.  This next-hop 
Pekka> would only be changed for "softwire-enabled" BGP sessions.  Each BGP 
Pekka> I-IP nexthop would be associated with its own unnumbered tunnel 
Pekka> interface.  Or it could point to a pseudo-tunnel interface, which 
Pekka> would have a separate routing table where it looked up where to tunnel 
Pekka> packets.

I don't think there is any need to discuss the various implementation
techniques that might be used to support the framework.  

Eric> In the unicast area, most of the technology needed is already
Eric> standardized or in LC, hence the framework document makes normative
Eric> references.  In the multicast area, the situation is different, and
Eric> the framework document lays out options without making normative
Eric> references to specified technology.

Pekka> I'd say this is a problem; the problem statement calls rather
Pekka> strongly for the solution to support multicast, and it currently does
Pekka> not do so.

The framework indicates multiple ways in which multicast can be supported.
That's about as good as it ever gets in multicast.  It makes no sense to
hold up the unicast solutions until all the multicast issues are understood
and agreed upon.

Eric> The problem referred to is that if unauthorized nodes masquerade as
Eric> authorized transmitting endpoints, there may be a way to side-step the
Eric> authorized policies.  I'm not quite sure what you are objecting to
Eric> here.

Pekka> It seems to be emphasizing the wrong thing -- that different kinds of 
Pekka> packets may or may not be encapsulated by authorized endpoints, and 
Pekka> that unauthorized endpoints are not bound to these policies.  The 
Pekka> problem is the unauthorized endpoints, the policy (or lack thereof) of 
Pekka> authorized endpoints doesn't really matter, because even if it didn't 
Pekka> exist, we could think of various kinds of packets sent by unauthorized 
Pekka> endpoints that would need to be blocked.  The key point here is 
Pekka> analyzing how to prevent unauthorized endpoints and what kind of 
Pekka> impact failing to do so would cause.

The  impact of  failing  to  prevent unauthorized  endpoints  is exactly  as
stated, that the  authorized policies may be bypassed.  It  seems to me that
the  security  considerations section  adequately  discusses  the issues  of
blocking traffic from unauthorized endpoints.


 


_______________________________________________
Softwires mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/softwires