Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

Curtis Villamizar <curtis@ipv6.occnc.com> Mon, 13 January 2014 20:04 UTC

Return-Path: <curtis@ipv6.occnc.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86DBB1ADFCA for <mpls@ietfa.amsl.com>; Mon, 13 Jan 2014 12:04:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level:
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eP9_LRbuYAzU for <mpls@ietfa.amsl.com>; Mon, 13 Jan 2014 12:04:29 -0800 (PST)
Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 178C61ADFB5 for <mpls@ietf.org>; Mon, 13 Jan 2014 12:04:28 -0800 (PST)
Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0DK4DFO080786; Mon, 13 Jan 2014 15:04:13 -0500 (EST) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201401132004.s0DK4DFO080786@maildrop2.v6ds.occnc.com>
To: mark.tinka@seacom.mu
From: Curtis Villamizar <curtis@ipv6.occnc.com>
In-reply-to: Your message of "Mon, 13 Jan 2014 07:13:09 +0200." <201401130713.13126.mark.tinka@seacom.mu>
Date: Mon, 13 Jan 2014 15:04:13 -0500
Cc: "mpls@ietf.org" <mpls@ietf.org>, "Eggert, Lars" <lars@netapp.com>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: curtis@ipv6.occnc.com
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jan 2014 20:04:30 -0000

In message <201401130713.13126.mark.tinka@seacom.mu>
Mark Tinka writes:
 
> On Monday, January 13, 2014 03:30:04 AM Gregory Mirsky
> wrote:
>  
> > Hi Mark,
> > if by "provisioning" you mean "mapped to", "assigned",
> > then what about IP addresses? Ain't they pre-provisioned
> > as well? Or these are native properties of NEs?
>  
> The path that two successive IP packets take to get from
> point A to B, in an MPLS-free network, can be arbitrary.
>  
> FEC's are constant for a group of IP destinations mapped to
> them.
>  
> Mark.


Mark,

Perhaps someone needs to explain to you what a FEC is and how MPLS
traffic is routed in most LDP networks.

The most common FECs "in the wild" from LDP RFC 5036 are the prefix
TLV or address list TLV containing exactly one address local to an
originating router.  This FEC is passed to adjacent LSR and each LSR
that get the FEC from more than one neighbor picks the best among them
based on the IP routing table.  Having picked a "best" next hop for
the FEC, the LSR passed the FEC on to all other neighbors.

In this way a multipoint to point tree is built where the tree exactly
follows the IP routes in the same network.  If there is an IP routing
change, the MPLS tree to that FEC also changes.  A packet destined to
a given FEC would follow the same set of hops whether it was
encapsulated in IP or encapsulated in MPLS.  For things like PW or
VPN, the MPLS encapsulation is needed but the endpoint can be
identified by the FEC.

MPLS label mappings *can* be provisioned, but in most cases (nearly
all AFAIK) they are not.  LDP is a signaling protocol and the mappings
of label to FEC are dynamic as described in the prior paragraph.  It
is in the absense of LDP (and in the absense of RSVP-TE) that label
mappings are provisioned.

So your objection above and in prior emails seems to be based on a
misunderstanding of what a MPLS FEC is and how LDP works.

X over MPLS over L2 follows the same path to an IP FEC as X over MPLS
over UDP over IP over L2.  The exception is that if part of the
network does not support MPLS (including an LDP partitioning where A
and B would otherwise not have MPLS connectivity), X over MPLS
over UDP over IP over L2 can make use of the non-MPLS capable part of
that network.

Curtis