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

From: Robert Rennison <[email-masked]>
Date: Wed, 19 Dec 2007 12:03:13 -0500

George,

I believe that this draft is ready for an MPLS WG last call.

Rob Rennison

ECI Telecom 

(412) 809 4271

> -----Original Message-----
> From: George Swallow [mailto:[email-masked]] 
> Sent: Tuesday, December 18, 2007 5:09 PM
> To: [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mpls
> 
> 

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

---

From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
Date: Mon, 7 Jan 2008 17:57:58 +0100

Hi Dave,

[...]

> > > I believe that some clarification needs to be added to the draft
regarding
> > > the conditions under which fault notification operates.
> > > Some specific
> > > comments are as follows:
> > >
> > > - Add a statement to section 4, problem statement,
> > > indicating that LDP label
> > > withdrawal can be used to advertise the state of a PE in a remote,
> > > summarized area/level, replacing the function done by the IGP in a
flat
> > > domain
> >
> >
> > The section "7.2. Impact on routing convergence time" already
> > has a discussion on this subject and states that "In case of
> > failure of the egress LER node, given that the IGP
> >    aggregates IP route on ABRs, the routing convergence behavior is
> >    changed compared to [LDP]. As the IGP does not carries specifics
> >    prefixes outside of the egress area, the IGP will not
> > propagate the
> >    notification of node failure outside of the area and therefore
> >    notification will rely on LDP. The FEC(s) of the egress
> > LER will be
> >    removed in an ordered way through the end-to-end
> > propagation of the
> >    LDP withdraw message."
> >
> >
> > Is your comment is that the existing text
> > - is not clear enough? In this case we can indeed rephrasing it)
> > - or is not at the right place (section 4 vs section 7.2)? In
> > this case, we can further discuss this but I would rather not
> > add this in the section 4 which is about the problem statement)
> >
> 
> As I understand the intent of the draft based upon our discussion,
part of
> the problem to be solved is in fact fault detection and notification
and
> therefore at least a summary statement in section 4 is appropriate
(which
> could point to section 7.2 for more detail). Also, the subject of
section 7
> is "Caveats for Deployment," which is not the best place to state what
> functions the document is intended to describe.

As I understand your point, you're rather ok with the text in the draft
and your concern is that discussion on PE failure notification is an
important point and therefore should be placed higher in the document.

First, I'd like to stress that the draft does not introduce new LDP
mechanism to advertise the failure of the remote PE. 

Now, regarding the section to hold that discussion,
- section 4 introduce the problem statement so I don't think this is the
best place. Especially this the protocol extension is not yet specified
and I don't think this is something which can be discussed before
specifying the solution.

- section 5 describe the protocol extension. Since this draft does not
introduce new LDP mechanism on this point, it does seem the best place
to hold the discussion.

- section 6 describe use case for this extension. This is clearly not
the good place. However, If the is a strong need the push that
discussion before in the draft, I suppose we could swap section 6
(example of use) and section 7 (Caveats for deployment). Yet I still
think the current order is more logical:
	1) Would you need it?
	2) If yes, before using it, you should consider theses caveats
 
- section 7 describe what service provider should consider before
deploying such extension. Being a service provider, in my mind this is
an important section which we are not trying to hide at the end of the
doc. I suppose we also could change the title of this section, to make
it more "must read", but with the current wording of the draft, again as
service provider, this is definitely not a section I would skipped.

> > > - Section 5:
> > > Suggest adding a statement that label withdrawal occurs in the
order from
> > > the routers adjacent to the failed egress node toward the upstream
nodes for
> > > the purpose of fault detection.
> >
> > Again, the section "7.2. Impact on routing convergence time"
> > already has a discussion on this subject and states that "In
> > case of failure of the egress LER node [..]. The FEC(s) of
> > the egress LER will be removed in an ordered way through the
> > end-to-end propagation of the LDP withdraw message."
> >
> > Is this text fine for you or would you like to add further
> > precisions?
> 
> As the draft currently reads, normative statements regarding operation
of
> the protocol cover only signaling for label distribution. As I
commented in
> Vancouver, the current text of the draft does not have normative text
> covering the cases of label withdrawal and how that could be used by
other
> protocols. The subject of section 7 is "Caveats for Deployment," which
does
> not appear to be the best place in the outluine of the draft to state
> protocol requirements.

