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? On both 
ASBR11 and ASBR22? If there more ASBRs, there will be
more configuration work. Is it right?
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?

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

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.



Hope to get your opinion on the progress egress for SR.



Regards,
Robin
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to