[Mobopts] RG Last Call for draft-irtf-mobopts-mmcastv6-ps-04.txt - Response

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Sat, 27 September 2008 16:50 UTC

Return-Path: <mobopts-bounces@ietf.org>
X-Original-To: mobopts-archive@megatron.ietf.org
Delivered-To: ietfarch-mobopts-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96FC63A68A3; Sat, 27 Sep 2008 09:50:13 -0700 (PDT)
X-Original-To: mobopts@core3.amsl.com
Delivered-To: mobopts@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1470A3A659A for <mobopts@core3.amsl.com>; Thu, 25 Sep 2008 01:47:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.508
X-Spam-Level:
X-Spam-Status: No, score=-0.508 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PInmMYQYDqDy for <mobopts@core3.amsl.com>; Thu, 25 Sep 2008 01:47:37 -0700 (PDT)
Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 2DED83A63D3 for <mobopts@irtf.org>; Thu, 25 Sep 2008 01:47:36 -0700 (PDT)
Received: from Gorry-Fairhursts-Laptop.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m8P8hMKd005476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Sep 2008 09:43:23 +0100 (BST)
Message-ID: <48DB4F23.5030503@erg.abdn.ac.uk>
Date: Thu, 25 Sep 2008 09:43:15 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683.
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
MIME-Version: 1.0
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk
X-Mailman-Approved-At: Sat, 27 Sep 2008 09:50:12 -0700
Cc: Gorry <gorry@erg.abdn.ac.uk>, "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>, mobopts@irtf.org
Subject: [Mobopts] RG Last Call for draft-irtf-mobopts-mmcastv6-ps-04.txt - Response
X-BeenThere: mobopts@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: Mobility Optimizations <mobopts.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mobopts>
List-Post: <mailto:mobopts@ietf.org>
List-Help: <mailto:mobopts-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: mobopts-bounces@ietf.org
Errors-To: mobopts-bounces@ietf.org

Cedric Baudoin sent the email below (see the following discussion with 
my response), and has kindly allowed me to forward to the RG as a prt of 
the LC process. Please see email below.

cedric.baudoin@thalesaleniaspace.com wrote:
> Hi Gorry
  >
> Here are some comments on the document:
  >
> First, I really like the document structure and the way the problem is
> described. Our work has mainly focussed on group management issues
> (for source and receivers), and the doc addresses the other side of
> the problem (i.e. multicast routing). To conclude, IMHO the problem
> description is almost exhaustive(and clear :-).

> I think that you should put emphasis on the problem of non capable
 > multicast networks (2.2.1), that can lead to discard some
 > (more efficient)
> solutions, or to have something able to adapt to the context.
 >
So, currently the draft says:
"In the latter case, it may encounter either one of the
following conditions: The new network may not be multicast-enabled or
the specific multicast service may be unavailable, e.g. unsupported
or prohibited. Alternatively, the requested multicast service may be
supported and enabled in the visited network, but the multicast
groups under subscription may not be forwarded to it. This means that
current distribution trees for the desired groups may only be re-
joined at a large routing distance. The simplest scenario is when
packets of some, or all, of the subscribed groups of the mobile node
are already received by one or several group members in the
destination network, and thus multicast streams natively flow after
the MN arrives at the new network.

I suggest replacing this with:
"In the latter case, the MN may encounter one of the
following conditions:
* The simplest scenario is when packets of some, or all, of the
subscribed groups of the mobile node are already received by one or
several other group members in the new network, and thus multicast
streams natively flow after the MN arrives at the new network.
* The requested multicast service may be supported and enabled in the
visited network, but the multicast groups under subscription may not be
forwarded to it. This means that current distribution trees for the
desired groups may only be re-joined at a large routing distance.
* The new network may not be multicast-enabled or the specific multicast
service may be unavailable, e.g. unsupported or prohibited. This means
that current distribution trees for the desired groups need to be
re-joined at a large routing distance by (re) establishing a tunnel  to
a multicast-enabled network node."


> Another problem is linked with the context transfer solution if there
 > is no more connexion to the previous visited network.
 >
Yes - I see this is something we should highlight. I think the initial
perspective presumed the context state was stored within a network node
that was reachable before and after the move. But there could be cases
were the MN is no longer in contact with the previous network, when at
the new location. In this case, the network itself can not assist in the
context transfer. Such a case could happen when moving from one
technology/operator domain to another. Would require a backwards
compatible way to recover from loss of connectivity to the node with the
context?

