{"draft":"draft-ietf-softwire-lb-03","doc_id":"RFC5640","title":"Load-Balancing for Mesh Softwires","authors":["C. Filsfils","P. Mohapatra","C. Pignataro"],"format":["ASCII","HTML"],"page_count":"6","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"Softwires","abstract":"Payloads transported over a Softwire mesh service (as defined by BGP\r\nEncapsulation Subsequent Address Family Identifier (SAFI) information\r\nexchange) often carry a number of identifiable, distinct flows.  It\r\ncan, in some circumstances, be desirable to distribute these flows\r\nover the equal cost multiple paths (ECMPs) that exist in the packet\r\nswitched network.  Currently, the payload of a packet entering the\r\nSoftwire can only be interpreted by the ingress and egress routers.\r\nThus, the load-balancing decision of a core router is only based on\r\nthe encapsulating header, presenting much less entropy than available\r\nin the payload or the encapsulated header since the Softwire\r\nencapsulation acts in a tunneling fashion.  This document describes a\r\nmethod for achieving comparable load-balancing efficiency in a\r\nnetwork carrying Softwire mesh service over Layer Two Tunneling\r\nProtocol - Version 3 (L2TPv3) over IP or Generic Routing\r\nEncapsulation (GRE) encapsulation to what would be achieved without\r\nsuch encapsulation.  [STANDARDS-TRACK]","pub_date":"August 2009","keywords":["[--------]","bgp encapsulation subsequent address family identifier","safi"],"obsoletes":[],"obsoleted_by":[],"updates":[],"updated_by":["RFC9012"],"see_also":[],"doi":"10.17487\/RFC5640","errata_url":null}