Ok, thanks for your clarification.

The draft does not introduce new LDP mechanism to advertise the failure
of the remote PE. As per RFC 3036/5036, LDP already withdraw the FEC
which means the LSP is not useable anymore. 
Given there is no new mechanism defines, I don't see why we would need
to define new actions.
However, I see your point that some existing implementations may not use
this message as an indication of the failure of the remote LER/PE but
only consider the removing of the /32 in the IGP. In this case, the
implementation would have to change to (also) take into account LDP
events.

Regarding adding or not this point in the draft, the question is "is
this an implementation issue or a protocol issue (which should be
specified in an IETF document)?". Currently, AFAIK, such interactions
between protocols (eg how should BGP react when LDP withdraw a
FEC/label) is not fully specified in a RFC (either BGP ones or LDP
ones). So I guess that this is left to implementation. 

IMO, this is a subject beyond this draft and should be applicable
regardless of the longest match vs exact match question. On this point,
you can also refer to my e-mail on this MPLS list (2007/12/19) which
also discus this point and relate the "mirror" discussion in the IDR WG.

> > > I think there are some other assumptions that are necessary for
LDP to
> > > support egress PE fault notification, as follows:
> > >
> > > If multiple paths from some ingress node to the egress node
> > > exist with the
> > > same cumulative metric (or within an implementation
> > > specific threshold that 
> > > considers them equal), then that ingress node will receive
multiple label
> > > advertisements to the egress node.
> >
> > Yes and this may also be true for transit LSR anywhere in the
> > path. (ie not only for the ingress node)
> 
> Yes, the ingress in general will have one or more transit nodes
between
> itself and the egress.
> 
> >
> > > If the ingress node uses liberal label retention, then it must
wait for all
> > > such labels to be withdrawn before declaring the egress PE down.
If this is
> > > not done, then a link failure along one of the equal cost IGP
paths could
> > > cause the ingress PE to falsely declare the egress PE down.
> >
> > I think this is independent of the label Retention Mode
> > (which is an issue in case of IGP rerouting to a new path
> > toward the same PE (FEC) ie new next-hop.  Cf section
> > 2.6.2.1. of RFC 5036)
> >
> > Your right but I don't see what's new with the draft for an
> > implementation using ordered mode. For an implementation
> > using independent mode, you're right there is a change but
> > the change is to implement ordered mode for the longest match
> > FEC (the same ordered mode as specified in RFC 5036.)
> >
> 
> I suggest that the last paragraph at the end of section 4 with the
three
> bulleted list items could be a good place to make part of the above
> clarification. To me, the current text implies a single RIB prefix of
a
> certain length (i.e., better match) and does not cover the case where
there
> may be multiple equally best matching RIB prefixes.

(I guessed you meant section 5 rather than 4)
This paragraph describes what's new compared to RFC 5036 due to the use
of a longest match in the label mapping procedure. Namely these 2
points:
- when a new prefix appears in the RIB, it could be a new better match
for some FECs
- when a prefix disappears in the RIB, another one could still be found
as a (less) good match.

Regarding your point (load-balancing between LSRs), the draft brings
nothing new compared to RFC 5036 so I don't see the need to specify
something which could mislead readers in believing that something ahs
changed. 

BTW, in case of load-balancing, I would still rather say "one RIB
prefix" when this prefix has 2 (or more) LSR has next-hop.
 
> I think there may be other issues with independent node depending upon
the
> order of label withdrawals received by an ingress mode.

Actually the FEC selected using this longest match procedure can only be
propagated and dealt with using ordered mode. These FEC are not
propagated with independent more and therefore the LSP is not setup. 

> I can see how fault
> detection and notification works best using ordered mode, and can
envision
> other race conditions with independent mode. I suggest that the wg
consider
> adding text to indicate that ordered mode is preferred, as you state
above.

Currently the draft states that "FECs selected by this "Longest Match"
label mapping procedure will be distributed in an ordered way". Would
you like that we add "using LDP ordered mode as defined in [LDP]" ?
 
> Also, I think the references to 3036 in the draft need to be replaced
by
> 5036.

You're right but this is already done in the current version of the
draft (draft-ietf-mpls-ldp-interarea-01.txt). If you used a different
version of the draft for your comments, this may explain that we faced
differences regarding sections numbers.
 
> > > There are also cases where two links along equal cost IGP
> > > paths could fail
> > > at nearly the same time, which could cause all labels to an FEC to
be
> > > withdrawn, and reestablshed shortly thereafter.
> >
> > The example is not fully clear to me. Do you mean
> > - the _link_ is reestablished? or the FEC?.
> I meant the link fails, the LDP session fails, the label is withdrawn.
Once
> the link is reestablished, the LDP session would become active and
then the
> FEC would be bound again.
> 
> 
> > - is the network has a backup path (with higher IGP metric)
> > to the PE or not? ie is the routing behavior is an IGP
> > rerouting toward the same remote PE or do we lose connection
> > to the PE.
> 
> I stated "two links along equal cost IGP paths." A clarification would
be
> that these are "separate equal cost IGP paths"
> 
> >
> > > This behavior will differ
> > > from an IGP hello type protocol node failure detection.
> > > Therefore, an
> > > implementation MAY implement a fault detection timer after
receiving
> > > withdraw(s) for all prefixes before declaring the egress PE to be
> > down.
> >
> > I don't think any more thing is required but it would help me
> > if you could elaborate on your specific example (especially
> > providing more precision on the topology and the failures events.
> 
> Below is a simple example for discussion:
> 
> 
>   /A---B\
> E        I
>   \C---D/
> 
> All hops have the same IGP metric. Egress (E) node and Ingress(I) node
are
> in stub areas and A,B,C, and D are in the backbone area (using OSPF
> terminology). E distributes a label for its own FEX to A and C, which
in
> turn distribute a label to B and D. B and D use the longest prefix
match
> signaling specified in the draft, and both distribute the label
binding for
> E's FEC to the Ingress (I).

Thanks for clarifying the example.

In your example, the backbone area does not seem connected so it's a big
particular to discus this topology. (Is this on purpose or did you omit
some links which didn't seem relevant to your point?)

> Now the link between E and A fails. A will issue a label withdraw to
B,
> which in turn will issue a label withdraw to I. However, I still has a
RIB
> prefix (of the same length and IGP metric) remaining to E (see my
comment
> and proposed clarification to section 5 above).

In your example, the behavior with the longest match procedure would be:

1) before the failure.
RIB: 10/8
	- Next hop B
	- Next hop C

In LDP, the LER I:
- received a label mapping from B, for the FEC 10.0.0.1/32, with the
label LB. 
	- according to the draft (section 5 "Label Mapping Procedure"),
it accepts the FEC since "its routing table contains an entry (10/8)
that matches the FEC Element (10.0.0.1/32) and the  advertising LSR (B)
is a next hop to reach the FEC. 

Idem from C
(- received a label mapping from C, for the FEC 10.0.0.1/32, with the
label LC. 
	- according to the draft (section 5 "Label Mapping Procedure"),
it accepts the FEC since "its routing table contains an entry (10/8)
that matches the FEC Element (10.0.0.1/32) and the  advertising LSR (C)
is a next hop to reach the FEC.)

2) After the failure.
RIB: 10/8
	- Next hop B
	- Next hop C

In LDP, the LER I received a label withdraw from B, for the FEC
10.0.0.1/32, according to RFC 5036 "When an LSR receives a Label
Withdraw message for a FEC from an
      LDP peer, it responds with a Label Release message and it removes
      the label from any forwarding/switching use.  If Ordered Control
      is in use, the LSR sends a Label Withdraw message to each LDP peer
      to which it had previously sent a label mapping for the FEC."

In short, LSR I remove the entry from its forwarding table.

> > > Furthermore, If the intermediate nodes between the ingress
> > > and egress do not
> > > all implement liberal label retention, then there may be some
delay in
> > > waiting for a periodically readvertised label or having to request
a label
> > > for a particular FEC.
> >
> > In case of rerouting on a new path, you're right, but the
> > draft brings nothing new. Again, you can refer to section
> > 2.6.2.1. of RFC 5036
> 
> I believe that this is an important deployment caveat that should be
added
> to the draft. In other words, liberal label retention mode may achieve
much
> faster convergence than conservative label retention mode.

Yes, but there is no change compared to RFC 5036. I don't see the point
of copy/pasting text from RFC 5036 which is not change by the draft.
This may lead to confusion as to whether or not there is a change.
 
> > > Finally, I suggest that a sentence be added stating that the LDP
label
> > > withgdrawal, or other methods that could be defined by the IETF
for use in
> > > egress PE fault detection can be selected at the ingress node as a
local
> > > implementation decision.
> >
> > You're right, in addition to the PE fault detection mechanism
> > provided by this draft, an ingress PE could, as a local
> > implementation decision, use additional methods to detect PE
> > failure. Eg BFD. But this is already a true statement with
> > RFC 5036 so I think this is largely independent of this draft.
> 
> I think this goes back to whether part of the problem the draft is
trying to
> solve is fault detection and notification.  

Indeed, this goes back to this.
The draft is solving the establishment of MPLS LSP by LDP when IGP areas
and IP aggregation are used between areas. This is done by using
"longest match" rather than "exact match". The notification of PE
failure is provided using Label Withdraw message exactly as per RFC
5036. There is no new mechanism defined by this draft.

> If so, I think that an operator
> being able to disable and set timers for this LDP signaling derived
fault
> detection and notification are important requirements.
> 
> Aslo, I don't believe that BFD is part of 5036.
> 
> >
> > > In my opinion, the above clarifications could be added during last
> > call
> > > comment resolution.
> >
> > OK, thanks.
> >
> > I'd be happy to further clarify these comments with you,
> > either on the MPLS mailing list or privately, and if needed,
> > to integrate the resulting required modifications in the draft.
> >
> 
> Let's have the discussion on the list so that others can comment as
they
> deem appropriate.
> Dave
> > Regards,
> > Bruno
> > > Dave
> > > > Please indicate whether you believe this draft is ready
> > for MPLS WG
> > > > last call.
> > > >
> > > > Thanks,
> > > >
> > > > George & Loa
> > > >

---

From: <[email-masked]>
Date: Tue, 29 Jan 2008 15:23:03 +0100

Hi Dave, all,

A few weeks ago, Dave asked for some additional clarifications in the draft regarding the conditions under which fault notification operates upon egress PE failure.

Following some first e-mail exchanges on the mailing list, we worked collaboratively off-line to agree on some text. 

We propose to add the following two clarifications:

- In section 5 "Label Mapping Procedure"

Following the existing text:
"FECs selected by this "Longest Match" label mapping procedure are distributed in an ordered way."

Addition of:
"In case of LER failure, the removal of reachability to the FEC occurs using standard LDP procedures as defined in [LDP]. Similarly, the FEC will be removed in an ordered way through the propagation of label withdraw messages. The use of this reachability information by application layers using the MPLS LSP (e.g., BGP) is outside the scope of this document."

- In section 7.2 "Impact on routing convergence time"

Following the existing text:
"In case of failure of the egress LER node, given that the IGP aggregates IP route on ABRs, the routing convergence behavior is changed compared to [LDP]. As the IGP does not carry specifics prefixes outside of the egress area, the IGP will not propagate the notification of node failure outside of the area."

Addition of:
"Application layers using the LSP may, as a local decision, use the availability of the MPLS LSP -as advertised by LDP- to achieve LER egress fault notification in addition to application layer fault detection mechanisms. For some applications (e.g., BGP) this is expected to be faster."

If the WG is fine with these clarifications, they will be added in the next revision of the draft.

Regards,
Bruno

> De [email-masked]
> 
> Hi Dave,
> 
> [...]
>

---

From: George Swallow <[email-masked]>
Date: Tue, 29 Jan 2008 14:56:20 -0500

Bruno -

It seems my call for "is it ready" has turned into a bit of a last call.
Could you update your draft with all the things you've been discussing
over the last month?  I'll issue the "official" last call as soon as it
is available.

Many thanks,

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

---

From: Dave McDysan <[email-masked]>
Date: Thu, 31 Jan 2008 09:50:29 -0500

Inclusion of this text in a revision addresses the issues I raised in
Vancouver and Email as part of the last call process.

Thanks,

