Softwire WG Meeting

IETF San Diego

Scribe: Chris Metz

11/06/2006

Meeting Minutes

=====================================

Chairs agenda bashing

Dave Ward – Update of Items Covered during Interim Meeting in September in Barcelona

• Reviewed current Hub&Spoke framework doc, group edits were performed

• Proxy-presented revised Mesh framework on behalf of John Scudder and Eric Rosen

• Problem statement work

• Agreed that multicast is next item to cover following Yong Cui’s presentation

• Then security will follow

Chris Metz – Softwire Problem Statement Update

draft-ietf-softwire-problem-statement-02.txt

• Rev-02 in last call

• Received feedback, mostly on SW Mesh, and need to incorporate into rev-03

• Feedback Item – SW Requirements vs L3VPN Requirements (RFC4031)

• SW Mesh will reuse multi-AF routing (e.g. BGP) and IP/MPLS encaps

• Need to add text that requirement to advertise tunnel encap info and the need to address v4nlri with v6 next-hop

• Pointers to IDR drafts on v4nlri/v6nh and info-safi

• Feedback item – spell out reachability combos.

• Add text that focus is public 4over6 and public 6over4; others are not excluded but covered in future doc

• Feedback item – notion is “islands”

• Clarify wording to indicate that islands may not be enclosed, i.e. backdoor AF1 routes between AF1 islands.

• Next step: generate rev-03

• No questions  

Eric Rosen – Softwire Mesh Framework Update

draft-wu-softwire-mesh-framework-01.txt

• first draft too complex in some cases; too simple in others, took another pass

• AF2 core is transparent to AF1 equipment

• AFBRs are dual-stack

• Need to tunnel AF1 packets across AF2 core

• Main cases are 6over4 or 4over6; existing solutions may apply more generally

• Too much VPN mentioned in previous draft; don’t want to recreate L3VPN work or confuse people

• Solutions Components
  

• Local AFBR needs to learn remote AFBR next hops for AF1 prefixes; NH of AF1 prefix can be AF2
  

• Precedent of different NLRI/NH combinations – e.g. VPN, 6PE, non-IP NLRI with IPv4/IPv6 NH

• Mixed NLRI/NH. Softwires endorses this notion; IDR needs to figure it out
  

• When to generate mixed NLRI/NH?
  

• Policy
  

• Default … NH-self, specify NH-self in IPv(X) if running BGP session over IPv(X)

• Constraint of mixed nlri/nh – in a given AF2 core all AFBRs and RR must deal with mixed combos

• Encapsulation and Policy
  

• AF1 must be tunneled across AF2
  

• Chosen by policy
   

• Admin. Select favorite encaps and deploys AFBRs that support it

• Conditional Policy
  

• Policy CANNOT be deduced from head-end/tail-end functions; e.g. what happens if head-end/tail-end routers support MPLS but core does not?
  

• Policies can be made conditional on information gathered in real-time by AFBRs

• Example of Conditional Policy given (see slides)
  

• Outlined BGP Info-SAFI (see slides)
   

• QoS, TE and security is really orthogonal to softwire machinery
  

• Tunnel Setup and Signaling
  

• Some tunnels don’t need signaling at all, except tail-end address which is provided by BGP next_hop. Example: IP-in-IP
  

• Others have native signaling. Example: RSVP-TE

• Some like L2TPv3 when used for multipoint-to-point forwarding is best signaled with pt-mpt BGP signaling. Another example: GRE w/keys

• What’s Not needed
  

• Prioritized list of encapsulation types
  

• Replacement of “BGP next hop” notion with “BGP next tunnel” notion … “hard row to hoe” in IDR

• Payload Type Identification
  

• After decap what is payload

• Some encaps tell you

• Other require demux

• Security – not really needed if dealing with Internet traffic
  

• Multicast

• Next time

• AF1 streams tunneled in AF2 multicast tunnels, like with MVPN PMSI
  

Ron: The distinction between L3VPN and Softwires is subtle. Is there something in L3VPN unicast that does not meet BGP-free core requirements?

Eric: Distinction is dealing with public AF, not VPN AF. Security requirement is different. L3VPN is carrying enterprise traffic; softwires is carrying Internet traffic

Ron: One client routing instance in softwires; many client routing instances in L3VPN

Yakov: Please go to solution constraints slides. You mean “No AF1 routes” in the core, not AF1 routing protocol. Please correct slides. And you need to explain why no legacy-legacy adjacencies are needed.

