The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2004-Aug> msg00022



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[mpls] Requesting your feedback - issues/errors/clarifications

  • From: "Vach Kompella" <vkompella@timetra.com>
  • Date: Tue, 24 Aug 2004 15:24:44 -0700
  • Cc: mpls@ietf.org
  • Importance: Normal
  • Organization: Alcatel USA
  • X-MIME-Autoconverted: from quoted-printable to 8bit by cell.onecall.net id i7ON5Rm15781
  • X-OriginalArrivalTime: 24 Aug 2004 22:22:36.0861 (UTC)FILETIME=[DC107ED0:01C48A28]

I agree we should get rid of the host FEC type.

Issue: it would be nice to be able to shut down an adjacency without
having to time it out.  E.g., two interfaces between the same pair of
nodes running LDP.  If one is shut down, there is no way to notify the
peer endpoint, e.g., notification message to the multicast address over
UDP.

Issue: do we really have to send all FECs in our database whenever we
have an LDP session between two peers?  E.g., A is a PE which does LDP
for address FECs as well as PW FECs.  If it sets up a targeted adjacency
clear across the network to another PE, does it really have to send all
its address FECs there?  In our implementation, we do not send address
FECs across a session that was set up with a targeted adjacency, since
we only use targeted adjacencies for PW FECs.

Issue: with all the combinations of Downstream Unsolicited, Downstream
on Demand, Ordered Control, Independent Control, etc., it makes sense to
define a mandatory combination.  DU/OC seems to be the favored one.
E.g., IC was useful back when MPLS LSPs replaced IP forwarding.  Now
that that isn't the case anymore, if there is a P router doing
independent control in the middle of the network, it propagates a FEC
for a tunnel that may be used by 2547, BGP-free core routing, or PWs,
falsely giving the impression that the PSN tunnel is end to end.  It
would be far better to identify, at ingress, that the tunnel is not up.
In either case, we blackhole packets, but in one case, we clearly know
the service is not up, the route is not resolvable, etc., while in the
other, you have to figure that there is a problem somewhere in the
middle of the network.

Issue: Minor optimization: why do you send a FEC back to the owner of
the FEC?  E.g., A sends its loopback to B.  Why should B send it right
back to A (as described in LMp.21)?

Issue: Minor optimization: if A is a stub node, i.e., only one LDP
session, does it really have to send a label mapping for every FEC that
it has, or can it do it lazily, e.g., when it has a second LDP session?

-Vach 

> -----Original Message-----
> From: mpls-bounces@lists.ietf.org 
> [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Markus Jork
> Sent: Tuesday, August 24, 2004 1:17 PM
> To: Ina Minei
> Cc: mpls@ietf.org
> Subject: Re: [mpls] Requesting your feedback - 
> issues/errors/clarifications
> 
> 
> > 
> > 	RFC3036 (LDP specification) is advancing to draft standard.
> > 
> > 	As part of this process, it is necessary to compile a list of 
> > changes/clarifications to the rfc, based on the experience 
> gained with 
> > the protocol.
> > 
> > 	Please send me errors/changes/clarifications that you 
> know about, so 
> > that they can be taken into account in the revised document. Please 
> > send your comments by September 6, either directly to me or to the 
> > list.
> 
> Here is one issue:
> The spec defines two types of FECs: "address prefix" and 
> "host address". The address prefix FEC is what's in 
> widespread use. We have also implemented support for the host 
> address FEC but I have never seen it used. It would be 
> interesting to know whether there is any known actual use of 
> it. If not, I suggest to remove it from the spec.
> 
> Markus
> 
> 
> > 	I will post the complete list of the issues a couple of 
> weeks later.
> > 
> > 		Thank you,
> > 
> > 			Ina
> 
> 
> 
> _______________________________________________
> 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