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

Mark Tinka <mark.tinka@seacom.mu> Tue, 14 January 2014 19:52 UTC

Return-Path: <mark.tinka@seacom.mu>
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 0D0461AE113 for <mpls@ietfa.amsl.com>; Tue, 14 Jan 2014 11:52:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.589
X-Spam-Level:
X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] autolearn=no
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 1S2AJBO6SYb7 for <mpls@ietfa.amsl.com>; Tue, 14 Jan 2014 11:52:24 -0800 (PST)
Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBD31ADFB1 for <mpls@ietf.org>; Tue, 14 Jan 2014 11:52:23 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from <mark.tinka@seacom.mu>) id 1W3A1X-0002U9-RH; Tue, 14 Jan 2014 21:51:43 +0200
From: Mark Tinka <mark.tinka@seacom.mu>
Organization: SEACOM
To: curtis@ipv6.occnc.com
Date: Tue, 14 Jan 2014 21:51:42 +0200
User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; )
References: <201401141810.s0EIArai099817@maildrop2.v6ds.occnc.com>
In-Reply-To: <201401141810.s0EIArai099817@maildrop2.v6ds.occnc.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2864094.YLMcIW7czl"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Content-Transfer-Encoding: 7bit
Message-Id: <201401142151.43057.mark.tinka@seacom.mu>
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: mark.tinka@seacom.mu
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: Tue, 14 Jan 2014 19:52:27 -0000

On Tuesday, January 14, 2014 08:10:53 PM Curtis Villamizar 
wrote:

> You need specific configuration to create the
> mis-alignment.  You can also override an IP routing
> protocol with static routes.

Ships-in-the-night IGP operations (typically due to 
migrations) and/or multiple paths available to an LSR/LER 
can present a unique set of circumstances for this to brew 
without synchronized metrics between LDP and the IGP.

> Both ISIS and OSPF have a TE metric and an IGP metric. 
> The default AFAIK was to use the IGP metric for LDP,

This is C's way.

For J, there are options for this, and the default is 
opposite to what C do.

> though if as you say J defaults to 1 and requires you to
> configure a separate LDP metric.  If so, then the LDP
> hop count TLV would not match the IGP cost.  Not a
> problem but an odd choice for default value on J's part.

I've been in situations, many years back, where this has led 
to interesting problems (albeit, transient and/or easy to 
detect).

Situation could be aggregavated when you tunnel LDP in RSVP.

> I'm not sure how any of this discussion changes anything
> wrt draft-ietf-mpls-in-udp.
> 
> Is there relevance to draft-ietf-mpls-in-udp that I am
> missing?

Agree, we're now really off-topic, and maybe it's time to 
circle back to relevance to draft-ietf-mpls-in-udp.

Cheers,

Mark.