The MPLS WG Archive

["Kullberg, Alan" <akullber@netplane.com>]

Hi Loa,

You are correct on all points.  We would like feedback and discussion
regarding our draft.

Thanks,

Alan

> -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.se]
> Sent: Thursday, January 23, 2003 2:08 PM
> To: Seisho Yasukawa
> Cc: 'mpls@UU.NET'
> Subject: Re: draft-yasukawa-mpls-rsvp-p2mp-00.txt
> 
> 
> All,
> 
> I've received a couple of questions if this is a working group draft.
> Answer is that it is not, a previous draft was presented in Atlanta
> and (I think in Yokohama), the name change makes it go back to -00.
> In Atlanta we said that "the discusion will contiune on the list".
> 
> Possibly the misunderstanding comes from the first line in
> the mail:
> "Please note that the following draft has been newly posted 
> to MPLS WG."
> 
> my understanding here is that this a request from the authors to
> have comments on the draft and discusion on the subject matter.
> 
> /Loa
> 
> 
> Seisho Yasukawa wrote:
> > 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-p
> 2mp-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.
> > ---------------------------------------------------------------
> > 
> > 
> > 
> 
> 
> -- 
> Loa Andersson
> 
> Mobile          +46 739 81 21 64
> Email           loa@pi.se
> 
>