Dave 

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Tuesday, January 29, 2008 9:23 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [mpls] draft-ietf-mpls-ldp-interarea-01.txt to 
> WG last call
> 
> Hi Dave, all,
> 
> A few weeks ago, Dave asked for some additional 
> clarifications in the draft regarding the conditions under 
> which fault notification operates upon egress PE failure.
> 
> Following some first e-mail exchanges on the mailing list, we 
> worked collaboratively off-line to agree on some text. 
> 
> "FECs selected by this "Longest Match" label mapping 
> procedure are distributed in an ordered way."
> 
> Addition of:
> "In case of LER failure, the removal of reachability to the 
> FEC occurs using standard LDP procedures as defined in [LDP]. 
> Similarly, the FEC will be removed in an ordered way through 
> the propagation of label withdraw messages. The use of this 
> reachability information by application layers using the MPLS 
> LSP (e.g., BGP) is outside the scope of this document."
> 
> 
> "In case of failure of the egress LER node, given that the 
> IGP aggregates IP route on ABRs, the routing convergence 
> behavior is changed compared to [LDP]. As the IGP does not 
> carry specifics prefixes outside of the egress area, the IGP 
> will not propagate the notification of node failure outside 
> of the area."
> 
> Addition of:
> "Application layers using the LSP may, as a local decision, 
> use the availability of the MPLS LSP -as advertised by LDP- 
> to achieve LER egress fault notification in addition to 
> application layer fault detection mechanisms. For some 
> applications (e.g., BGP) this is expected to be faster."
> 
> 
> > > > > - Add a statement to section 4, problem statement, indicating 
> > > > > that LDP label withdrawal can be used to advertise 
> the state of 
> > > > > a PE in a remote, summarized area/level, replacing 
> the function 
> > > > > done by the IGP in a
> > flat
> > > > > domain
> > > >
> > > >
> > > > The section "7.2. Impact on routing convergence time" 
> already has 
> > > > a discussion on this subject and states that "In case 
> of failure 
> > > > of the egress LER node, given that the IGP
> > > >    prefixes outside of the egress area, the IGP will 
> not propagate 
> > > > the
> > > >    notification will rely on LDP. The FEC(s) of the egress LER 
> > > > will be
> propagation of 
> > > > - or is not at the right place (section 4 vs section 
> 7.2)? In this 
> > > > case, we can further discuss this but I would rather 
> not add this 
> > > > in the section 4 which is about the problem statement)
> > > >
> > >
> > > is "Caveats for Deployment," which is not the best place to state 
> > > what functions the document is intended to describe.
> > 
> > As I understand your point, you're rather ok with the text in the 
> > draft and your concern is that discussion on PE failure 
> notification 
> > is an important point and therefore should be placed higher 
> in the document.
> > 
> > - section 4 introduce the problem statement so I don't 
> think this is 
> > the best place. Especially this the protocol extension is not yet 
> > specified and I don't think this is something which can be 
> discussed 
> > before specifying the solution.
> > 
> > it more "must read", but with the current wording of the 
> draft, again 
> > as service provider, this is definitely not a section I 
> would skipped.
> > 
> > > > > - Section 5:
> > > > already has a discussion on this subject and states 
> that "In case 
> > > > of failure of the egress LER node [..]. The FEC(s) of 
> the egress 
> > > > LER will be removed in an ordered way through the end-to-end 
> > > > propagation of the LDP withdraw message."
> > > >
> > > Vancouver, the current text of the draft does not have normative 
> > > text covering the cases of label withdrawal and how that could be 
> > > used by
> > other
> > > not appear to be the best place in the outluine of the draft to 
> > > state protocol requirements.
> > 
> > The draft does not introduce new LDP mechanism to advertise the 
> > failure of the remote PE. As per RFC 3036/5036, LDP already 
> withdraw 
> > the FEC which means the LSP is not useable anymore.
> > However, I see your point that some existing 
> implementations may not 
> > use this message as an indication of the failure of the 
> remote LER/PE 
> > but only consider the removing of the /32 in the IGP. In this case, 
> > the implementation would have to change to (also) take into account 
> > LDP events.
> > 
> > regardless of the longest match vs exact match question. On this 
> > point, you can also refer to my e-mail on this MPLS list 
> (2007/12/19) 
> > which also discus this point and relate the "mirror" 
> discussion in the IDR WG.
> > 
> > 
> > > > > exist with the same cumulative metric (or within an 
> > > > > implementation specific threshold that considers them equal), 
> > > > > then that ingress node will receive
> > multiple label
> (which is 
> > > > an issue in case of IGP rerouting to a new path toward 
> the same PE 
> > > > (FEC) ie new next-hop.  Cf section 2.6.2.1. of RFC 5036)
> > > >
> > > > implementation using ordered mode. For an implementation using 
> > > > independent mode, you're right there is a change but 
> the change is 
> > > > to implement ordered mode for the longest match FEC (the same 
> > > > ordered mode as specified in RFC 5036.)
> > > >
> > >
> > > clarification. To me, the current text implies a single 
> RIB prefix 
> > > of
> > a
> > (I guessed you meant section 5 rather than 4) This 
> paragraph describes 
> > what's new compared to RFC 5036 due to the use of a longest 
> match in 
> > the label mapping procedure. Namely these 2
> > points:
> > - when a prefix disappears in the RIB, another one could still be 
> > found as a (less) good match.
> > 
> > Actually the FEC selected using this longest match 
> procedure can only 
> > be propagated and dealt with using ordered mode. These FEC are not 
> > > > > There are also cases where two links along equal cost 
> IGP paths 
> > > > > could fail at nearly the same time, which could cause 
> all labels 
> > > > > to an FEC to
> > be
> > > > - is the network has a backup path (with higher IGP 
> metric) to the 
> > > > PE or not? ie is the routing behavior is an IGP 
> rerouting toward 
> > > > the same remote PE or do we lose connection to the PE.
> > >
> > > > > withdraw(s) for all prefixes before declaring the 
> egress PE to 
> > > > > be
> > > > down.
> > > >
> > > > I don't think any more thing is required but it would 
> help me if 
> > > > you could elaborate on your specific example 
> (especially providing 
> > > > more precision on the topology and the failures events.
> > >
> > In your example, the backbone area does not seem connected 
> so it's a 
> > big particular to discus this topology. (Is this on purpose 
> or did you 
> > omit some links which didn't seem relevant to your point?)
> > 
> > > which in turn will issue a label withdraw to I. However, 
> I still has 
> > > a
> > RIB
> > 	- according to the draft (section 5 "Label Mapping 
> Procedure"), it 
> > accepts the FEC since "its routing table contains an entry 
> (10/8) that 
> > matches the FEC Element (10.0.0.1/32) and the  advertising 
> LSR (B) is 
> > a next hop to reach the FEC.
> > 
> > Idem from C
> > 	- according to the draft (section 5 "Label Mapping 
> Procedure"), it 
> > accepts the FEC since "its routing table contains an entry 
> (10/8) that 
> > matches the FEC Element (10.0.0.1/32) and the  advertising 
> LSR (C) is 
> > a next hop to reach the FEC.)
> > 
> > 2) After the failure.
> > RIB: 10/8
> > 	- Next hop B
> > 	- Next hop C
> > 
> > > > > Furthermore, If the intermediate nodes between the 
> ingress and 
> > > > > egress do not all implement liberal label retention, 
> then there 
> > > > > may be some
> > delay in
> > > > In case of rerouting on a new path, you're right, but the draft 
> > > > brings nothing new. Again, you can refer to section 2.6.2.1. of 
> > > > RFC 5036
> > >
> > Yes, but there is no change compared to RFC 5036. I don't see the 
> > point of copy/pasting text from RFC 5036 which is not 
> change by the draft.
> > > > > egress PE fault detection can be selected at the 
> ingress node as 
> > > > > a
> > local
> > > > > implementation decision.
> > > >
> > > > failure. Eg BFD. But this is already a true statement with RFC 
> > > > 5036 so I think this is largely independent of this draft.
> > >
> > The draft is solving the establishment of MPLS LSP by LDP when IGP 
> > areas and IP aggregation are used between areas. This is 
> done by using 
> > > > I'd be happy to further clarify these comments with 
> you, either on 
> > > > the MPLS mailing list or privately, and if needed, to integrate 
> > > > the resulting required modifications in the draft.
> > > >
> > >