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

[Robert Raszuk <[e-mail]>]

Gregory,

I would not compare it to ethernet or trill but more to mpls-tp. But I
think it is advisable to separate discussions about architecture from basic
primitives of mpls.

Cheers,
R.

PS. I am ready to talk about both but let's handle one at a time ;)

On Thu, Jul 23, 2015 at 11:14 PM, Gregory Mirsky <
[e-mail]> wrote:

>  Hi Robert,
>
> RE: “new architectures”
>
> It does look very much like Ethernet or TRILL. Why not to use one of them?
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* mpls [mailto:[e-mail]] *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, July 23, 2015 9:58 PM
> *To:* Eric C Rosen
> *Cc:* [e-mail]
> *Subject:* Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much
> does it really save?
>
>
>
> ​Hi Eric,​
>
>
>
>  ​​
>
> If you notice that the incoming label needs to be 'replaced' by an
> outgoing label of the same value, you could just make the rewrite string
> shorter, so it won't overwrite the top label on the stack.  This seems to
> be what the draft suggests, but it could be done as an optimization for the
> particular case where the incoming and outgoing labels have the same value.
>
>
>
> ​This is precisely ​the crux where your statement fails.
>
>
>
> You use term "incoming label" and "outgoing lable" ... well in the new
> architectures there is no such things.
>
>
>
> It is a "global label" or "path label" with adjacency information.
>
>
>
> 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.
>
>
>
> Why would we do that other then due to worry about legacy chipsets feared
> to be non compliant to new RFC ?
>
>
>
> Many thx,
>
> R.
>
>
>