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

["Stewart Bryant (stbryant)" <[e-mail]>]

Just a quick response.

It runs over MPLS, and you can run MPLS(GAL) over datalinks.

Stewart



> On 6 Mar 2014, at 13:22, "Kireeti Kompella" <[e-mail]> wrote:
> 
> 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
> 
>