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

From: George Swallow <[email-masked]>
Date: Tue, 18 Dec 2007 17:09:09 -0500

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

---

From: Rahul Aggarwal <[email-masked]>
Date: Tue, 18 Dec 2007 14:49:19 -0800 (PST)

Hi George,

Yes. I believe this draft is ready for WG last call.

rahul

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 18 Dec 2007 16:18:21 -0800

George,

> Please indicate whether you believe this draft is ready for MPLS WG last

I think the draft is ready for MPLS WG last call.

Yakov.

---

From: "Sina Mirtorabi" <[email-masked]>
Date: Tue, 18 Dec 2007 18:05:16 -0800

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..

- 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. 

Thanks
Sina

->-----Original Message-----
->From: George Swallow [mailto:[email-masked]] 
->Sent: Tuesday, December 18, 2007 2: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
->
->
->

---

From: "JACQUENET Christian RD-DDEV-REN" <[email-masked]>
Date: Wed, 19 Dec 2007 10:19:13 +0100

Dear all,

I think the draft is ready for WG last call.

Cheers,

Christian. 

-----Message d'origine-----
De : George Swallow [mailto:[email-masked]] 
Envoyé : mardi 18 décembre 2007 23:09
À : [email-masked]
Objet : [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

---

From: Dave McDysan <[email-masked]>
Date: Wed, 19 Dec 2007 10:01:59 -0500

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

- 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.

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.

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. 

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. 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.

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. 

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. 

In my opinion, the above clarifications could be added during last call
comment resolution.

Dave

> -----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
>

---

From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
Date: Wed, 19 Dec 2007 19:38:32 +0100

Hi Sina,

Thanks for your comments.

Answers inlined.

> De : Sina Mirtorabi [mailto:[email-masked]]
> Envoyé : mercredi 19 décembre 2007 03:05
> À : George Swallow; [email-masked]
> Objet : RE: [mpls] draft-ietf-mpls-ldp-interarea-01.txt to WG last call
> 
> Geroge,
> 
> 
> I have two comments
> 
> 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.  

> 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.

---

From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
Date: Thu, 20 Dec 2007 21:41:01 +0100

Hi Dave,

> summarized area/level, replacing the function done by the IGP in a
flat

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)
 
> 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? 

> 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)
 
> 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.)

> withdrawn, and reestablshed shortly thereafter.

The example is not fully clear to me. Do you mean
- the _link_ is reestablished? or the FEC?.
- 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.

> This behavior will differ

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.
 
> waiting for a periodically readvertised label or having to request a
label

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
 
> egress PE fault detection can be selected at the ingress node as a
local

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.
 
> In my opinion, the above clarifications could be added during last
call

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.

Regards,
Bruno

---

From: "Sina Mirtorabi" <[email-masked]>
Date: Thu, 20 Dec 2007 17:31:15 -0800

Hi Bruno, 

->
->Hi Sina,
->
->Thanks for your comments.
->
->Answers inlined.
->
->> -----Message d'origine-----
->> De : Sina Mirtorabi [mailto:[email-masked]]
->> Envoyé : mercredi 19 décembre 2007 03:05 À : George Swallow; 
->> [email-masked] 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?
->

Thank you, this is fine.

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

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

Well the draft purpose is to eliminate the requirement for having /32 routes for LERs, which said otherwise promote suboptimal path for LSP. Therefore it should explicitly mention that as a result of that choice suboptimal path could be introduced. Of course this is the well known scalability versus optimality but now that we are on this subject let me ask the authors of the draft, how much scalability are we gaining here for giving away LSP optimum path? 

It is sufficient to have /32 routes only for PE routers (versus all routers in the network) therefore how many PE routers a very large network would have that would result to such a scalability issue in IGP? I think the choice of giving away optimal path versus scalability needs to be carefully considered by operators..

Thanks
Sina

->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:[email-masked]]
->> ->Sent: Tuesday, December 18, 2007 2: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: Fri, 21 Dec 2007 12:27:14 +0100

Hi Sina,

Answers inlined

> ->Would this be fine for you?
 
Good
 
> Well the draft purpose is to eliminate the requirement for having /32
routes for LERs, which said
> otherwise promote suboptimal path for LSP. Therefore it should
explicitly mention that as a result
> of that choice suboptimal path could be introduced. Of course this is
the well known scalability
> versus optimality 

The purpose of the draft is not to promote any choice. It's to give the
ability for LDP to set up LSP when the IGP performs IP aggregation. This
is a routing consideration which is for example described in RFC 2966.
As you said, the trade off of this is well known. Regarding this
technical point, I don't think this trade off need to be discussed again
in this draft and hence referencing RFC 2966 would be enough. Did you
agree on this by saying that "the trade off of this is well known"?

However, regarding more editorial choices, currently the draft takes the
point of view of an existing IP network (with IGP area) which faces the
requirement to introduce MPLS LSP. With this point of view, the draft
does not change anything as far as routing (sub) optimality is
concerned.
But thanks to your comment, I see that someone may read the draft with
the different perspective. For example the one of a service provider
already leaking all /32 in the IGP and considering removing these /32 by
using this draft. In this case, _if_ it used to propagate IGP metrics to
these /32 (opposed to overriding IGP metrics between areas), using this
draft and performing aggregation in the IGP may result in suboptimal
routing. And indeed, a reminded on this in the draft could help.

In short, you're right that the draft should say a word on this.
How about placing this in "7.1. Deployment consideration" with something
like "A service provider which used to leak all specific prefixes in the
IGP and now considers performing IP aggregation on ABR should be aware
that this may result in suboptimal routing as discussed in RFC 2966."

If this fine for would or are you thinking of something different or
additional?

> but now that we are on this subject let me ask the authors of the
draft, how much
> scalability are we gaining here for giving away LSP optimum path?
> It is sufficient to have /32 routes only for PE routers (versus all
routers in the network)
> therefore how many PE routers a very large network would have that
would result to such a
> scalability issue in IGP?

The gain is less prefixes in the IGP, less churn in the IGP by not
propagating failures events outside of the area, less prefixes in the
RIB. Exactly "how much" is dependant on the use case. Again RFC 2966
already discuss this. (Although putting more emphasis on the control
plane than on the forwarding plane (FIB)).
 
> I think the choice of giving away optimal path versus scalability
needs
> to be carefully considered by operators..

Agreed and indeed your comments helped in this regards.

Thanks,
Bruno

---

From: Dave McDysan <[email-masked]>
Date: Thu, 27 Dec 2007 11:03:31 -0500

Hi Bruno,

I was on vacation, returning today.

A few responses in line.

Dave 

> From: DECRAENE Bruno RD-CORE-ISS 
> [mailto:[email-masked]] 
> Sent: Thursday, December 20, 2007 3:41 PM
> To: Dave McDysan
> Cc: [email-masked]
> Subject: RE: [mpls] draft-ietf-mpls-ldp-interarea-01.txt to 
> WG last call
> 
> Hi Dave,
> 
> 
> > - Add a statement to section 4, problem statement, 
> indicating that LDP
> label
> 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 
> - 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.

> 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."
> 

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.

> > If multiple paths from some ingress node to the egress node 
> exist with
> the
> > same cumulative metric (or within an implementation 
> specific threshold
> that
> 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. 

> 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)
> 
> 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 think there may be other issues with independent node depending upon the
order of label withdrawals received by an ingress mode. 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.

Also, I think the references to 3036 in the draft need to be replaced by
5036.

>  
> > There are also cases where two links along equal cost IGP 
> paths could
> fail
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"

> 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). 

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). 

>  
> > Furthermore, If the intermediate nodes between the ingress 
> and egress
> do not
> 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.

> 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.  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. 

> 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.

Thanks,

Dave

> > > Please indicate whether you believe this draft is ready 
> for MPLS WG 
> > > last call.
> > >
> > > Thanks,
> > >
> > > George & Loa
> > >

---

From: "Sina Mirtorabi" <[email-masked]>
Date: Thu, 27 Dec 2007 19:34:46 -0800

Hi Bruno,

->As you said, the trade off of this is well known. Regarding 
->this technical point, I don't think this trade off need to be 
->discussed again in this draft and hence referencing RFC 2966 
->would be enough. Did you agree on this by saying that "the 
->trade off of this is well known"?

A reference to RFC2966 would be fine

->However, regarding more editorial choices, currently the 
->draft takes the point of view of an existing IP network (with 
->IGP area) which faces the requirement to introduce MPLS LSP. 
->With this point of view, the draft does not change anything 
->as far as routing (sub) optimality is concerned.

It does, the justification for the draft (also mentioned in the problem
statement of the draft) is to eliminate /32 route to LERs, therefore the
potential introduction of sub-optimal routing. There are networks that
already do aggregations but leak /32 routes for LERs..

->But thanks to your comment, I see that someone may read the 
->draft with the different perspective. For example the one of 
->a service provider already leaking all /32 in the IGP and 
->considering removing these /32 by using this draft. In this 
->case, _if_ it used to propagate IGP metrics to these /32 
->(opposed to overriding IGP metrics between areas), using this 
->draft and performing aggregation in the IGP may result in 
->suboptimal routing. And indeed, a reminded on this in the 
->draft could help.

Yes 

->
->In short, you're right that the draft should say a word on this.
->How about placing this in "7.1. Deployment consideration" 
->with something like "A service provider which used to leak 
->all specific prefixes in the IGP and now considers performing 
->IP aggregation on ABR should be aware that this may result in 
->suboptimal routing as discussed in RFC 2966."

I wouldn't say "all" specific prefixes but /32 LER's address.

Sina->> but now that we are on this subject let me ask the authors of
the
Sina->draft, how much
Sina->> scalability are we gaining here for giving away LSP optimum
path?
Sina->> It is sufficient to have /32 routes only for PE routers (versus
all
Sina->routers in the network)
Sina->> therefore how many PE routers a very large network would have
that
Sina->would result to such a
Sina->> scalability issue in IGP?

->The gain is less prefixes in the IGP, less churn in the IGP 
->by not propagating failures events outside of the area, less 
->prefixes in the RIB. Exactly "how much" is dependant on the 
->use case. Again RFC 2966 already discuss this. (Although 
->putting more emphasis on the control plane than on the 
->forwarding plane (FIB)).

I think everybody knows the benefit of 'less' prefix in IGP, but the
question was how many /32 prefix (for LERs only) even a large network
needs to carry that require one to aggregate /32 prefix for LERs, use
your draft and introduce sub-optimal routing? I don't think the
reduction of 100-200 prefixes worth the introduction of suboptimal
routing...

sina->> I think the choice of giving away optimal path versus
scalability
Sina->needs
Sina->> to be carefully considered by operators..

->Agreed and indeed your comments helped in this regards.

I agree with your agreement ;-)

thanks
Sina

---

From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
Date: Mon, 31 Dec 2007 16:50:53 +0100

Hi Sina,

> A reference to RFC2966 would be fine

Ok.
 
> I wouldn't say "all" specific prefixes but /32 LER's address.

Right.
We can even say "/32 LER's loopback addresses"

> reduction of 100-200 prefixes worth the introduction of suboptimal

I know some deployments with significantly more LER/PE and where routing
per /32 is absolutely not a requirement (eg both ABRs are very close, TE
requirements to (equally) load balance the traffic on expensive local
links whatever remote failures in the backbone).