The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] draft-yasukawa-mpls-rsvp-p2mp-00.txt
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 >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
|
|