In-line [Uma]: -- Uma C.
-----Original Message----- From: Eric C Rosen [mailto:[email protected]] Sent: Monday, April 11, 2016 11:59 AM To: Uma Chunduri; Xuxiaohu; [email protected] Cc: [email protected] Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 >> [Eric] It would be somewhat unusual to have an IGP domain in which some >> nodes support MPLS and some don't. > [Uma] May be true with non-SR and traditional MPLS. > But with SR I am working with one customer where MPLS (as SR data plane) is > brought into their pure IGP-IP domain. > With static PW labels (inner label) currently pure soft GRE encap is being > used (for transport) but SR is being planned from EPG to cell site routers > eventually. > Planning slow upgrade for some of the MBH nodes with SR-MPLS data plane. In > this case its quite possible to use (in future) non-shortest path SR label > stack. > > Interesting. But I'm not sure which of two scenarios you are describing: 1. There is always an MPLS path from ingress to egress, but the shortest path may not consist entirely of MPLS-capable nodes. 2. There isn't always an MPLS path from ingress to egress. So if the ingress creates an MPLS packet, some intermediate node may need to re-encapsulate the packet in IP, in order to get the packet delivered to the egress node. Or is the scenario different from either of these two? [Uma]: I was describing more of #2. However #1 is one of the cases. In #2 as the shortest path neighbor doesn't support SR (and no outgoing LDP/RSVP label) and it recognizes the same, it encapsulates in IP or as per the egress node N's tunnel de-capsulation capabilities. There is no additional computation required here and its still shortest path towards egress but not labeled. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
