RE: [mpls] mpls wg review of draft-ietf-avt-hc-mpls-reqs-03.txt

"Ash, Gerald R \(Jerry\), ALABS" <gash@att.com> Fri, 24 September 2004 17:45 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01166; Fri, 24 Sep 2004 13:45:54 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAuFm-0007j6-UC; Fri, 24 Sep 2004 13:53:11 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAu2B-0001Cy-AW; Fri, 24 Sep 2004 13:39:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAtSV-0008HB-Vu for mpls@megatron.ietf.org; Fri, 24 Sep 2004 13:02:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26170 for <mpls@ietf.org>; Fri, 24 Sep 2004 13:02:09 -0400 (EDT)
Received: from ckmso1.att.com ([12.20.58.69] helo=ckmso1.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAtZV-00064G-1W for mpls@ietf.org; Fri, 24 Sep 2004 13:09:28 -0400
Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i8OH1SN1018494 for <mpls@ietf.org>; Fri, 24 Sep 2004 13:01:36 -0400
Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (7.1.006) id 414DAE590013B4B9; Fri, 24 Sep 2004 13:01:36 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6561.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [mpls] mpls wg review of draft-ietf-avt-hc-mpls-reqs-03.txt
Date: Fri, 24 Sep 2004 12:01:36 -0500
Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE276@KCCLUST06EVS1.ugd.att.com>
Thread-Topic: [mpls] mpls wg review of draft-ietf-avt-hc-mpls-reqs-03.txt
Thread-Index: AcSiNp5fNphPVdEXRG+d6Ppmp+tueQAHvSpg
From: "Ash, Gerald R (Jerry), ALABS" <gash@att.com>
To: Thomas Eriksson <thomas.a.eriksson@teliasonera.com>, loa Andersson <loa@pi.se>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Content-Transfer-Encoding: quoted-printable
Cc: mpls@ietf.org
X-BeenThere: mpls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=subscribe>
Sender: mpls-bounces@ietf.org
Errors-To: mpls-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Content-Transfer-Encoding: quoted-printable

Thomas,

Thanks for the comments.

> Some comments on the draft "draft-ietf-avt-hc-mpls-reqs-03.txt" below:
> 
> "Figure 1 illustrates an HC over MPLS session established on an LSP
that 
> crosses several routers, from R1/HC --> R2 --> R3 --> R4/HD, where
R1/HC is 
> the ingress router where HC is performed, and R4/HD is the egress
router 
> where header decompression (HD) is done. HC of the RTP/UDP/IP header
is 
> performed at R1/HC, and the compressed packets are routed using MPLS
labels 
> from R1/HC to R2, to R3, and finally to R4/HD, without further 
> decompression/recompression cycles."
> 
> The text and also the figure seems to indicate LSPs all the way to
router 
> R4. Would this work with penultimate hop popping?

I see no reason this wouldn't work with PHP.  The egress router does not
necessarily expect a label.

> Do you intend to identify the compressed packet by incoming interface
and 
> SCID? This would work, but matching of SCID at the incoming interface
would 
> demand some extra implementation.

The incoming compressed packet is identified only by the SCID, not the
incoming interface or label.  The proposed mechanism for obtaining
SCIDs, as discussed in the protocol extensions draft
http://ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-protocol-0
1.txt, would ensure unique SCIDs at the egress router.

> When thinking about it some more, could it be a problem with multiple
LSPs 
> terminating at the same incoming interface and compression is used
over 
> them because of colliding SCIDs? Again with PHP.

Yes, it would be a problem.  That's why the protocol extensions draft
proposes a method to ensure unique SCIDs at the egress router.

> Regarding "Extensions to MPLS signaling", I assume that this signaling
is 
> not intended to be done along with the actual LSP setup but rather
between 
> "HC-ingress" and "HD-egress"?

Right.

> Thanks,
> Thomas

Thanks,
Jerry

> -----Original Message-----
> From: mpls-bounces@lists.ietf.org 
> [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Loa Andersson
> Sent: Tuesday, September 21, 2004 9:08 AM
> To: mpls@ietf.org
> Subject: [mpls] mpls wg review of draft-ietf-avt-hc-mpls-reqs-03.txt
> 
> All,
> 
> the avt working group has requested that
> draft-ietf-avt-hc-mpls-reqs-03.txt should be
> published as an Informational RFC.
> 
> Our AD's asks that we (the mpls working group) review
> and comment on the draft.
> 
> Since it is my ambition to send our response on Monday
> please send any comment to me before that.
> 
> /Loa
> 
> -- 
> Loa Andersson
> 
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  loa.andersson@acreo.se

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls