Subject: RE: draft-yasukawa-mpls-rsvp-p2mp-00.txt

From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
Date: Tue, 28 Jan 2003 11:27:17 +0100

Hi Seisho and all

We read your draft with much interest, and consider this is a good
approach for multicast MPLS-TE tunnels.

We have several comments regarding leaf initiated Joining/pruning
procedures, and the interaction with access multicast protocols like
IGMP :

Why does the Join/ leave messages contain the attributes of the P2MP
tunnel (Session, and Sender objects) ? 
This requires a mechanism for the Join leaf node to dynamicaly learn
these attributes.

To our mind, it could be more relevant to include (S,G) or (*, G),or
({S}, {G}) in Join /Leave messages, rather than tunnel parameters. Then
the sender would have knowledge of (S, G) localization, and could
optimise P2MP utilisation (FEC) based on this information.

In this scenario, the sender would have to maintain a table indicating
the registered (S, G) attached to each leaf node.
When a potential leaf node receives an IGMPv3 report message for a new
(S, G), it checks if it already receives this (S, G), if no it sends a
Join message to the sender node, including the (S, G). Then the sender
can either graft an existing P2MP tunnel, or create a new tunnel to
reach this leaf node, depending on local optimization criteria.

Regards

JL and Elodie

-----Message d'origine-----
De : Seisho Yasukawa [mailto:[email-masked]]
Envoye : jeudi 23 janvier 2003 09:45
A : [email-masked]'
Cc : [email-masked]
Objet : draft-yasukawa-mpls-rsvp-p2mp-00.txt

Hello everyone,

Please note that the following draft has been newly posted to MPLS WG.

Extended RSVP-TE for Point-to-Multipoint LSP Tunnels
<draft-yasukawa-mpls-rsvp-p2mp-00.txt>

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-rsvp-p2mp-00.txt

This draft specifies the extension to RSVP-TE signaling protocol
in support of MPLS P2MP LSP creation/deletion and Leaf initiated
Join/Leave signaling.

We think P2MP MPLS technology will become increasingly important
with the dissemination of new, real-time application, such as content
delivery services and video conference, which require P2MP real-time
transmission capability with much more bandwidth and stricter QoS
control mechanism than conventional IP application.

We NTT as a service provider really needs this kind of P2MP MPLS
technology because this technology opens the possibility to offer
our customer a new broadband service.

We think discussion of P2MP technology agrees with the charter of this
wg.
And, we found that applications of "multicast explicit routing"are a
target
topic for "RSVP-TE "(RFC3209, Section 4.3.1) and "IP Multicast in a MPLS
Environment"(RFC3353, Section.7)

Therefore, we want to discuss this P2MP MPLS technology in this wg.

Please give us any comments from technology, application and operation
sides.

We need a lot of discussion and advice for protocol architecture to
improve
this architecture.

Thanks

Seisho

------------------------------------------------------------
Please refere followings (contents of this draft).

This draft include the contents of "draft-yasukawa-mpls-rsvp-p2mp-01".
In this new draft, protocol architecture is modified and the protocol
name
was changed from "multicast" to "P2MP" to clarify the technology
difference.

Section 0 describes why this draft suit to this wg.
Please see sec.0.4 to know the reason why we introduce P2MP tunnel
without IP multicast.

Section 4 describes the architecture of this protocol.
The new concepts; P2MP LSP tunnel and TERO/TRRO are newly introduced.
The TERO is main architecture to realize P2MP TE LSP.

Section 5 - 7 describes the detailed signaling mechanisms.

Section 11 shows the difference between RSVP multicasting and P2MP
TE tunnels.

We describe the difference between multicast LSP realized by
RSVP-TE&IP multicasting and P2MP TE LSP realized by TERO.
---------------------------------------------------------------

---

From: George Swallow <[email-masked]>
Date: Tue, 28 Jan 2003 10:56:31 -0500

> reach this leaf node, depending on local optimization criteria.

I very much agree. This draft is not simply an extension to RSVP for
multicast tunnels.  It actually defines a new multicast protocol.

As such it is:

   a) a mis-use of RSVP (note the thread on IANA Considerations for
      RSVP)

   b) not completely in the scope of the MPLS wg.

While the MPLS wg can look for ways to support multicast, it is not
now (or ever likely to be) in the charter of the workgroup to define a
new multicast protocol.  

RSVP should simply be used to build the tree.  All of the join/leave
activity belongs in a multicast protocol.  

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Seisho Yasukawa <[email-masked]>
Date: Wed, 29 Jan 2003 19:35:57 +0900

Hello George,

I understand your concern about our P2MP draft.
Let me explain our intention and understanding again.

When we propose this draft, we are not intending to develop a new
multicast protocol over conventional RSVP-TE framework.

I think, defining multicast protocol requires
a mechanism which calculates multicast tree in itself.
But our proposed draft doesn't have such a mechanism in itself.

In our design, TERO (Tree Explicit Object) is introduced and
P2MP LSP is established using TERO.
This TERO represents P2MP LSP topology but it is provided by
external mechanism (e.g. NW management system).

In this way, our protocol doesn't define multicast tree calculation
mechanism in protocol itself as multicast protocol do.

And we evaluate that this extension is consistent with TE
extension to RSVP (RSVP-TE) and in the scope of RSVP-TE
extension.

So we think this is acceptable and in the scope of the
MPLS wg.

And we want to discuss this extension at MPLS wg
because we think this wg is most appropriate place
when considering situation discussed over the thread
on IANA Considerations for RSVP.

But I totally agreed with you in the point that introducing Join/Leave
mechanism might enhance the function exceeding the scope of
MPLS wg.

We want to know what modification is required to our draft
in order to fit in the scope.
We will modify our specification if necessary because we want
this technology.

And we want to know how should we process this work in this wg.

It is very helpful for us if you or anybody in this list give us some
suggestion to these issues.

Thanks,

Seisho