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

From: Seisho Yasukawa <[email-masked]>
Date: Tue, 28 Jan 2003 21:16:01 +0900

Hello JL and Elodie,

Thank you for useful comments and suggestions.
Please find my answers and comments in-line.

>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) ?

The reason why these messages contain both objects is that this
protocol uses both objects to identify P2MP LSP tunnel uniquely.
And this Join/Leave architecture is consistent with other message
architecture, like Path/Path(Graft)/Path(Prune) message.
This protocol prepare same interface to LSP handler (who setup and
modify LSP) in regard to LSP identification.
In another word, this protocol assumes that all LSP handler knows
same tunnel information.
And we think this is also consistent to conventional P2P RSVP-TE
idea and architecture.

>This requires a mechanism for the Join leaf node to dynamicaly learn
>these attributes.

Yes, I agree your point.

>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.

I like this kind of approach.
As you suggested, I also think your proposal could be more relevant
if a P2MP LSP convey single IP Mcast group traffic.
One of my concern is what should we do when a P2MP LSP conveys
multiple IP Mcast group traffic.
Maybe we can resolve this issue by same mechanism.
But, I think we need some sophisticated algorithm in sender/leaf node.
And another concern is what should we de when a P2MP LSP conveys
non-IP Mcast traffic.
Considering these situation, we choose both objects for LSP identifier.

>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.

I like this approach.
So, if you have any solution to above problems, please teach us your
solution.

And we think this technology can also applicable to
P2MP backbone technology for Wireless LAN (hot spot) and CATV network
in addition to content delivery network which is mentioned in draft.
Using this technology, we can provide broadcast service
in these network economically.

We want to discuss service applicability issues with you
if you have some interest in this issue.

Thanks,

Seisho

>-----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: Robert Raszuk <[email-masked]>
Date: Tue, 28 Jan 2003 14:15:38 +0100

Hi Seisho,

> multiple IP Mcast group traffic.

I think both cases for p2mp LSP carrying single and multiple multicast
groups should be supported. Further it would be up to the IGMP report
recepient to make the decision if new LSP needs to be created or if any
of his present LSPs can be extended (for example by changing constrains
in the shared explicit way) to carry new multicast group(s). 

> Considering these situation, we choose both objects for LSP identifier.

If you are planning to use any P2MP LSP for multiple groups pipe how do
you calculate tunnel id ? In other words if all multicast packets will
arrive at the egrees unlabed (PHP) or even labeled (no PHP) are you
assuming another IP lookup/RPF check to send it to receivers ?

In other words maybe at some point just lookup on the LFIB would be in
order and label stack would be the tool ? Just trying to make sure that
forwarding wise egress performance will be doable. Another interesting
point is that there could be cases (transient or permanent) that some
received groups should be filtered on the egress of the P2MP LSP rather
then always forwarding it to the potential receiver. Dropping them based
on the label is much more eficient then processing by CPU and dropping
later ;).

Also considering that LSPs are unidirectional (well at least today in
some implementations :) it would be nice to address explicitely how and
if RPF on egrees should be performed.

Thx,
R.

> Seisho Yasukawa wrote:

---

From: Seisho Yasukawa <[email-masked]>
Date: Wed, 29 Jan 2003 22:30:37 +0900

Hello Robert,

Thank you for useful comment.

>groups should be supported.

I agree with you.
Our current design support both cases.

>Further it would be up to the IGMP report

We assume another IP lookup at egress LSR.to send multicast packets
to recivers.
And we don't assume any RPF check because this draft can be
applicable to non-IPmulticast network.

>forwarding wise egress performance will be doable.

Could you clarify above question in more detail ?
We also assume this issue is very important when we implement real
P2MP LSR.

>Another interesting

I agree that in some case, it is more efficient to filter some group traffic
on the egress.
Using this technique, we can avoid leaf-initiated Join/Leave mechanism
and make IGMP interwork more simple.
But I cannot understand detail architecture of your suggestion,
Could you clarify the meaning of last sentence.
" Dropping them based on the label is ........"

>if RPF on egrees should be performed.

Yes, we need some mechanism that address explicitely how and if
RPF on egress should be performed when we consider system implementation.

Thanks,

Seisho