This could be related as an issue in 5.2.1?

cedric.baudoin--> Yes

> Another important issue in solution where a host and the proxy are
> simultaneously member of a group is the waste of bandwidth can can be a
> severe drawback for some access networks (this is mentioned in the
 > draft).
 >
Yes, that's a trade-off that needs to be made.

> In 4.2.4, you do not discuss about S2 & GSE (this is clearly the next
> evolution of the RCS/S2 products).
 >
If the technology is also applicable, we could consider including some
background text, e.g.:

4.2.5 Multicast over TV broadcast and satellite networks

IP multicast may be enabled in TV broadcast networks, including those
specified by DVB, ATSC, and related standards [51]. These standards are
also used for one and two-way satellite IP services. Networks based on
the MPEG-2 Transport Stream may support either the multi-protocol
encapsulation (MPE) or the unidirectional lightweight encapsulation
(ULE) [RFC4326]. The second generation DVB standards allow the Transport
Stream to be replaced with a Generic Stream, using the generic stream
encapsulation (GSE) [RFC5163]. These encapsulation formats all support
multicast operation.

In MPEG-2 transmission networks, multicast distribution services are
defined by a mapping of groups onto appropriate PIDs, which is managed
at the IP Encapsulator [51]. The addressing issues resemble those for
DVB-H (section xxxx) [50]. The issues for using GSE resemble those for
ULE (except the PID is not available as a mechanism for filtering
traffic) [50]. Networks that provide bidirectional connectivity may
allow active service subscription (multicast join) to initiate
forwarding from the upstream IP Encapsulator / gateway.

cedric.baudoin --> Some kind of filtering can be achieve using the ISI 
field.

But, we'd need to add references to:
[RFC4326]
[RFC5163]

> Regarding address transparency, you may also introduce HIP (and the RSV),
> as a way to achieve and simplify mobility . CBA can be also mentioned
>
Hmmm...

We don't consider HIP [RFC5206] with multicast. I thought HIP was
intended for unicast upper layer protocols (is there more I should
know?) I see there has been some discussion on use with multicast... I
don't know what happened to MOBIKE for instance, does anyone recall this
story?

[draft-vogt-mobopts-simple-cba-00.txt]

 > Last though, I fell that network mobility solutions, and in particular
 > impact due to route optimization is not clearly addressed here
 >
Does anyone wish to comment on this?

> Br
>
> Cédric
>

Thinking on these topics, should section 6 also note that there are
security implications in introducing Agents within the network to assist
in multicast mobility. Issues concern the potential need for
authentication, protection of user-specific subscription information,
and methods to mitigate denial of service attacks.

>
> -------- Original Message --------
> Subject:           [Mobopts] RG Last Call for
> draft-irtf-mobopts-mmcastv6-ps-04.txt
> Date:              Mon, 8 Sep 2008 14:41:24 -0400
> From:              Koodli, Rajeev <rkoodli@starentnetworks.com>
> To:          <mobopts@irtf.org>
>
> Hello folks,
>
> This is to initiate a LC for the Multicast Mobility document.
>
> This document has already gone through some good reviews resulting in
> the current version. However, we need broader review from the RG folks,
> in order to progress this (and other RG) documents.
>
> Please provide your comments by September 26.
>
> ID URL: http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-04
>
>
> Thanks,
>
>
> -Rajeev
>
>
> --
> Dr Gorry Fairhurst, School of Engineering.
> The University of Aberdeen is a charity registered in
> Scotland No SC013683.
> _______________________________________________
> Mobopts mailing list
> Mobopts@ietf.org
> https://www.ietf.org/mailman/listinfo/mobopts
>
>
>
>
>
>
> Research Department/Advanced Telecom Satellite Systems
> Tel : +33 (0)53435 6817  /  Fax : +33 (0)53435 5560
> Porte : W153  /  E-Mail : cedric.baudoin@thalesaleniaspace.com
>
>
>





Research Department/Advanced Telecom Satellite Systems
Tel : +33 (0)53435 6817  /  Fax : +33 (0)53435 5560
Porte : W153  /  E-Mail : cedric.baudoin@thalesaleniaspace.com



_______________________________________________
Mobopts mailing list
Mobopts@ietf.org
https://www.ietf.org/mailman/listinfo/mobopts