Yakov: Is it realistic to build a network system that supports two types of routers, each supporting a distinct and different encap type?

Eric: No but you would might one where some routers support both but all routers support at least one common encap type.

Danny: 1. What are the implications of supporting mixed NLRI/NH combos, need to spell out in more detail

Eric: Nothing special, just basic next-hop for v4 NLRI except it is a v6 NH. and would be comparable if I had for example a v4 NLRI with a V4 NH and a V6 NH

Danny: 2. What is the difference between enterprise and Internet multicast

Eric: Well one exists, the other does not J

Yakov: I like mixed NLRI/NH combos and it does work. 6PE and other solutions are proof points. An NLRI with mixed NHs is no different then an NLRI with next hops of the same AF.

Yakov: Observation: Default IGP in the AF core determines IGP NH

Chandra: Made some remarks critical of length field determining NH AF.

Subject of using multiple AFI/SAFI came up

Eric: This would be very bad, different AFI/SAFI is administrator configurable adding more work.  

Chandra: Remarked that multiple AFI/SAFI is actually simpler, IMHO …

Yakov: Using different AFI/SAFI makes route comparison Impossible; using same SAFI makes comparison of routes with different AF NHs possible

Eric: RIP would make Internet simpler; why not use it?

Bruno STEVANT – SW Hub & Spoke Framework Update

draft-ietf-softwire-hs-framework-l2tpv2-01.txt

• reviewed changes suggested in Barcelona interim meeting

• Softwire Establishment – L2TPv2 tunnel setup, PPP and endpoints configuration, additional configuration (optional depending on scenario), Scenario and AF used determined by softwire initiator
  

• SW Tunnel Maintenance

• 2 options for dead end detection: L2TP hello or PPP LCP
  

• BCP sections renamed as “considerations”
  

• Address Provisioning

• SW end-point addresses: give global, different solutions may be appropriate

• Delegated prefixes: removed reverse DNS considerations
  

• Address Stability

• New section with text form addr provisioning

• Involves nomadicity
  

• Radius Integration

• Added RRAO mechanism for DHCPv6
  

• Moving forward

• Finalize draft

• Discuss changes on ML

• Send to IESG for proposed standard

Ron: Why not use BFD for failure detection?

Dave Ward: BFD was discussed. But L2TPv2 or PPP Hello are sufficient for timeframe

Alain: Typical application is home with one wire

Ron: Why is there a need for separate H&S framework draft?

Bruno: Different problem than SW Mesh; in H&S only 1 tunnel per site/subscriber is required.

Shu Yamamoto - Softwire Security Update

draft-ietf-softwire-security-requirements-01

• published -01 version

• revised hub/spoke security

• mesh security section added

• overviewed h&s security model - Trusted (see slides)

• overviewed h&s security model – Non-Trusted (see slides)

• included RFC3193

• CPE home is un-trusted

• SW authentication mechanism

• PPP authentication – mutual using chap

• L2TPv2 authentication – optional chap-like authentication

• Ipsec authentication

• Summarized Control/Data Plane Protection (see slides)

• illustrated Ipsec in H&S scenario (see slides)

• illstrated H&S non-athenticated Mode (see slides)

• illustrated H&S Security Model (Visited) (see slides)

• Mesh Security Model

• Control plane attack to BGP/IGP

• DoS intrusion at edge

• Attack on data plane

• Mesh Security Model 2

• Discussed various mechanisms including SIDR techniques, ACL, Ipsec

• SW Mesh Security protection

• Control plane

• Data plane

• TCP MD5 and Ipsec for BGP updated

• RFC2385 for TCP MD5

• Ipsec

Discussed Tero Kivinen feedback of security doc.

Alain: Check with 6over4 Ipsec authors to see if it applies to 4over6 case

Danny: Maybe these security mechanisms are too broadly defined

Dave Ward: We need to do security analysis

John Scudder: Does SW need any more security than Internet?

Stewart: What IETF needs is general-purpose security document

Next Steps - Chairs

• H&S FW Update

• Mesh FW Update

• Work with IDR on BGP extensions

• Start multicast (Yong and Eric leading) and security

• want PS and Phase 0 of Framework docs through LC by next IETF

• no need for interim meeting until current work completed

Alain: looking to COMPLETE drafts by Prague