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

[Robert Raszuk <[e-mail]>]

Adrian,

No one in this thread is saying that 3031 is wrong. All we are saying is
that it is incomplete.

As to your objects for the domain wide/global label case I only need two:

LABEL_VALUE
BINDED_IP_ADDRESS

I do not need IN_INTERFACE .. in fact as I am sure you know per interface
label space was practically never implemented. Even where it is very needed
implementations  use well known trick around it (example: for inter-as
option B on ASBRs or CSC).

As far as OUT_INTERFACE I would also leave it to FIB recursive resolution
to dynamically set it based on the BGP/IGP information.

So is this still MPLS per 3031 ? I am actually not that sure anymore.

Maybe it would be cleaner to call this MPLSv2 and document it in its own
RFC?

Then of course question will come why not just use remote next hop
attribute and encapsulate with IP. Well there is class of switches which do
brilliant L2 and L2.5 but not L3. I am not sure if cost of high speed
ports, very competitive power consumption, great cooling characteristics
would be a sufficient of the market for this new work - but I do not think
this is us here in IETF to decide that.

Best,
r.


On Fri, Jul 24, 2015 at 7:15 PM, Adrian Farrel <[e-mail]> wrote:

> Robert,
>
> You want to specify the interface between control plane and data plane?
>
> That's OK (although it may have been done once or twice before).
>
> And if you want to specify the interface between the management plane and
> the data plane, that is also OK (although it has been done before as well).
>
>
>
> If you want to specify that for a packet with incoming label the operation
> is NO-SWAP, that's OK.
>
> But note that your data model (to be generic) is going to need to also
> support SWAP.
>
> Thus, you will have objects...
>
> IN-INTERFACE (ifid)
>
> IN-LABEL (label)
>
> OPERATION {POP, PUSH, SWAP, NO-SWAP}
>
> OUT-INTERFACE (ifid)
>
> OUT-LABEL (label)
>
>
>
> Setting OPERATION to NO-SWAP saves you from setting OUT-LABEL, but doesn't
> save you from needing the object in your data model. So it is a trade in
> the design of the data model and either approach is fine.
>
>
>
> You can see a similar model in the LSR MIB module (3813 IIRC) and in the
> olde ATM MIB modules.
>
>
>
> None of the above has the slightest to do with 3031 being right or wrong.
>
>
>
> Adrian
>
>
>
>
>
> *From:* mpls [mailto:[e-mail]] *On Behalf Of *Robert Raszuk
> *Sent:* 24 July 2015 17:55
> *To:* Eric Rosen
> *Cc:* [e-mail]
> *Subject:* Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much
> does it really save?
>
>
>
> Eric,
>
> This discussion to me is not related to data plane.
>
> I look at it from control plane perspective which needs to pass label
> values to date plane.
>
> Creating non standard optimised APIs or YANG models to send single label
> or artificially send identical labels an in and out when given architecture
> does not have it seems like no-op to me.
>
> Best,
> R.
>
> On Jul 24, 2015 6:29 PM, "Eric C Rosen" <[e-mail]> wrote:
>
> On 7/23/2015 5:31 PM, Robert Raszuk wrote:
>
> 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
>
>
> I'm not sure I understand what it means to "have a notion ... in all
> routers".  A given router only needs to implement the functionality that it
> needs to provide to those who are going to deploy it.
>
> However, certainly there is a distinction to be made between "incoming"
> and "outgoing" even in the case of "pure" IP.  The incoming IP header of a
> packet is always different than the outgoing IP header of that packet, due
> to the need to modify the TTL and checksum fields.
>
> In addition, as you point out, the incoming source address field may be
> different than the outgoing source address field, due to NAT.  And use of
> the source routing option can result in there being a difference between
> the incoming destination address field and the outgoing destination address
> field.
>
> Another interesting case is tunnel stitching, where the incoming source
> and destination address fields may both be different than the outgoing
> source and destination address fields.  If you want to optimize for tunnel
> stitching, you precompute the rewrite string, and to the forwarding plane
> it looks like an ordinary case of forwarding a packet.
>
> Of course, if your platform doesn't need to perform any of these
> functions, it doesn't have to implement them.  Similarly, if you think that
> the most common operation (or even the only operation) your platform will
> have to perform on an MPLS packet is "don't modify the label stack except
> for the TTL of the top entry", nothing stops you from optimizing for that
> case.
>
> BTW, I understand perfectly well that there is some controversy about
> whether it is or is not a good idea to use domain-wide labels, but that is
> not a data plane issue, and the use of domain-wide labels does not require
> a change in the data plane architecture.
>