On (2013-04-02 10:57 -0700), Pedro Roque Marques wrote: > The document describes the behavior of the end-system and the external > Forwarder. In my mind, the scenario where Q-in-Q (or other L2 encap) is > used between the end-system and the Forwarder because of additional L2 > hops should not need to be explicitly described.
I don't understand. Are you saying even if host would double tag, that would not be relevant to Forwarder? Looking at page 12 I don't know how to signal two tags to Forwarder. > Searching thought the document /32 seems to appear in examples. If you > don't mind pointing out explicitly where you believe the text should be I'm probably reading it wrong, page 13, request 2, associate node is one that caught my eye. > The route-server is not on the forwarding path. I was thinking native MPLS-to-the-edge in DC, where I only have VPN Forwarder between my host and core MPLS PE (preferably right in the host as 'virtual router'). Then if I'd use OptB, I'd need to collapse route-server and VPN forwarder into same box? > The data-center gateway typically implements option B (or IBGP plus > next-hop self) and stitches the MPLS-over-GRE LSP segment (internal to > the DC) with an MPLS over L2 LSP segment outside the data-center, in > scenarios where the service is delivered to a WAN L3VPN. Would this be true for green-field as well? I'd really love to see solution where I can plug host anywhere in MPLS network. -- ++ytti
