Re: [Softwires] WG LC softwire-lb

[Carlos Pignataro <[e-mail]>]

Hi Robert,

Thanks for the follow-up, please see inline.

On 4/29/2009 2:40 PM, Robert Raszuk wrote:
> <trimming a bit the spam list :)>
> 
> Hi Carlos,
> 
> Perhaps I was not very clear in the question. I understand that you are 
> adding the ability for ingress where for L2TPv3 over IP - Session ID & 
> for GRE - GRE key are distributed per egress as per RFC5512.
> 
> This is great !
> 
> But what I was mainly asking about was the case where egress does not 
> signal GRE key. Per 5512 is seems very well allowed as key is optional:
> 
>     "Note that the key is optional.  Unless a key value is being
>      advertised, the GRE encapsulation sub-TLV MUST NOT be present."

Thanks for the clarification; doesn't this para from RFC5512 mean that
the receiver (i.e., advertising router) is not expecting a key? That's
my understanding: The key is optional to be used, but if not signaled is
not used, and can mis-mux if used. From the first sentence in the
previous para (quoted below), I think it can be inferred that the
advertising router, by not signaling a key, is telling the encapsulating
end to not use one (rather than to use any):

   * GRE Key: 4-octet field [RFC2890] that is generated by the
     advertising router.
...
     Note that the key is optional.  Unless a key value is being
     advertised, the GRE encapsulation sub-TLV MUST NOT be present.

> 
> Then if one would read carefully your draft is says there:
> 
>     "Needless to say, if an egress router does not support load balancing
>     block sub-TLV, the Softwire continues to operate with a single load
>     balancing field that all ingress routers encapsulate with."
> 
> But since the whole purpose is to provide some additional field in the 
> IP encapsulation header other then play with src address for core 
> routers doing ECMP shouldn't we mention some text allowing for local 
> ingress PE injection of random keys when such a keys are not required by 
>   application using 5512 for it's mesh tunnel setup ?

That's the whole purpose, as long as the egress can understand it. Such
policy seems too liberal on sending, considering that the same result is
achieved when the advertising router includes a lb-block TLV with
appropriate mask (i.e., an 0/0).

Perhaps, do you think we should add some text to tighten that case, and
saying that for the specific case where GRE is used without Key and
without LB-block, the sender is explicitly expected direct to not use LB
Keys (since the receiver can otherwise mis-demux/drop)?

Potentially, the last sentence of the following para from softwire-lb:

   The sub-TLV type of the Load Balancing Block sub-TLV is 5.  The sub-
   TLV length is 2 octets.  The value represents the length of the block
   in bits and it MUST NOT exceed the size of the load balancing field.

seems to implicitly cover that the lb-block sub-TLV cannot be used
without the Encapsulation Sub-TLV (and corresponding Key), do you think
that needs tightening? We can explicitly say in Section 2.1 that is not
only applicable to tunnels that define the field, but also can only be
used when that field is signaled?


> 
> As to my second question I agree. In fact your proposal allows for sort 
> of overloading the GRE key semantics to serve both for given application 
> as well as for core load-balancing.
> 

Ack.

Thanks again for the comments.

-- Carlos.

> Many thx,
> R.
> 
> 
>> Hi Robert,
>>
>> Thank you for your comments, please see inline.
>>
>> On 4/24/2009 4:31 AM, Robert Raszuk wrote:
>>> 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 ?
>> 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.
>>
>>> * 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 ?
>> 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.
>>
>>
>>
>>> Cheers,
>>> R.
>>>
>>>
>>>> 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
>>> _______________________________________________
>>> Softwires mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>>
> 
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>