Subject: [mpls] Requesting your feedback - issues/errors/clarifications for RFC3036

From: Ina Minei <[email-masked]>
Date: Thu, 19 Aug 2004 17:34:14 -0700 (PDT)

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.

	I will post the complete list of the issues a couple of weeks
later.

		Thank you,

			Ina

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Markus Jork <[email-masked]>
Date: Tue, 24 Aug 2004 16:17:13 -0400

> 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

---

From: "Vach Kompella" <[email-masked]>
Date: Tue, 24 Aug 2004 15:24:44 -0700

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Markus Jork
> Sent: Tuesday, August 24, 2004 1:17 PM
> To: Ina Minei
> Cc: [email-masked]
> Subject: Re: [mpls] Requesting your feedback - 
> issues/errors/clarifications
> 
> 
> > 
> > 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 
> 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
> 
> 
>

---

From: Luca Martini <[email-masked]>
Date: Tue, 24 Aug 2004 16:14:32 -0600

Ina,

The following text needs more explanation:
RFC3036:

  F bit
     Forward unknown TLV bit.  This bit applies only when the U bit is
     set and the LDP message containing the unknown TLV is to be
     forwarded.  If F is clear (=0), the unknown TLV is not forwarded
     with the containing message; if F is set (=1), the unknown TLV is
     forwarded with the containing message.  The sections following
     that define TLVs specify a value for the F-bit.

-----------------------------
If  the U Bit and the F bit are set , then the extra TLV can be forwarded.

I believe that somewhere we need to explain that this was intended to 
allow attachment of attributes to a FEC.
I believe that this is used by the LDP MTU draft already, but we need 
some text to specify the F-bit better.

Luca

Luca

---

From: Mark Duffy <[email-masked]>
Date: Tue, 24 Aug 2004 18:30:09 -0400

>send your comments by September 6, either directly to me or to the list.

Hi Ina,  I have 2 items:

1.  It would be nice to fold the content of 
draft-ietf-mpls-ldp-mtu-extensions-02.txt into the main LDP standard document.

2.  Re LDP discovery (RFC 3036 section 2.4):  Two types of peer discovery 
are described: Basic and Extended.  Basic as described will work on 
broadcast and point-point media but not in general on NBMA media (e.g. 
non-LC-ATM when used in a multipoint mode).

Extended can work on NBMA but its semantics are quite different than Basic: 
it allows "discovery" of peers that are more than 1 hop away, and it does 
not bind the Hello adjacency to a particular interface.  Both of these 
differences can be undesirable in a context where one is looking to use LDP 
to distribute outer labels with adjacent peers on a non-LC NBMA 
network.  Extended discovery appears to be primarily intended for 
distributing "inner" labels with non-adjacent peers.

I think the successor to 3036 should either point out that basic discovery 
on NBMA is not provided for, or it should specify a mechanism semantically 
similar to basic discovery (1 hop limit, bind the hello adjacency to an 
interface) except using preconfigured neighbor addresses.

Thanks, Mark

---

From: Ina Minei <[email-masked]>
Date: Tue, 24 Aug 2004 15:42:35 -0700 (PDT)

Mark,

	Thank you for your feedback, please see inline below.

> draft-ietf-mpls-ldp-mtu-extensions-02.txt into the main LDP standard document.

	From a standards point of view, this cannot be done, since the mtu
extensions is not yet an RFC.

	Regarding the second point, I will send all comments together to
the list for review/discussion after receiving all the feedback.

				Ina

---

From: "Kishore Tiruveedhula" <[email-masked]>
Date: Tue, 24 Aug 2004 21:23:34 -0400

Here is one more issue:
   In case of loopdetection enabled in Downstream Unsolicited mode, need to
address the following issue.

  Router A             Router B
  --------             --------
  Send Label Mapping
                       Recv Label Mapping
                       Send Label Release (due to Loop found).
  NHOP Changes
  Send Label Mapping
  (with new pv tlvs)

  Recv Label Release
                       Recv Label Mapping.

In the above scenario, "A" ends up with no label advertised to "B", But "B"
has received label from "A".

 Probably, the Label Release message should carry the message id (mandatory)
to indicate exactly this is an ack for which message.

Thanks,
Kishore

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Ina Minei
Sent: Tuesday, August 24, 2004 6:43 PM
To: Mark Duffy
Cc: [email-masked]
Subject: Re: [mpls] Requesting your feedback -
issues/errors/clarificationsfor RFC3036

	Mark,

				Ina

---

From: Eric Gray <[email-masked]>
Date: Wed, 25 Aug 2004 05:45:47 -0400

Ina,

    From an IETF standards process perspective, what you say below is not
strictly correct. That does not mean that your conclusion is incorrect. :-)

    You cannot refer to the MTU extensions work in progress as a normative
reference until it is an RFC. However, if it turns out that LDP 
implementations
typically include these extensions and multiple such implementations are 
found
to not only include it but interoperate as well, then you certainly 
_could_ "fold
in" the actual contents (at least as actually implemented). In fact, if 
a number of
implementation reports indicated that implementing these extensions was 
needed
in order to achieve interoperability, you would have to do so.

    Assuming these extensions are not required to make LDP work (I 
believe this
to be the case) then the fact that you _could_ "fold in" the extensions 
does not
mean that you should. In fact, from the perspective that "options are 
(often) bad",
you should not.

    So, while I agree with the conclusion that we don't want to do this, 
I have to
object to the (possibly precedent setting) statement that "this cannot 
be done".

--
Eric

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 25 Aug 2004 05:46:08 -0700 (PDT)

Ina wrote:

>        From a standards point of view, this cannot be done, since
> the mtu extensions is not yet an RFC.

You're both missing a key point.  That does not mean your conclusion
is incorrect :-)

RFC 2026 says:

4.1.2  Draft Standard

   A specification from which at least two independent and interoperable
   implementations from different code bases have been developed, and
   for which sufficient successful operational experience has been
   obtained, may be elevated to the "Draft Standard" level.

While I think that the LDP MTU stuff is wonderful, folding it into a
DRAFT STANDARD is soooo tomorrow -- no implementation, let alone two
interoperable implementations (it is currently targeted as
Experimental just for this reason), no vast storehouse of deployment
experience, none of what it takes to take a doc to Draft status.

Let it mature for a few years, then we can re-evaluate.

The same principle should apply to anything else that people suggest
get put into the DS version of 3036, *even parts of 3036* that
haven't had enough exposure, implementation or deployment.

Kireeti.
-------

---

From: Eric Rosen <[email-masked]>
Date: Wed, 25 Aug 2004 11:00:17 -0400

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

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

> have an LDP session between two peers? 

This should not be a requirement of the protocol spec, the application which
is using the protocol should determine which FECS get sent. 

> define a mandatory combination.  DU/OC seems to be the favored one. 

I believe  this would  put a majority  of the  deployed LDP speakers  out of
spec.  Such a change cannot be made as part of going to DS.

---

From: Luca Martini <[email-masked]>
Date: Wed, 25 Aug 2004 09:33:51 -0600

>other, you have to figure that there is a problem somewhere in the
Actually I disagree. If anyting we should have DU/IC , the ordered 
control caused lot's of operational problems , and it took almost a year 
to get it working properly. There are a number of situations that cause 
problems in ordered control mode , but not in independent control. Most 
of these issues are due to timing.

>it has, or can it do it lazily, e.g., when it has a second LDP session?
No sure I understand what you mean here.  LDP cannot know what path is 
selected, so it must send all the FECs.

Luca

---

From: Ina Minei <[email-masked]>
Date: Wed, 25 Aug 2004 10:44:05 -0700 (PDT)

> is using the protocol should determine which FECS get sent.

	I agree. This is not a specification issue, but rather a
best-practice based on the application for which the protocol is used.
If you only need the loopbacks as FECs for your application, then it is
best if you _ask_ LDP to only redistribute the loopbacks, because it will
make your network easier to troubleshoot.

				Ina

---

From: Luca Martini <[email-masked]>
Date: Thu, 26 Aug 2004 15:19:00 -0600

Ina,

Please note the following points:

- the LDP loop detection mechanisms do not make much sense in DU mode. 
This is the hop count TLV,  and the Path Vector TLV. ( When LDP 
interoperability testing was just starting , I had most vendors out 
there remove it for DU mode ). We should add something explicitly that 
says that these TLVs should not be used in DU mode. ( This is the 
current practice in all implementations that I know of )

- The Host FEC is accepted by most implementations I worked with , but 
sent by none. So I also think it's probably a good idea to remove it.

Luca

---

From: Rama Ramakrishnan <[email-masked]>
Date: Thu, 26 Aug 2004 14:16:44 -0700

Hi,

I also think that removing Host FEC is a good idea

Regards,

Rama Ramakrishnan

---

From: Rama Ramakrishnan <[email-masked]>
Date: Mon, 30 Aug 2004 09:47:00 -0700

Ina,

I tried to go through the LDP RFC to see if it specifically says that a 
wildcard
release message should be sent only in response to a wildcard withdraw 
message.

There may be a timing condition in which an upstream router may still hold
a label for which downstream router has removed it from the incoming label
database.

draft-ietf-pwe3-control-protocol-08.txt probably talks about a similar 
situation for
wildcard release for L2 FECs as below

"A wildcard  release message MUST include only the group ID. A Label Release
    message initiated from the imposition router must always include the 
   PW ID."

Any thoughts?

Regards,

Rama Ramakrishnan