Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

[Robert Raszuk <[e-mail]>]

Eric,

Going by your logic we would have a notion of "incoming IP address" and
"outgoing IP address" in all routers in the world doing basic non NAT
routing.

While packets still arrive and depart they do not change label value hence
it makes rather limited sense to divide the label they carry into "incoming
label" and "outgoing label". Wouldn't you agree ?

Cheers,
R.


On Thu, Jul 23, 2015 at 11:27 PM, Eric C Rosen <[e-mail]> wrote:

> You use term "incoming label" and "outgoing label" ... well in the
>> new architectures there is no such things.
>>
>
> The incoming label is the label on the packet when it arrives, and the
> outgoing label is the label on the packet when it departs.  If a packet
> arrives with a label and leaves with a label, it has an incoming label and
> an outgoing label.  I believe that even in the "new architectures",
> packets still arrive and depart.
>
>  So to support legacy hardware new control plane has to make up from
>> single label now two (identical) labels to pass it to data plane. Now
>> also data plane must be smart to check that and program its state
>> per your suggestion.
>>
>
> I don't really understand what you are saying here.  The control plane
> determines the rewrite string and causes it to be programmed into the
> data plane.  There are many ways to implement this interaction.
>
> Are you worried about the following:
>
>  What happens if hardware vendor comes with hardware which exposes to
>> control plane API which allow protocols to signal that mpls label Y
>> is not to be swapped ? If so which IETF document such API would be
>> compliant with ?
>>
>
> I don't understand this point either.  RFC 3031 does not specify an API,
> so it doesn't make any sense to ask whether a particular API is or is not
> compliant with it.
>
>
>
>
>
>