Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[Robert Raszuk <[e-mail]>]

Hi Tony,

 I’m simply trying to address use cases and requirements.  Yes, it would be
> much better to have a true understanding, but I have yet to get a clear
> explanation myself.
>

I think this is necessary to make sure what we build will actually work.
Some people still believe that you can emulate SONET/SDH/TDM type of
containers in IP networks. And they say slice would be channel ID.
Unfortunately this is not how IP networks work which I have heard is still
surprising to a few folks. Statistical multiplexing concept is still also
foreign to them.

 There’s another 11 bits in an LSE and it would make more sense to allocate
> them than to waste them.  As we’ve discussed, there might be a scalability
> issue and 11 bits might go a long way in improving the range.
>

Honestly I can get those 11 bits today with no issue. I only need S bit to
be untouched in LSE post RFI so I can have 31 bits today. (Total size I
assume is still 4 octets :).

> Of course this is not to say that even if we do not integrate they do not
> exist - but on my side I would leave those to the user to prioritize
> execution between RFV and ISDs.
>
> I’m not following you.  If they are not integrated, then the specification
> xor the implementation is going to define the order of execution, the same
> as if they are integrated.  The integrated approach would give us lower
> overhead (e.g. only one SPL).
>

Well first you are optimistically assuming there is market need for both :)

Then if there is market need then order of execution should be left to the
operator to specify.

The complexity will be there if both RAF and MNA functions are required.
>

Yes. Even within ISD if you put 5 actions there is complexity.

Going under ISD is a very very risky business from the perspective of
upgrades. Suppose node supports action MNA_1, MNA_2 and RFV. One day some
one like to introduce MNA_3. Well till *all* routers are upgraded and
enabled to execute MNA_3 the entire ISD may be ignored in best case. Or
packet can be dropped the moment MNA_3 is in ISD and packet hits non
upgraded box.

And remember RAF specifically targets spots not the entire network to
execute additional network functions.


> The lower overhead is from a single SPL rather than 2.
>

True.


> The added complexity would come from two modifications to the stack vs. one
>

Well in the vast majority of my deployment RAF tuple should not be modified
anywhere in the network.


> , plus searching for two SPLs in the stack.
>

Hmmm didn't you say the other day that each LSR needs to parse the entire
stack anyway in search for SPLs ? Remember my comment during the last
meeting .. today label stack has no offset so you do not know what it
contains till you parse it. Heavy !


> Life looks simpler if things are integrated.
>

See I do not mind integration, but I do have real concern that in the event
vendors decide not to support MNA at all - RAF is dead. And to tell you the
truth, what I am seeing and hearing in respect to MNA's future is not too
promising. Yes - I am sure it can be pushed through IETF, but that's not
the point :)

Kind regards,
Robert.