Re: [netext] Brian's review comments on draft-ietf-netext-pmip6-qos-08.txt

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Mon, 09 December 2013 22:29 UTC

Return-Path: <sgundave@cisco.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A98C1AE60D for <netext@ietfa.amsl.com>; Mon, 9 Dec 2013 14:29:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level:
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 HSj0VjJb8_Zp for <netext@ietfa.amsl.com>; Mon, 9 Dec 2013 14:29:13 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id B95991AE601 for <netext@ietf.org>; Mon, 9 Dec 2013 14:29:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1517; q=dns/txt; s=iport; t=1386628149; x=1387837749; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Fu8yj1eodlraouICXQAFZMhlPJkxVSKqel3sQ3NXkmI=; b=eO5EJ22s/oEErMgkDzgsUpI1A/tT/6n1zvgDsemY2vA1Nfd8njgJurQU BS8TiAiWqd7hkZd1Y+iolrqAmTIVRvFbal4HQco6Z/2OwzyozGPI2bsiB OOjhKalj/+tqwa91dwzojGv51NcH7+85iP+iPkqwQI1ESyLDDahA0hw9i A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoMFAGlDplKtJXG+/2dsb2JhbABZgweBC7kWgSwWbQeCJQEBAQQ6UQEIGB5CJQIEE4gCohueTheOXTqEMwOYFJITgymCKg
X-IronPort-AV: E=Sophos;i="4.93,860,1378857600"; d="scan'208";a="5525326"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-5.cisco.com with ESMTP; 09 Dec 2013 22:29:08 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB9MT815011204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <netext@ietf.org>; Mon, 9 Dec 2013 22:29:08 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.155]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 16:29:08 -0600
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: "netext@ietf.org" <netext@ietf.org>
Thread-Topic: Brian's review comments on draft-ietf-netext-pmip6-qos-08.txt
Thread-Index: AQHO9S0rDL1xVF1YCUiw4/NdtdZNYppMUEIA
Date: Mon, 09 Dec 2013 22:29:08 +0000
Message-ID: <CECB8418.F5EE0%sgundave@cisco.com>
In-Reply-To: <CECB8274.F5ED0%sgundave@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.212]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <BF82E17EA628FD439B12451DC28762A5@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [netext] Brian's review comments on draft-ietf-netext-pmip6-qos-08.txt
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext/>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 22:29:15 -0000

FYI


>
>
>On 12/9/13 9:04 AM, "Brian Haberman" <brian@innovationslab.net> wrote:
>
>>All,
>>     Here are my comments on this draft...
>>
>>1. Somewhere in the front matter of the draft, there should be some
>>discussion as to why existing QoS signaling mechanisms are not used
>>(e.g., RSVP).
>>
>>2. Section 2.2 refers to the Allocation and Retention Priority option as
>>ARP and AARP.  I assume AARP is a typo (but ARP is also an unfortunate
>>overload...).
>>
>>3. Is there any expectation for infrastructure devices between the MAG
>>and LMA to provide QoS services for these flows?  If so, how?  With the
>>QoS information embedded in PMIP messages, how would these intermediate
>>devices know anything about these QoS parameters and any associated
>>Per-Hop-Behaviors?  This needs some discussion in the draft to ensure a
>>consistent deployment view.
>>
>>4. Section 4.1 says that if M=1, D=0, but there is no discussion of what
>>to do if M=D=1 occurs.  Is the option ignored?
>>
>>5. I am curious as to why a 5-bit Service Request ID is sufficient.  You
>>have bits available in the Resvd field... Wouldn't an 8-bit field make
>>operations/comparisons easier?
>>
>>6. Section 4.2 only describes bit-rate-based attributes.  Is this due to
>>use cases described in other SDOs?
>>
>>7. What is the handling if there is a conflict between a per-node QoS
>>attribute and a set of per-flow QoS attributes associated with that node?
>>
>>Regards,
>>Brian
>>
>