Re: [lisp] Tsvart last call review of draft-ietf-lisp-gpe-05

Fabio Maino <fmaino@cisco.com> Fri, 28 September 2018 20:35 UTC

Return-Path: <fmaino@cisco.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7863412F1A2; Fri, 28 Sep 2018 13:35:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.956
X-Spam-Level:
X-Spam-Status: No, score=-14.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdZrH6MySWVd; Fri, 28 Sep 2018 13:35:34 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE77127B92; Fri, 28 Sep 2018 13:35:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50097; q=dns/txt; s=iport; t=1538166934; x=1539376534; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=Vy8d0/iKlSuEo3yG/PkFPm+s4NwmOWuGZQ+Go2Fg5Ow=; b=YJZQFr7CW2EF1BFKdxPdow9yRHl7YV3C0rAfemgqRnNshfk4ETfJvJQm hiQsn3AYEucpX5boDm61VeUw/H+d0n2RL96+SrgGuEC515qs9SqkHBD8j CeqnQ/iB2+7w7CfJ1Xw3PXiS76Ds5vwnjXnaTcENugBArQFIAIbPMQb0i Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AsAABZj65b/4sNJK0ZAUIbAQEBAQM?= =?us-ascii?q?BAQEHAwEBAYFSgV4FKmZ/IQeYOYFoJXiVXhSBZgsjhEkCg3shNRcBAwEBAgE?= =?us-ascii?q?BAm0cDIU4AQEBAQIBGgEsMg4CCw4EBiABBgcbKwMOBg0GAgEBgx0BgXkICAe?= =?us-ascii?q?HXJ4qH4MKgQIBBwc9hRUFinkXgUE/gRInDIIqNYMbAgMBgSoBCwcBGwqFUgK?= =?us-ascii?q?IKBgIBCyGAEaNXwmGQ4MLhlwGF4FHhFqCY4ZEjAaBeBeHDoFEATVkcTMaCBs?= =?us-ascii?q?VgycJFoIGF3sBAwSEK4MshV4fMAEXAQGKXg8XgicBAQ?=
X-IronPort-AV: E=Sophos;i="5.54,316,1534809600"; d="scan'208,217";a="448533281"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2018 20:35:31 +0000
Received: from [10.32.173.55] ([10.32.173.55]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTP id w8SKZU88030903; Fri, 28 Sep 2018 20:35:30 GMT
To: Luigi Iannone <ggx@gigix.net>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, tsv-art@ietf.org, lisp@ietf.org, ietf@ietf.org, draft-ietf-lisp-gpe.all@ietf.org, =?UTF-8?Q?Mirja_K=c3=bchlewind?= <ietf@kuehlewind.net>
References: <153553422964.14784.628403975182959075@ietfa.amsl.com> <f5930d34-4e3b-a800-4c59-b8b46fd78b73@cisco.com> <5dd519c0-6810-8596-37e9-377e38175a7d@ericsson.com> <8856bfce-8d2f-baae-d85c-fea09ba86f69@cisco.com> <29f21563-362e-e7cc-3e07-19ff14294eab@cisco.com> <368436FB-586D-4810-9A04-91CBD3C526D4@gigix.net>
From: Fabio Maino <fmaino@cisco.com>
Message-ID: <6f6e6640-6964-4b4e-a15e-f73f406cfdb0@cisco.com>
Date: Fri, 28 Sep 2018 13:35:30 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <368436FB-586D-4810-9A04-91CBD3C526D4@gigix.net>
Content-Type: multipart/alternative; boundary="------------22C74C5D87E349E9469F4094"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.32.173.55, [10.32.173.55]
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/BdPRr-XPmN2xZtxrtGIthINIBFs>
Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-gpe-05
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Sep 2018 20:35:39 -0000

On 9/21/18 2:04 AM, Luigi Iannone wrote:
> Hi Fabio,
>
> just one comment on the following sentence (section 1)
>
> LISP-GPE MAY also be used to extend the LISP Data-Plane header, that
>    has allocated all by defining a Next Protocol "shim" header that
>    implements new data plane functions not supported in the LISP header.
>
> Something is missing in this sentence.
>
> May be: LISP-GPE MAY also be used to extend the LISP Data-Plane 
> header, **since
>    all of the reserved bits have been allocated, **  by defining a 
> Next Protocol "shim" header that
>    implements new data plane functions not supported in the LISP header.
> Ciao

Thanks for catching this Luigi. It will be addressed in -07.

Fabio

>
> L.
>
>
>
>> On 21 Sep 2018, at 07:12, Fabio Maino <fmaino@cisco.com 
>> <mailto:fmaino@cisco.com>> wrote:
>>
>> I have incorporated the changes as discussed, so hopefully rev 6. can 
>> be used by reviewers before the telechat: 
>> https://www.ietf.org/id/draft-ietf-lisp-gpe-06.txt
>>
>> Here is the diff: goo.gl/tCKD4A <http://goo.gl/tCKD4A>
>>
>>
>> I believe the following comments are still open. I'll work with the 
>> respective authors to address them in the next rev of the document.
>>
>>
>> A. [Deborah/Magnus] it is being discussed on a separate private 
>> thread if the following should be added to the IANA section:
>> "To ensure that protocols that are encapsulated in LISP-GPE will work 
>> well from a transport interaction perspective, the registration of a 
>> new encapsulated payload MUST contain an analysis of how LISP-GPE 
>> SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit 
>> Congestion Notification (ECN) bits whenever they apply to the new 
>> encapsulated payload. The analysis for the new encapsulated payload 
>> registered in this document is in section 3.1."
>>
>>
>> B. [Magnus] draft-ietf-tsvwg-ecn-encap-guidelines has expired 
>> yesterday, and cannot be referenced. I'll add it back to section 3.1 
>> as soon as the draft is refreshed.
>>
>> C. [Magnus/Mirja] in 3.1.1 Payload Specific Transport Interactions 
>> for Ethernet Encapsulated Payloads
>>
>> >>>The UDP Checksum considerations specified in section 5.3 of 
>> [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated Payloads. 
>> Implementors are encouraged to consider the UDP checksum usage 
>> guidelines in section 3.4 of [RFC8085] when it is desirable to 
>> protect UDP, LISP and Ethernet headers against corruption.
>>
>> So this is not the necessary documentation of the analysis that 
>> IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to use. 
>> There needs to be an analysis here to verify that this protocol 
>> combination do work. You will actually have to discuss how the 
>> Ethernet encapsulation fulfills the requirements listed in Section 4 
>> of RFC 6936.
>>
>> https://datatracker.ietf.org/doc/rfc7510/ is an example where such an 
>> analysis was included. I would also note the applicability 
>> limitations this has.
>>
>> Which actually brings up an additional issue for Ethernet 
>> encapsulation. For IP the assumption is that the IP traffic that is 
>> encapsulated is congestion controlled. This assumption is even less 
>> certain when having Ethernet. Thus, some consideration of that issue 
>> is likely needed.
>>
>> >>>When a LISP-GPE router performs Ethernet encapsulation, the inner 
>> 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be 
>> mapped from the encapsulated frame to the Type of Service field in 
>> the outer IPv4 header, or in the case of IPv6 the 'Traffic Class' 
>> field as per guidelines provided by [RFC8325].
>>
>> I don't know enough about IEEE and the various versions of Ethernet 
>> and WLAN here to be certain that 802.1Q PCP's can be mapped directly 
>> to the 802.11 User Priorities discussed in RFC8325. Please 
>> investigate if they are the same, and if they are the same 
>> priorities, then make a explicit statement that they are applicable.
>>
>> D. [Magnus] 3.1.2 Payload Specific Transport Interactions for NSH 
>> Encapsulated Payloads
>>
>> >>> The UDP Checksum considerations specified in section 5.3 of 
>> [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. 
>> Implementors are encouraged to consider the UDP checksum usage 
>> guidelines in section 3.4 of [RFC8085] when it is desirable to 
>> protect UDP, LISP, and NSH headers against corruption.
>>
>> Same as for Ethernet also the NSH header needs to have a documented 
>> analsysis of fulfillment of the requirements.
>>
>>
>> Thanks,
>>
>> Fabio
>>
>>
>>
>>
>>
>>
>> On 9/20/18 1:03 PM, Fabio Maino wrote:
>>> Thanks Magnus,
>>> I'll consolidate the changes we have agreed so far in the next rev 
>>> that I plan to publish later today.
>>>
>>> I'll then work on the comments on this email and will send you the 
>>> corresponding actions.
>>>
>>> Fabio
>>>
>>> On 9/20/18 2:39 AM, Magnus Westerlund wrote:
>>>>
>>>> Hi Fabio,
>>>>
>>>> Most of the below text is excellent. Some comments inline for 
>>>> needed clarifications and additions.
>>>>
>>>> On 9/18/2018 9:52 PM, Fabio Maino wrote:
>>>>> Hi Magnus,
>>>>> thanks for your comments.
>>>>>
>>>>> I think I see the points you are making.
>>>>>
>>>>> I'll add the section 3.1 below to specify the general transport 
>>>>> requirements for the registration of new LISP-GPE payloads, and I 
>>>>> will introduce two subsections to instantiate those requirements 
>>>>> for Ethernet and NSH (section 4.2 and 4.3 will be moved here). In 
>>>>> the "IANA Considerations" section I'll refer to this new section 
>>>>> 3.1 as a requirement for registration of new encapsulated payload.
>>>>>
>>>>> "3.1 Payload Specific Transport Interactions
>>>>>
>>>>> To ensure that protocols that are encapsulated in LISP-GPE will 
>>>>> work well from a transport interaction perspective, the 
>>>>> specification of a new encapsulated payload MUST contain an 
>>>>> analysis of how LISP-GPE SHOULD deal with outer UDP Checksum, DSCP 
>>>>> mapping, and Explicit Congestion Notification (ECN) bits whenever 
>>>>> they apply to the new encapsulated payload.
>>>>>
>>>>> For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis] 
>>>>> specifies how to handle UDP Checksums encouraging implementors to 
>>>>> consider UDP checksum usage guidelines in section 3.4 of [RFC8085] 
>>>>> when it is desirable to protect UDP and LISP headers against 
>>>>> corruption. Each new encapsulated payloads, when registered with 
>>>>> LISP-GPE, MUST be accompanied by a similar analysis.
>>>>>
>>>>> Encapsulated payloads may have a priority field that may or may 
>>>>> not be mapped to the DSCP field of the outer IP header (part of 
>>>>> Type of Service in IPv4 or Traffic Class in IPv6). Such new 
>>>>> encapsulated payloads, when registered with LISP-GPE, MUST be 
>>>>> accompanied by an analysis similar to the one performed in Section 
>>>>> 3.1.1 of this document for Ethernet payloads.
>>>>>
>>>>> Encapsulated payloads may have Explicit Congestion Notification 
>>>>> mechanisms that may or may not be mapped to the outer IP header 
>>>>> ECN field. Such new encapsulated payolads, when registered with 
>>>>> LISP-GPE, MUST  be accompanied by a set of guidelines derived from 
>>>>> [draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].
>>>>>
>>>>> The rest of this section specifies payload specific transport 
>>>>> interactions considerations for the two new LISP-GPE encapsulated 
>>>>> payloads specified in this document: Ethernet and NSH.
>>>>>
>>>>> 3.1.1 Payload Specific Transport Interactions for Ethernet 
>>>>> Encapsulated Payloads
>>>>>
>>>>> The UDP Checksum considerations specified in section 5.3 of 
>>>>> [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated 
>>>>> Payloads. Implementors are encouraged to consider the UDP checksum 
>>>>> usage guidelines in section 3.4 of [RFC8085] when it is desirable 
>>>>> to protect UDP, LISP and Ethernet headers against corruption.
>>>>
>>>> So this is not the necessary documentation of the analysis that 
>>>> IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to 
>>>> use. There needs to be an analysis here to verify that this 
>>>> protocol combination do work. You will actually have to discuss how 
>>>> the Ethernet encapsulation fulfills the requirements listed in 
>>>> Section 4 of RFC 6936.
>>>>
>>>> https://datatracker.ietf.org/doc/rfc7510/ is an example where such 
>>>> an analysis was included. I would also note the applicability 
>>>> limitations this has.
>>>>
>>>> Which actually brings up an additional issue for Ethernet 
>>>> encapsulation. For IP the assumption is that the IP traffic that is 
>>>> encapsulated is congestion controlled. This assumption is even less 
>>>> certain when having Ethernet. Thus, some consideration of that 
>>>> issue is likely needed.
>>>>
>>>>
>>>>>
>>>>> When a LISP-GPE router performs Ethernet encapsulation, the inner 
>>>>> 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be 
>>>>> mapped from the encapsulated frame to the Type of Service field in 
>>>>> the outer IPv4 header, or in the case of IPv6 the 'Traffic Class' 
>>>>> field as per guidelines provided by [RFC8325].
>>>>
>>>> I don't know enough about IEEE and the various versions of Ethernet 
>>>> and WLAN here to be certain that 802.1Q PCP's can be mapped 
>>>> directly to the 802.11 User Priorities discussed in RFC8325. Please 
>>>> investigate if they are the same, and if they are the same 
>>>> priorities, then make a explicit statement that they are applicable.
>>>>
>>>>>
>>>>> When a LISP-GPE router performs Ethernet encapsulation, the inner 
>>>>> header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, 
>>>>> or used to determine the LISP Instance ID field.
>>>>>
>>>>> 3.1.2 Payload Specific Transport Interactions for NSH Encapsulated 
>>>>> Payloads
>>>>>
>>>>> The UDP Checksum considerations specified in section 5.3 of 
>>>>> [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. 
>>>>> Implementors are encouraged to consider the UDP checksum usage 
>>>>> guidelines in section 3.4 of [RFC8085] when it is desirable to 
>>>>> protect UDP, LISP, and NSH headers against corruption.
>>>>
>>>> Same as for Ethernet also the NSH header needs to have a documented 
>>>> analsysis of fulfillment of the requirements.
>>>>
>>>>
>>>>>
>>>>> When a LISP-GPE router performs an NSH encapsulation, DSCP and ECN 
>>>>> values MAY be mapped as specified for the Next Protocol 
>>>>> encapsulated by NSH (namely IPv4, IPv6 and Ethernet)."
>>>>>
>>>>>
>>>>> I will also add a paragraph to "Iana Considerations" that says:
>>>>>
>>>>>
>>>>> "To ensure that protocols that are encapsulated in LISP-GPE will 
>>>>> work well from a transport interaction perspective, the 
>>>>> registration of a new encapsulated payload MUST contain an 
>>>>> analysis of how LISP-GPE SHOULD deal with outer UDP Checksum, DSCP 
>>>>> mapping, and Explicit Congestion Notification (ECN) bits whenever 
>>>>> they apply to the new encapsulated payload. The analysis for the 
>>>>> new encapsulated payload registered in this document is in section 
>>>>> 3.1."
>>>>>
>>>>> Please, let me know if this address your comments.
>>>>>
>>>>> Thanks,
>>>>> Fabio
>>>>>
>>>>>
>>>>>
>>>>> On 8/29/18 2:17 AM, Magnus Westerlund wrote:
>>>>>> Reviewer: Magnus Westerlund
>>>>>> Review result: Not Ready
>>>>>>
>>>>>> This document has been reviewed as part of the transport area directorate's
>>>>>> ongoing effort to review key IETF documents. These comments were written
>>>>>> primarily for the transport area directors, but are copied to the document's
>>>>>> authors and WG for their information and to allow them to address any issues
>>>>>> raised.
>>>>>>
>>>>>> When done at the time of IETF Last Call, the authors should consider this
>>>>>> review together with any other last-call comments they receive.
>>>>>> Please always CCtsv-art@ietf.org  if you reply to or forward this review.
>>>>>>
>>>>>> Issue A.
>>>>>>
>>>>>> The reason I state Not Ready has to do with this documents failure to consider
>>>>>> the use of zero checksum for IPv6 when tunneling other things than IP. The none
>>>>>> GPE version is limited to tunnel IP for which the analysis for use of zero
>>>>>> checksum has been done. Each of the new tunneled protocols that are specified
>>>>>> in this document, i.e. ethernet and NHS, will need to perform the analysis if
>>>>>> they are safe to use zero checksum or not, and if not disallow zero checksum
>>>>>> for IPv6/UDP. The documetn also need a requirement in the registration
>>>>>> requirements to perform this analysis and defined if zero checksum is
>>>>>> acceptable or not.
>>>>>>
>>>>>> Citing Section 5.3 of draft-ietf-lisp-rfc6830bis
>>>>>>
>>>>>>     UDP Checksum:  The 'UDP Checksum' field SHOULD be transmitted as zero
>>>>>>        by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation
>>>>>>        [RFC6935] [RFC6936].  When a packet with a zero UDP checksum is
>>>>>>        received by an ETR, the ETR MUST accept the packet for
>>>>>>        decapsulation.  When an ITR transmits a non-zero value for the UDP
>>>>>>        checksum, it MUST send a correctly computed value in this field.
>>>>>>        When an ETR receives a packet with a non-zero UDP checksum, it MAY
>>>>>>        choose to verify the checksum value.  If it chooses to perform
>>>>>>        such verification, and the verification fails, the packet MUST be
>>>>>>        silently dropped.  If the ETR chooses not to perform the
>>>>>>        verification, or performs the verification successfully, the
>>>>>>        packet MUST be accepted for decapsulation.  The handling of UDP
>>>>>>        zero checksums over IPv6 for all tunneling protocols, including
>>>>>>        LISP, is subject to the applicability statement in [RFC6936].
>>>>>>
>>>>>> The issue is that when LISP encapsulate other protocols the impact of a
>>>>>> missdelivered tunnel packet to the wrong ETR can have different impacts. As
>>>>>> well as errors in the headers of the encapsulated packet that may be assumed to
>>>>>> be protected by the encapsulating layer. Thus, individual analysis of each
>>>>>> protocol that are tunneled are needed.
>>>>>>
>>>>>> B.) 4.2.  Type of Service
>>>>>>
>>>>>>     When a LISP-GPE router performs Ethernet encapsulation, the inner
>>>>>>     802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be
>>>>>>     mapped from the encapsulated frame to the Type of Service field in
>>>>>>     the outer IPv4 header, or in the case of IPv6 the 'Traffic Class'
>>>>>>     field.
>>>>>>
>>>>>> Any recommendation about how to perform that mapping? Maybe parts of
>>>>>> https://datatracker.ietf.org/doc/rfc8325/  are relevant in this context.
>>>>>>
>>>>>> C. General case of 4.2:
>>>>>>
>>>>>> I expect other protocols than Ethernet may have a priority field that may or
>>>>>> may not be mapped to the DSCP field of the tunnel packet.
>>>>>>
>>>>>> I would expect that for new protocol registration in the LISP-GPE Next Protocol
>>>>>> Registry should consider this. Thus, it would be good to note that such
>>>>>> considerations are needed and part of what should be evaluated for new
>>>>>> registrations.
>>>>>>
>>>>>> D. ECN handling
>>>>>>
>>>>>> Section 5.3 of draft-ietf-lisp-rfc6830bis states:
>>>>>>
>>>>>>     o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
>>>>>>        of the IPv6 'Traffic Class' field) requires special treatment in
>>>>>>        order to avoid discarding indications of congestion [RFC3168].
>>>>>>        ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
>>>>>>        header to the outer header.  Re-encapsulation MUST copy the 2-bit
>>>>>>        'ECN' field from the stripped outer header to the new outer
>>>>>>        header.
>>>>>>
>>>>>> The above rules may not be applicable for all transport protocols. Thus I think
>>>>>> it is required that one do protocol specific considerations of ECN. TSVWG are
>>>>>> working on recommendations for tunnels handling of  ECN here, see:
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/  Thus,
>>>>>> my expectation would be to ensure that the registered protocols have defined
>>>>>> ECN handling, explicitly or by reference. Secondly that registration
>>>>>> requirement states the need for this consideration.
>>>>>>
>>>>>> Summary: To ensure that future added protocols that are encapsulated will work
>>>>>> well from a transport interaction perspective there need to be a requirement on
>>>>>> new registration to consider and define how they use zero checksum, any DSCP
>>>>>> mapping and ECN bits. In addition the current document needs to ensure these
>>>>>> things are clearly specified for the encapsulated protocols in this document.
>>>>>>
>>>>>>
>>>>>
>>>> -- 
>>>>
>>>> Magnus Westerlund
>>>>
>>>> ----------------------------------------------------------------------
>>>> Network Architecture & Protocols, Ericsson Research
>>>> ----------------------------------------------------------------------
>>>> Ericsson AB                 | Phone  +46 10 7148287
>>>> Torshamnsgatan 23           | Mobile +46 73 0949079
>>>> SE-164 80 Stockholm, Sweden | mailto:magnus.westerlund@ericsson.com
>>>> ----------------------------------------------------------------------
>>>
>>>
>>
>