Hi Robin, Thanks for your interest in SPRING/Segment Routing. Please see inline [Bruno]
Regards, Bruno From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Lizhenbin Sent: Sunday, January 18, 2015 7:28 AM To: spring@ietf.org Cc: m...@ietf.org Subject: [mpls] New Comments on Segment Routing(2): Challenge of Proxy Egress for SR-BE Path Hi all authors of segment routing, This is the second issue. In order for better understanding and discussion, I include MPLS WG in the discussion. I will propose one use case of LDP proxy egress: Inter-AS VPN Option C PE11--------ASBR11--------ASBR21-------PE21 | | | | | AS1 | | AS2 | | | | | PE12--------ASBR12--------ASBR22-------PE22 In this case, the label BGP(RFC3107) can advertise the label route for PE21 and PE22 from the ASBR in AS2 to the ASBR in AS1. Some carriers prefers to use label BGP to go on to advertise the label route to PE11 and PE12. But some carriers do not like full mesh BGP peers and three layer label for the traffic, they would redistribute the BGP routes to IGP at ASBR11/ASBR12 and depend on LDP to setup LDP LSP for the prefix PE21/PE22 in the AS1. For the use case if the SR is adopted, there may propose following challenges: 1. How to configure the SID/label for these proxy egress addresses? [Bruno] I a priori see 3 options, but this is open for discussion 1- If you want to use MPLS hierarchy. ASBR1x advertise in IGP the SIDs/MPLS labels as local labels. PE11 will need to use a 2 label stack: Node_SID(ASBR1x), Prefix_SID (PE2y). 2- If you don't want to use MPLS hierarchy: a. ASBR1x only advertise the IP reachability. The SID mapping is advertised by the mapping server. b. Assuming AS2 also use SPRING, then the real issue is the redistribution between protocols. IGP->BGP->IGP. This can be done with a BGP extension to carry the SID. e.g. https://tools.ietf.org/html/draft-keyupate-idr-bgp-prefix-sid-00 On both ASBR11 and ASBR22? If there more ASBRs, there will be more configuration work. Is it right? [Bruno] no, see above with 3 solutions. Others could be discussed if needed. 2. According to seamless MPLS, there may be 10,000 node addresses. If take the assumption, it will be a great configuration work. 3. The label route on the ASBR can be dymamic changed. Is there the case that the more or less SID/Labels are configured? [Bruno] I don't see what you mean. If my understanding is right, comparing with the simple case with actual egress, there will be more challenge for the proxy egress case for SR. In fact, there are more usecases of proxy egress: 1. C & C: Proxy egress for the VPN routes 2. Seamless MPLS: Proxy egress for the LDP DoD [Bruno] For the downstream direction (signaling toward upstream), If you use BGP, you can still use BGP. If you use IGP cf solutions 1 & 2.a above. 3. Some usecases which needs LDP node and Non-LDP node coexists. I wonder if you have thought about the proxy egress scenarios and what is the possible solution? If the proxy egress cannot be supported, there will be more challenges: 1. LDP cannot be replaced by SR-BE path. In the above usecase, LDP Proxy Egress and SR actual egress may have to co-existed. It will be too complexed and SR is totally unnecessary. 2. TI-FRR for the proxy egress case cannot supported either. But this case can be supported by other FRR solutions. [Bruno] TI-FRR protects solutions using the IGP (1 & 2.a). Node protecting BGP destination is possible (e.g. draft-minto-2547-egress-node-fast-protection) but this is a different story. /Bruno Hope to get your opinion on the progress egress for SR. Regards, Robin _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
