On Sun, Mar 22, 2020 at 4:45 PM Gyan Mishra <hayabusa...@gmail.com> wrote:
> > > On Sat, Mar 21, 2020 at 3:22 PM Rishabh Parekh <risha...@gmail.com> wrote: > >> Gyan, >> >> >The SR replication segment tree sid draft states that it can only be >> used for PCE centralized controller model. >> >I am guessing BIER maybe an option? >> >> Strictly speaking, BIER is not SR dataplane, but yes it is an option. > > > So BIER technically can be used with SR but has its own BIFT > forwarding table. Understood. > > For the WG question I posed is that if LDP is eliminated from SP core and > you don’t want to use RSVP-TE and BIER is not yet available and SR > replication tree SID draft can only be used if a centralized PCE is > utilized what alternatives or options does the operators have? > > Also if PCE is configured on SR source node in a hybrid model and BGP > prefix SID is advertise by PCC elements in IGP via BGP LS propagation would > that be an option for SR-MPLS multicast P2MP and MP2MP LMDTs? > >> >> >> Any other options for operators? >> >> LDP with RFC 7473 can be used just for mLDP LSPs. >> > > So in the case where you have LDP still enabled in the core and have > SR-PREFER configured so all L3 vpn unicast traffic is using SR-MPLS > forwarding plane - so then for multicast to work to use mLDP data plane > this draft and what you are saying for that to work is you have to > configure a knob to disable FEC root prefix lsp. Not sure how that would > work as that mldp fec binding for mLDP core p-tree gloabal is PSMI/UI/MI/S > MVPN instantiation of the tree how would that even work. > > There is some XR knob I am missing to get this working and is key for any > mLDP MVPN profiles Verizon will be using. > > > > 6.4 <https://tools.ietf.org/html/rfc7473#section-6.4>. Disabling Prefix-LSPs > on an mLDP-only Session > > Assume that LSR1 and LSR2 have formed an LDP session to exchange mLDP > state only. In typical deployments, LSR1 and LSR2 also exchange > bindings for IP (unicast) prefixes upon mLDP session, which is > unnecessary and wasteful for an mLDP-only LSR. > > Using the procedures defined earlier, an LSR can indicate its > disinterest in Prefix-LSP application state to its peer upon session > establishment time or dynamically later via an LDP capabilities > update. > > In reference to Section 3.1 > <https://tools.ietf.org/html/rfc7473#section-3.1>, the peer disables the > advertisement of > any state related to IP Prefix FECs, but it still advertises IP > address bindings that are required for the correct operation of mLDP. > > > I found the RFC 7473 sac knob for SR for capability exchange for > mldp-only and configured on PEs first still no change in MRIB state on > egress PE > > then added knob to all Ps as well and still no change. We can continue > "off list". Thanks. > RP/0/RP0/CPU0:PE1-XRV9k#sh run mpls ldp Sun Mar 22 23:12:24.127 UTC mpls ldp ! *capabilities sac mldp-only * > > -Rishabh >> >> On Sat, Mar 21, 2020 at 11:11 AM Gyan Mishra <hayabusa...@gmail.com> >> wrote: >> > >> > >> > Thank you Rishabh! >> > >> > I will contact you regarding Cisco specific questions. >> > >> > The questions apply to multicast support with SR-MPLS and are not >> vendor specific however I am using Cisco as an example. >> > >> > From a IETF standards perspective, I believe the one question that this >> thread is related is with multicast SR-MPLS support use case where you are >> migrated to SR-MPLS and LDP has been removed from the SP core. >> > >> > In this customer use case where the customer does not want to use RSVP >> TE or IR due to replication processing overhead in a distributed model what >> options are available for multicast support. >> > >> > The SR replication segment tree sid draft states that it can only be >> used for PCE centralized controller model. >> > >> > I am guessing BIER maybe an option? >> > >> > Any other options for operators? >> > >> > Kind regards >> > >> > Gyan >> > >> > On Sat, Mar 21, 2020 at 1:49 PM Rishabh Parekh <risha...@gmail.com> >> wrote: >> >> >> >> Gyan, >> >> These questions are implementation specific and should be addressed >> >> off the mailing list. Please contact me at ripar...@cisco.com. >> >> >> >> -Rishabh >> >> >> >> On Fri, Mar 20, 2020 at 6:41 PM Gyan Mishra <hayabusa...@gmail.com> >> wrote: >> >> > >> >> > >> >> > Daniel & Authors >> >> > >> >> > I had a question related to the draft related to lab POC testing. >> >> > >> >> > >> https://datatracker.ietf.org/doc/draft-voyer-spring-sr-replication-segment/ >> >> > >> >> > In the draft it states that SR replication using Tree SID to >> replication to leafs on a tree is only supported with a centralized PCE >> controller based model using BGP LS. >> >> > >> >> > I have an SR-MPLS Cisco VIRL POC test bed using XRV9000 nodes 7.0.1 >> using ISIS SR extensions where I have L3 vpn overlay and everything is >> working very well from a unicast perspective. No issues. >> >> > >> >> > I have LDP still enabled but via “SR-Prefer” am using SR-MPLS >> forwarding plane. I kept LDP enabled so I can use mLDP for LMDT label >> switched trees for multicast and technically that all MVPN procedures RFC >> 6513 6514 encap tunnel types should work for p-tree using mLDP forwarding >> plane for multicast while SR-MPLS is being used for unicast.. >> >> > >> >> > I can get the LMDT core tree default and data mdt to build for MP2MP >> or P2MP tree but cannot get on the FEC root the MRIB state to build. Not >> sure why? >> >> > >> >> > Any ideas. Is there anything special I have to do for multicast to >> use the ldp mLDP extension data plane and not the SR-MPLS data plane. >> >> > >> >> > I think what’s happening is at the data plane forwarding level >> SR-MPLS data plane is being used instead of mLDP. >> >> > >> >> > I have a bunch of SR-TE policies in place with candidate dynamic and >> static ERO paths and that works well coloring the VRF steering. >> >> > >> >> > I was wondering if I can use SR-TE binding Sid with Static ERO loose >> path using prefix SID of egress PE to replicate to and build P2MP tree >> instantiation via SR-TE. >> >> > >> >> > Is that possible? >> >> > >> >> > Kind regards >> >> > >> >> > Gyan >> >> > >> >> > >> >> > -- >> >> > >> >> > Gyan Mishra >> >> > >> >> > Network Engineering & Technology >> >> > >> >> > Verizon >> >> > >> >> > Silver Spring, MD 20904 >> >> > >> >> > Phone: 301 502-1347 >> >> > >> >> > Email: gyan.s..mis...@verizon.com >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > spring mailing list >> >> > spring@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/spring >> > >> > -- >> > >> > Gyan Mishra >> > >> > Network Engineering & Technology >> > >> > Verizon >> > >> > Silver Spring, MD 20904 >> > >> > Phone: 301 502-1347 >> > >> > Email: gyan.s.mis...@verizon.com >> > >> > >> > >> > -- > > Gyan Mishra > > Network Engineering & Technology > > Verizon > > Silver Spring, MD 20904 > > Phone: 301 502-1347 > > Email: gyan.s.mis...@verizon.com > > > > -- Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mis...@verizon.com
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
