Re: [mpls] Comments on draft-kompella-larp

[Kireeti Kompella <[e-mail]>]

Hi Stewart,

On Mar 6, 2014, at 09:10 , Stewart Bryant <[e-mail]> wrote:

> Kireeti,
> 
> This is an interesting problem and we are pleased that you
> have brought discussion of this topic to the IETF MPLS WG.

Cool.

> The proposal on the table however is a point solution and
> it may be worth considering the wider problem of host
> to network  MPLS interfaces (UNIs).
> 
> In particular whilst the majority of traffic is IPv4 today, the
> stated policy of the IETF is to recognize the need to deliver IPv6
> solutions and thus not to design IPv4 only solutions.

Got that message; will fix.

> Whilst it is true that everyone does ARP, and ARP can in
> principle be extended, the reality of the situation is that
> the majority of ARP implementations are optimized IPv4
> specific, and thus in most cases extending ARP would
> require a similar effort to deploying a new IPv4/IPv6 agnostic
> protocol for the UNI.

Understood that this will be new code; the actual code isn’t that much, though.

> Given that Ethernet, whilst the most popular server network
> interface, is not the exclusive interface and recognizing
> that new link types may emerge, particularly in the IOT space,
> it may serve us better to take an approach that is
> MPLS specific but data-link neutral.

ARP is not Ethernet specific.  We prefer to have different code points for MPLS-over-Ethernet, MPLS-over-foo, etc. rather than have TLVs for the link layer.

> A further consideration is that whilst it may be possible to
> extend ARP for other address families, it is not a protocol
> that is well suited to the transport of other necessary
> UNI information, for example, metrics, QOS information,
> MTU, authentication, integrity, spectral information etc.

What we are going for is simplicity.  We have metrics and entropy label capability on deck; but we really don’t want to add too much more.

> An alternative approach that is worth considering as a starting
> point is described in draft-ietf-mpls-gach-adv (in the RFC
> Editor's queue). When we wrote this draft we were attempting
> to define a general UNI approach for MPLS with a focus on
> simplicity.

I took a quick look.  The immediate question is, can gach-adv be run over native Ethernet?  I don’t see a UDP port or IP encoding.  I do see that this can be used over MPLS; but the L-ARP draft is for establishing tunnels when you have none.  That’s why I prefer something that runs at the link layer.

If I missed something, please let me know.

Cheers,
Kireeti.

> If you are interested in exploring this with us further we
> would be pleased to work with you on this.
> 
> Dan and Stewart
> 
> 
> 
> 
> 
> 
>