The MPLS-OPS Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Re: P2MP LSP and Multicast for BGP/MPLS VPN
Hi, Yup, the P2MP RSVP draft is probably not the place to start your reading. I suggest starting with draft-ietf-mpls-p2mp-sig-requirements which should give you the terminology and set out the requirements that the solutions draft is trying to address. draft-ietf-mpls-rsvp-te-p2mp (the solutions draft) is something of a work in progress, but is getting there. Other drafts that might be of relevance to you can be found in the L3VPN working group. There you will find a base requirements draft for multicast MPLS VPNs (draft-ietf-l3vpn-ppvpn-mcast-reqts). There have also been several proposed solutions drafts for multicast VPNs (draft-rosen-vpn-mcast, draft-raggarwa-l3vpn-mvpn-vpls-mcast, and draft-yasukawa-l3vpn-p2mp-mcast), and work is well-progressed to combine these efforts into a new single draft that will be published soon. You are also right that scalability is one of the important concerns to be addressed in the solutions and moving the data replication away from the PE and into the network is an important feature. Your specific suggestions for protocol extensions are worth consideration and you should bring them to the MPLS working group (discussed here on this list they may not get the full attention you would wish). Functionally, the ideas you suggest are similar to those in the solutions draft. But finally, your discussion seems more suited to an LDP-based approach than to RSVP-TE. This is certainly feasible, and I know that several people are interested in such technology. The work in the MPLS working group at the moment is focused on RSVP-TE partly because that gives traffic engineering capabilities in the P-core. Regards, Adrian ----- Original Message ----- From: "M. ELK" <elkou141061@hotmail.com> To: <mpls-ops@mplsrc.com> Sent: Monday, March 14, 2005 7:16 PM Subject: [MPLS-OPS]: P2MP LSP and Multicast for BGP/MPLS VPN > > Hi > > As non educated opinion i guess that Multicast is only possible and scalable > with the P2MP LSP > feature . For the P to get involved in multicast is a BAD idea . > > Started to read the P2MP RSVP draft , but realized that reading such draft > is not the job U do at the end of the working day (not so easy with many new > confusing -at least for me -terminology) . > > Though about this simple (naive) approah , what do U think ?? > > > > PE1-------P1--------P2-------P3---(toward PE2,PE3,PE4 ) > ! > !-----P4---(sub netw toward PE5,PE6,PE7) > > The ingress PE (PE1) will initiate a seperate RSVP-TE LSP to each Egress > (PE2,...PE7). > Total = 6 RSVP-TE . > All the 6 RSVP-TE will have an extra properties (new object) which function > as an indication that > they belong to the same group . let us call it group-ID . > let say that L1 to L6 are the label recieved for the 6 LSP . > PE1 will send RSVP Group-request msg (new msg to be defined) to P1 , the > msg contain the Group-ID . > P1 will respond with Group-Rely msg with label "L7" . > which mean if U send me a packet with top label "L7" i will replicate it as > if i recieved 6 packet > with L1 to L6 as top label . > > P1 could also send Group-request to P2 . > P2 will reply with Group-reply with label 200 . > Now ,P1 when recieve a packet with Top label 7 ,it will not replicate it > just swap 7 with 200 and forward to P2. > > P2 will send to P3 and P4 a Group-Request MSG , P3 reply with label 300 and > P4 with label 400. > when P2 recieve a label with 200 , it will be replicated as : 1) with top > label 300 to P3 . > and 2) with top label 400 to P4 . > > ..etc . > > the above considered ordered mode ,but independent mode is also possible . > ex: P2 will notice that their 3 LSP going through P3 have the same Group-ID > so it could initiate > a Group-Request msg . > > Let us say that PE1 in addition to sending a stream to the 6 PE's need also > at the same time to send another stream to PE2 and PE5 only . > > PE1 send a group-Request with the Group-ID but it contain the label L2 and > L5 . > P1 will repy with Group-reply and label 10. > > P1 will send a grou-request to P2 with label L2 and L5 (assume same label > advertized by P3 ,just > for simplicitly) ,P2 will reply with label 210 . > > P2 will not send group-request with label L2 to P3 neither a Group-Request > with Label L5 to P4 . > as it is a branching point and the nbr of label is just 1 . > > For stream from PE1 to PE2 and PE5 , PE1 will send a packet with top label > 10 , > P2 will swap label 10 with label 210 and forward to P3. > P3 will replicate the packet , one copy with label L2 toward P3 . other copy > with label L5 to P4. > > > The advantage : > the same 6 LSP used to send to all the PE's or to any combination . > the RSVP-TE protocol is not changed must still it follow the rule of P2P . > the intermediate node do not get involved in the complexity of P2MP . > > Pls comments. > > Brgds > > _________________________________________________________________ > Express yourself instantly with MSN Messenger! Download today it's FREE! > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > > MPLScon 2005 - May 16-19, NYC, NY > http://www.mplscon.com/ > > ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml MPLScon 2005 - May 16-19, NYC, NY http://www.mplscon.com/
|
|