Re: [mpls] New Version Notification for draft-kompella-mpls-larp-02.txt

[Bhupesh Kothari <[e-mail]>]

Hi Kireeti,

>
> Hi Bhupesh,
>
>
>     On Oct 30, 2014, at 14:02 , Bhupesh Kothari <[e-mail]>
wrote:
>
>     Hi Kireeti,
>
>     Can you describe how L-ARP can be used between a DSLAM and its
upstream
>     router to form bi-directional tunnels?  I want to understand what, if
any,
>     assumptions are made.
>
>
> L-ARP is for the DSLAM (or server, or whatever) to talk to a BNG (or
remote
> server).  For the reverse direction, one possibility is “labeled DHCP”.  A
> quick overview is that when a DSLAM X asks for an IP address, it also
says,
> allocate a label for me.  The upstream node (switch/BNG/CMTS) Y then
allocates
> a label, which it advertises to reach X.  That would establish
bidirectional
> connectivity.

If you have X and Y to begin, the solution works.  But that is not
always the case.  Take a L2 CMTS for example.  It has an IP address
but only for management, and is either connected on a separate
physical network for management or the management traffic is in-band
on a management VLAN.  For customer data traffic, which is what I want
to tunnel, it does not have visibility into what (and how many)
upstream routers are and is just a bridge in the data path.  In other
words, for label exchange is such a scenario, ARP semantics does not
fit well, especially in the reverse direction.


>
> To establish hierarchical tunnels, I would recommend L-BGP (RFC 3107).
Two
> possibilities: The X announces this label (with next hop Y); or Y
announces
> this label with itself as next hop.  In the former case, the L-DHCP reply
needs
> to have a label for X to advertise.
>
> If this makes sense (and interests you), I’d be happy to collaborate with
you
> on the L-DHCP draft.

Interested.  Let me give you my general comments on the whole draft,
and see if I am on the same page.

Agree on the need for a simpler label distribution protocol in certain
scenarios.  Modeling the protocol as stateless with simple semantics
is highly desirable in such cases.

There are two key functions: endpoint discovery and label exchange
(including service labels).  The L-ARP message format though is biased
for host use case.  For example, a host knows (either static, DHCP or
NDP as in v6) what its default gateways are.  It also understands what
subnets imply.  But in the label exchange process for L2 topologies
where nodes are connected over an Ethernet fabric, such semantics
might not be applicable.  Traffic entering into the tunnel could be
based on some identifier other than IP destination such as a DOCSIS
channel.  In such a case, I am not looking to "resolve" an IP address.
You might say that in this case for all traffic, I am looking to
resolve the default gateway.

Re-using (hijacking ;-))  ARP Ether type does not buy you much.
Intermediate
nodes on an Ethernet fabric does not care for Ether Type.  The end
nodes that consume ARP anyway needs the new functionality.  I agree
that re-using a Ether type saves some changes relatively, but hardware
type in ARP, IMHO, is still intended for resolution and not for a new need.
Label exchange sounds like a new protocol.

One common use case I have is creating bi-directional tunnels between
access nodes and all routers.  In addition, there is a need to create
multiple tunnels (PWs is more appropriate) between a pair of access
node and its upstream routers for different traffic types.  The topology
fits your applicability.


>
> Kireeti.

Bhupesh