Subject: [PWE3] WG LC softwire-lb

From: David Ward <[email-masked]>
Date: Thu, 23 Apr 2009 16:07:19 -0500

All -
	Following the last IETF meeting all comments have been addressed in:

http://tools.ietf.org/html/draft-ietf-softwire-lb-02

The authors have requested a WG LC and I have added L3VPN and PWE3  
that may be interested and have comments on the technology. Please  
send back all comments by May 7, 2009.

Thanks

DWard, Alain

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 24 Apr 2009 01:31:41 -0700

Hi David,

Perhaps I may have missed the discussion on this in the other WGs but I 
have two comments/questions ...

* Why the decision on enhancing the load balancing capability of IP 
encapsulated packet has to be signaled as opposed to be a local matter 
of the ingress router performing encapsulation ?

* Reg use of GRE key for the purpose of load balancing I must say that 
GRE key has already been proposed in number of solutions today. Therefor 
overloading more on it may be impractical. Did authors analyzed use of 
Sequence Numbers in GRE header instead for the purpose of increasing 
effectiveness of load-balancing by the transit nodes ?

Cheers,
R.

> The authors have requested a WG LC and I have added L3VPN and PWE3 that 
> may be interested and have comments on the technology. Please send back 
> all comments by May 7, 2009.
> 
> Thanks
> 
> DWard, Alain

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 29 Apr 2009 11:23:36 -0400

Hi Robert,

Thank you for your comments, please see inline.

> of the ingress router performing encapsulation ?

This is because the load-balancing field is signaled (see RFC5512), so
using for lb it needs signaling of a block to avoid collisions. Note
also the context from the title, lb for Mesh Softwires. For the L2TPv3
case, and from <http://tools.ietf.org/html/rfc5512#section-4.1>, the
only encapsulating header field that is always there is the Session ID
(Cookie is optional), which is signaled; the case for GRE is equivalent,
but also please see below. If it's only a local matter, the
encapsulating header's fields could not be used and you would be limited
to playing with e.g., the source IP address.

> effectiveness of load-balancing by the transit nodes ?

Yes, it was considered, but we need a field that can be used for flow
identification. From RFC2890, the seq # MUST be used by the receiver to
establish packet transmission order, so it's incompatible with a
per-flow use. The GRE Key's semantics from RFC2890 match this use,
<http://tools.ietf.org/html/rfc2890#section-2.1>:

   The Key field contains a four octet number which was inserted by the
   encapsulator. The actual method by which this Key is obtained is
   beyond the scope of the document. The Key field is intended to be
   used for identifying an individual traffic flow within a tunnel.

Thanks,

-- Carlos.

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>