Re: [Mpls-interop] MPLS over MPLS-TP

Ben,

> 3. If there is demarcation as suggested in point 2, what is the best
way
> to 
> provide demarcation?
> a. Encode as a PW with the end of stack set and a PW header according
to
> the 
> appropriate PW encoding type.
> b. Simply use the end of stack bit to say that we have reached the
> bottom of 
> the MPLS-TP label stack.
> (The alternative clearly being that the label stack runs through from
> the 
> client label stack to the server label stack.)
> 
> AM> I prefer b, for simplicity and generality of what can be carried
> over MPLS-TP. Thus we could have a label stack with two EOS bits set.

Does setting EOS provide the necessary separation?  Today in some MPLS
implementations if I reach the EOS in the middle of the network the
label is
popped and the IP traffic inside is forwarded natively as IP across the
core.  Now if that IP traffic is really say control plane traffic for
your
customers MPLS network do you want that to happen?

Is it just that we need to specify how an implementation is supposed to
behave in MPLS-TP in this sort of scenario or do we need explicit
mechanisms
to prevent it such as always wrapping MPLS/IP in a PW?

AM> The intention would be that the MPLS-TP EOS bit would only be
encountered at boundary the MPLS-TP network, and the payload would
delivered to the client to do with as it desires (and expects), whether
it's IP to forward, MPLS to switch using router-allocated labels, PW
contents, or something else entirely. To the client, there should be no
difference (at some layer of abstraction above the interface details)
between using MPLS-TP for transport and POS or GFP encapsulation for
transport.

Cheers,
Andy

_______________________________________________
Mpls-interop mailing list
Mpls-interop@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-interop