RE: [mpls] draft-ietf-mpls-ldp-interarea-01.txt to WG last call

"DECRAENE Bruno RD-CORE-ISS" <bruno.decraene@orange-ftgroup.com> Wed, 19 December 2007 18:38 UTC

Return-path: <mpls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53om-0001SE-9E; Wed, 19 Dec 2007 13:38:56 -0500
Received: from mpls by megatron.ietf.org with local (Exim 4.43) id 1J53ok-0001Lj-GX for mpls-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 13:38:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53ok-0001JA-4l for mpls@ietf.org; Wed, 19 Dec 2007 13:38:54 -0500
Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J53oi-0004Tl-3p for mpls@ietf.org; Wed, 19 Dec 2007 13:38:54 -0500
Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 19:38:50 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [mpls] draft-ietf-mpls-ldp-interarea-01.txt to WG last call
Date: Wed, 19 Dec 2007 19:38:32 +0100
Message-ID: <5A0FF108221C7C4E85738678804B567C059BA6BF@ftrdmel3>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [mpls] draft-ietf-mpls-ldp-interarea-01.txt to WG last call
Thread-Index: AchBwqwJthOR9H+fTA60ed5N0MOmxAAGcz0wAB8KfBA=
References: <20071218220910.1C6F250BC41@swallow-mini-mac.cisco.com> <9E2742C54E161041A53F36F9A8DC31BEFB1B90@EXCH-CLUSTER-04.force10networks.com>
From: DECRAENE Bruno RD-CORE-ISS <bruno.decraene@orange-ftgroup.com>
To: Sina Mirtorabi <smirtorabi@force10networks.com>, mpls@ietf.org
X-OriginalArrivalTime: 19 Dec 2007 18:38:50.0441 (UTC) FILETIME=[65F46390:01C8426E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48
Cc:
X-BeenThere: mpls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=subscribe>
Errors-To: mpls-bounces@lists.ietf.org

Hi Sina,

Thanks for your comments.

Answers inlined.

> -----Message d'origine-----
> De : Sina Mirtorabi [mailto:smirtorabi@force10networks.com]
> Envoyé : mercredi 19 décembre 2007 03:05
> À : George Swallow; mpls@ietf.org
> Objet : RE: [mpls] draft-ietf-mpls-ldp-interarea-01.txt to WG last call
> 
> Geroge,
> 
> 
> I have two comments
> 
> - Section 7.2 Impact on routing convergence time, as it is mentioned,
> the failure of a node will not be propagated outside of the area, and
> the notification is relied upon LDP (which arguably could be comparable
> to IGP fast convergence) however the draft should also mention that this
> would introduce an issue for other protocols convergence that rely on
> IGP, i.e. BGP. In such a scenario a node failure in the remote area
> cannot be detected by IGP and the convergence of BGP could significantly
> be increased, unless other mechanisms are used to convey more specific
> IGP information.

1) Knowledge of the failure:
We don't need any other mechanism as LDP will advertise the failure of the egress node/PE (through the removal of the specific /32 FEC).

2) Use of this knowledge:
You're right, upper layer protocols (eg BGP) would need to check MPLS reachability of the BGP Next-Hop /egress (advertised by LDP) whereas currently some implementation may eventually only check the IP reachability (advertise by the IGP).

This is mostly out of scope of LDP and MPLS (but rather up to upper protocols) but you're right this would be better to explicit this. What about adding:
"Note that applications using these MPLS LSPs (eg BGP to reach the BGP next-hop) need to check the MPLS reachability of these LSP (signaled by LDP) and not only the IP reachability (signaled by the IGP)".

Would this be fine for you?



In addition, note that there has been a very recent discussion on this point during IETF 68 (Prague) in the IDR WG (BGP) regarding the draft draft-asati-bgp-mpls-blackhole-avoidance-00. In short, most people were considering that BGP may/should already check MPLS availability of the Next-Hop if BGP needs an LSP to reach the next-hop of the destination prefix (NLRI).

(For additional information, following lines are relevant extracts form the minutes:

"- Yakov -- LHD is outside scope of BGP, base spec doesn't talk about how to interact with ANY other protocols.  Sounds like you want this WG to change route selection algorithm.

[...]

- Chandra -- maybe we need to say that implementations should be smart about interpreting what "next hop reachability means"
- Yakov -- exactly.  They shouldn't be dogmatic when reading the BGP spec.
- ??? (name not stated at mic) -- I agree with Yakov.  I suggest this is informational.  LDP black holing is an implementation problem.  I think that this is very helpful.

[...]

- John Scudder -- fundamental premise OK but seems like a lot of  
pages to make a simple point, and too much implementation details.   
Isn't basic point that if network layer foo is used for forwarding, network layer foo reachability is needed to qualify NH?
- John -- could make this a one-page doc that says "please be careful about selecting a next hop if j. random network layer reachability isn't there".
- Yakov -- yes, that could be a one-page draft (one line plus boilerplate).
")


Bottom line is that BGP checking MPLS reachability is already useful and implemented by at least a major implementation.  


> - The draft should also mention that by announcing more specific FECs
> across area, it does not remove the suboptimal path introduced by virtue
> of summarization of PE's loopback. In other word, Inter-area LSP could
> now take a suboptimal path.

You're right but this is a routing discussion, not an LDP one since LDP is only following IGP routing decision.

It seems to me that RFC 2966 already covers that discussion so we could reference it in the draft.
Would this be fine for you?



In addition, note that even when the ABRs advertises specific (/32) prefixes in the IGP for the sole purpose of the current LDP requirement (as per RFC 3036/5036) service provider may choose to override the IGP metric with a static value during the redistribution between areas/levels in order to reduce IGP churn/instability (at the cost of loosing optimal routing). This is already an existing trade-off.

> 
> 
> Thanks
> Sina
> 
> 
> 
> 
> 
> 
> ->-----Original Message-----
> ->From: George Swallow [mailto:swallow@cisco.com]
> ->Sent: Tuesday, December 18, 2007 2:09 PM
> ->To: mpls@ietf.org
> ->Subject: [mpls] draft-ietf-mpls-ldp-interarea-01.txt to WG last call
> ->
> ->Please indicate whether you believe this draft is ready for
> ->MPLS WG last call.
> ->
> ->Thanks,
> ->
> ->George & Loa
> ->
> ->==============================================================
> ->==========
> ->George Swallow             Cisco Systems
> ->(978) 936-1398
> ->                           1414 Massachusetts Avenue
> ->                           Boxborough, MA 01719
> ->
> ->
> ->
> ->
> ->_______________________________________________
> ->mpls mailing list
> ->mpls@lists.ietf.org
> ->https://www1.ietf.org/mailman/listinfo/mpls
> ->
> ->
> ->
> 
> 
> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls


_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls