Subject: [multimob] draft-ietf-multimob-pmipv6-base-solution in the IESG

From: Jari Arkko <[email-masked]>
Date: Thu, 27 Jan 2011 00:24:15 -0800

This draft was discussed in the IESG meeting last week.

A couple of changes were brought up by a number of ADs:

1. BCP vs. Informational

The IETF BCP document class is reserved for a number of different 
purposes, including describing practices that are widely deployed and/or 
highly or urgently recommended. It was felt that given the deployment 
situation of multicast in PMIP networks that Informational would be a 
more suitable document class. Please remember that the IETF RFC 
boilerplate was recently changed. "Informational" RFC from the IETF is 
by no means an unimportant classification. Documents that have gone 
through the IETF Last Call will for instance, contain the following 
statement:

   It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).

2. RFC 2119 keywords

It was felt that as the document does not change the behaviour of 
existing specifications, just explain how to use them in a proper way, 
we should not use RFC 2119 keywords.

I have added RFC Editor notes and changed the datatracker document 
status field accordingly.

In addition, the following question from Ralph Droms should be answered:

> If I'm reading the document correctly, the LMAs arrange to receive
> multicast streams and forward the streams to the MAGs, which then
> forward the streams to subscribed MNs.
>
> In figure 1, suppose MN1, associated with LMA1, and MN2, associated
> with LMA2, are both associated with multicast stream MC.  Will MAG1
> receive copies of MC from both LMA1 and LMA2?
>
> Was a design considered in which the MAG arrange directly for the
> delivery of multicast streams as required by attached MNs?
>   

Jari

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 27 Jan 2011 10:31:20 +0100

I answered the questions of Ralph on Jan. 19th (see attached).

If it felt that the answer is not satisfying / exhaustive, please let me 
know. I'll be happy to provide further input.

Thanks,

Thomas

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

Subject: Re: Ralph Droms' Discuss on draft-ietf-multimob-pmipv6-base-solution-07: (with DISCUSS)
From: "Thomas C. Schmidt" <[email-masked]>
To: Ralph Droms <[email-masked]>
Cc: The IESG <[email-masked]>, [email-masked], [email-masked]
Date: Wed, 19 Jan 2011 18:31:39 +0100

Dear Ralph,

thanks for overlooking the document. Please see answers inline.
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>

Yes, that's correct.

> receive copies of MC from both LMA1 and LMA2?

Yes, it will. This is the result of "limited" PMIP awareness of 
multicast management at the MAG - it acts just as a standard MLD proxy.

> delivery of multicast streams as required by attached MNs?

An explicit coordination of multicast management at MAGs with respect to 
different MN <-> LMAs bindings was out of scope for this document, as 
this would require new protocol operations. The charter only permitted 
the re-use of existing protocols.

The alternative approach,  to limit the deployment of multicast-enabled 
LMAs in PMIP to one single entity (that requires no coordination), is 
discussed/compared in Appendix C.

A further direction to avoid duplicate packet delivery at MAGs is 
discuseed in Section 4.6. "Multicast Availability throughout the Access 
Network". This option requires multicast to arrive at the MAGs natively 
by other means, e.g., all MAGs have a common access to *one* multicast 
delivery network.

To my understanding, these directions explore the solution space for 
protocol re-uses.

Solutions that optimize multicast streams jointly with handover 
performance (context transfer) are future work in Multimob.

Thanks,

Thomas

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °