Subject: [Idr] WGLC on the draft-ietf-idr-best-external-05

From: "Susan Hares" <[email-masked]>
Date: Fri, 10 Feb 2012 22:09:07 -0500

This is to start a WGLC on draft-ietf-idr-best-eternal-05.txt which will run
from 2/11 - 2/25. 

Please send comments to the list.  

Sue and John 

-----------------

http://datatracker.ietf.org/doc/draft-ietf-idr-best-external

   This document extends that procedure to operate in environments where

   Route Reflection [RFC4456] or Confederations [RFC5065] are used and

   explains why advertising the additional routing information can

   improve convergence time without causing routing loops.

   Additional benefits include reduction of inter-domain churn and

   avoidance of permanent route oscillation.

---

From: Jay Borkenhagen <[email-masked]>
Date: Sat, 11 Feb 2012 06:26:18 -0500

Susan Hares writes:
 >  
 > 
 > This is to start a WGLC on draft-ietf-idr-best-external-05.txt which will run
 > from 2/11 - 2/25. 
 > 

I cannot support this draft in its current form, but I will suggest a
change that I would be able to support.

Prior to best-external when a router X in AS1 learns a route via ibgp
having a bgp next-hop of border router Y (also in AS1) for a route
coming from Y's neighboring AS2, X can be assured that if it can
somehow deliver packets destined for that route to router Y, that Y
will forward those packets out of AS1 into AS2.

With best-external, this is no longer necessarily the case, as Y's
announcement may be its best-external route that Y does not itself
use for its forwarding.

I think it's possible that many network designs today implicitly rely
on the current behavior.  Certainly many network operators believe it
to be so, and would be misled by best-external.

I do not think that the Deployment Considerations section goes far
enough to address this.  I agree that in most network designs, router
X would also learn the advertisement that router Y chooses as its
overall best and router X would make the same overall best-path choice
as router Y had made, but it is not a certainty that this is so and it
should not be assumed so here.

My suggestion to remedy this concern is to add text requiring that any
router software implementing best-external MUST enable it only as an
optional knob, with the existing "announce only one's overall best"
behavior continuing as the default.

If this suggestion is adopted, then the Deployment Considerations
section should be adjusted to say something like "Networks should
enable best-external only if they know their bgp mesh is constructed
in such a way that routers learning a non-overall-best best-external
route from some other router in their AS will also learn the same
overall-best route the other router preferred."  (Or to continue using
my example from above: routers in AS1 should enable best-external only
if their bgp mesh is constructed such that router X will always learn
the overall-best route preferred by router Y.)

Thanks.

						Jay B.

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 11 Feb 2012 06:32:17 -0500

Yes/support

Regards,
Jeff

On Feb 11, 2012, at 4:09, "Susan Hares" <[email-masked]<mailto:[email-masked]>> wrote:

This is to start a WGLC on draft-ietf-idr-best-eternal-05.txt which will run from 2/11 – 2/25.
Please send comments to the list.

Sue and John

-----------------

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 11 Feb 2012 17:45:56 +0100

Hi Jay,

 > behavior continuing as the default.
+
 > behavior continuing as the default.

The default today is not as you say above. Today if IBGP path is 
selected as best path ASBR/PE does not advertise anything into IBGP 
mesh. (If it advertised before ebgp learned path it will withdraw it). 
Typically this happens due to MED or Local-Preference.

"best-external" proposal does not reduce information advertised into 
IBGP mesh. Contrary it enhances it with additional paths which otherwise 
would be suppressed from getting advertised.

If ASBR/PE chooses as best path it's ebgp path it will advertise it as 
usual regardless if best-external knob is enabled or not.

To summarize I see no point of stating in "Deployment Considerations" 
that networks should configured their IBGP mesh correctly. I sort of 
take this as given ;)

Conclusion: I am fine to progress the draft as is.

Best,
R.

> [email-masked]

---

From: Jakob Heitz <[email-masked]>
Date: Sat, 11 Feb 2012 20:08:19 -0500

The introduction includes the sentence:
   There is also the possible concern regarding advertising a path
   different than the path that has been selected for forwarding.

The advertisement rules specify "MAY".

While the draft does not go into explicit details about what the
concerns are, I don't believe it needs to.

--
Jakob Heitz.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jay Borkenhagen
Sent: Saturday, February 11, 2012 3:26 AM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Idr] WGLC on the draft-ietf-idr-best-external-05

Thanks.

						Jay B.

---

From: Randy Bush <[email-masked]>
Date: Sat, 11 Feb 2012 17:26:44 -0800

> the overall-best route preferred by router Y.)

this makes sense to me.  pola.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 12 Feb 2012 11:11:44 +0100

> this makes sense to me.

care to elaborate how one would construct valid ibgp mesh in a way that 
overall best path in an AS will not be distributed to all bgp speakers ?

r.

---

From: Jay Borkenhagen <[email-masked]>
Date: Sun, 12 Feb 2012 11:09:27 -0500

> overall best path in an AS will not be distributed to all bgp speakers ?

Nope.  It's exactly the opposite: Proponents of any changes to
long-standing BGP behaviors must bear the burden of proof to show that
those changes will not break any non-fatally-flawed configurations.

So in the case of best-external: its proponents need to demonstrate
that a router X learning router Y's best-external but not overall best
route will not choose it as X's overall best, at least not until
network conditions change and router Y also considers that route to be
its overall best.

If this cannot be demonstrated, then best-external can still be made
available, but only by opting-in by explicitly choosing a non-default
behavior.

Also, "overall best path" is a local decision.  Different routers in
an AS often do select different overall best paths to the same
prefix.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 12 Feb 2012 22:09:35 +0100

> those changes will not break any non-fatally-flawed configurations.

Please show how best external will break anything.

> available, but only by opting-in by explicitly choosing a non-default

You are still missing the point. When best-external is configured it is 
not that ASBR/PE router (not acting as RR) will advertise something 
different. It is that router will advertise it's best ebgp learned path 
even if ibgp path is selected as best. For the latter ASBR/PE by default 
would not advertise anything.

With cluster external this is different hence requirement in the draft 
for client to client full mesh.

Regardless best-external is a optional configuration. Where in the draft 
you see a recommendation to modify the current 4271 default behaviour ?

> an AS often do select different overall best paths to the same

That can happen due to consideration of next hop metric .. and this has 
no bearing on the topic discussed here. As mentioned before IBGP path 
can win best path selection based on MED or Local-Pref comparison steps 
which are evaluated before comparing distance metric to bgp next hop.

R.

---

From: <[email-masked]>
Date: Mon, 13 Feb 2012 10:17:39 +0100

Support

________________________________

	De : [email-masked] [mailto:[email-masked]] De la part de Susan Hares
	Envoyé : samedi 11 février 2012 04:09
	À : [email-masked]
	Cc : [email-masked]
	Objet : [Idr] WGLC on the draft-ietf-idr-best-external-05

	This is to start a WGLC on draft-ietf-idr-best-eternal-05.txt which will run from 2/11 - 2/25. 

	Sue and John 

	-----------------

	 

	

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
Thank you.

---

From: Shane Amante <[email-masked]>
Date: Mon, 13 Feb 2012 08:15:08 -0700

I support WGLC of this doc.

-shane

---

From: Ilya Varlashkin <[email-masked]>
Date: Tue, 14 Feb 2012 22:46:26 +0100

support

/iLya

> Please send comments to the list. 

/iLya

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 16 Feb 2012 14:05:41 -0500

Support

-Jon

---

From: Uli Bornhauser <[email-masked]>
Date: Fri, 17 Feb 2012 22:08:20 +0100

Hi Robert, hi all,

let me contribute to the discussion with a small illustrative configuration:

                    RR(PE1, PE2, PE3)
                   .        .        .
                  . ID3     . ID2     . ID1
+-----+   5  +-----+  1  +-----+  2  +-----+
| PE1 |------| PE2 |-----|  X  |-----| PE3 |
+-----+......+-----+.....+-----+     +-----+
   | ^          | ^                     | ^
   | q          | r                     | p
   |            |                       |
   | MED 1      | MED 5                 | MED m
---+------------+---                 ---+---
        AS x                          AS y

.. = iBGP session

Even if at least in my understanding it is not "best practice", the example above gives a basic understanding on what problems best-external may induce under certain circumstances:
Assume we have the sketched network where three paths for the same destination are provided at three ASBRs PE1, PE2, and PE3. We have one RR that is part of a cluster that consists of RR, PE2, X, and PE3. For any reason, an additional iBGP session is kept between PE1 and PE2 as well as between PE2 and X.

Applying Best External, the following should happen  (according to my understanding):
+++ PE1 chooses q as best path and provides this path to PE2.
+++ PE2 knows q and r, provided by the same peer-AS x. Due to the MED, path q is preferred. Path r is best external according to the draft, so r is provided to RR, X, and PE1.
+++ Obviously, PE1 does not change its routing decision. Path q is still selected and announced.
+++ PE3 chooses p as best path and announces this path to RR.
+++ Due to the BGP ID, for example, RR prefers path p and spreads this path across the cluster.
+++ Knowing q, r, and p, PE2 chooses p as best path (r has lower MED than q, p comes along with a lower IGP distance than q): p < q < r (according to best-external). Path r is still announced as best external.
+++ X knows p and r. As path q is not known, is chooses r (lower IGP than p).

--- The routing is stable and X relies on that PE2 forwards traffic out of the system (via r). However, PE2 intends to forward traffic via X to PE3. Forwarding between PE2 and X forms a loop. Note that this behavior is stable, even if RR knows path q.

Due to this (I know constructed but illustrative) example, I agree to Jay and Randy. From my point of view, the draft should contain a *very very clear* preamble that refers to the possible risks. The draft may even contain a small example, e.g. the configuration provided here. 

Maybe I have missed an important aspect in my considerations, in that case I highly appreciate corrections and clarifications.

Have a nice weekend and best regards

Uli

Am 12.02.2012 um 22:09 schrieb Robert Raszuk:

> You are still missing the point. When best-external is configured it is not that ASBR/PE router (not acting as RR) will advertise something different. It is that router will advertise it's best ebgp learned path even if ibgp path is selected as best. For the latter ASBR/PE by default would not advertise anything.
> 
> With cluster external this is different hence requirement in the draft for client to client full mesh.
> 
> Regardless best-external is a optional configuration. Where in the draft you see a recommendation to modify the current 4271 default behaviour ?
> 
> That can happen due to consideration of next hop metric .. and this has no bearing on the topic discussed here. As mentioned before IBGP path can win best path selection based on MED or Local-Pref comparison steps which are evaluated before comparing distance metric to bgp next hop.
> 
> R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Feb 2012 23:24:54 +0100

Hi Uli,

Adjusting topology according to your offline message essentially
adding PE1-RR ibgp sessions:

               ..... RR(PE1, PE2, X, PE3)
           .....    .        .        .
       .....       . ID3     . ID2     . ID1
		
... = iBGP session

Let's analyze step by step your case below ...

And to RR.

+++ PE2 knows q and r, provided by the same peer-AS x. Due to the MED, 
path q is preferred. Path r is best external according to the draft, so 
r is provided to RR, X, and PE1.

Well best external is per session or per af. It is not immediately 
obvious what PE2 configuration is in your example. Assuming it is per AF.

+++ Obviously, PE1 does not change its routing decision. Path q is still 
selected and announced.
+++ PE3 chooses p as best path and announces this path to RR.

Nope. If q MED is 1 it wins over any integer m. Path q will be overall 
best in this RR cluster. So PE3 will choose path q as well.

+++ Due to the BGP ID, for example, RR prefers path p and spreads this 
path across the cluster.

BGP_ID does not matter here. RR would choose the overall best due to 
MED. In our case RR will choose path q as overall best (MED=1).

+++ Knowing q, r, and p, PE2 chooses p as best path (r has lower MED than q

Wrong .. r=5 & q=1 so qMED < rMED ... q remains best.

, p comes along with a lower IGP distance than q): p < q < r (according 
to best-external).

IGP distance does not matter at all here. Best path decision is made due 
to MED.

Path r is still announced as best external.

Ok.

+++ X knows p and r. As path q is not known, is chooses r (lower IGP 
than p).

Wrong. Path q will be known via RR. X will again use MED and will select 
path q MED=1 as best.

--- The routing is stable and X relies on that PE2 forwards traffic out 
of the system (via r). However, PE2 intends to forward traffic via X to 
PE3.

What does it mean that PE2 "intends" ? Traffic to our destination will 
exit via PE2's best path so via q. Do you mean to some other destination 
? It's quite irrelevant then.

   Forwarding between PE2 and X forms a loop. Note that this behavior is 
stable, even if RR knows path q.

I do not see a loop.

---

Best,
R.

> Even if at least in my understanding it is not "best practice", the
> example above gives a basic understanding on what problems best-external
> may induce under certain circumstances:
> Assume we have the sketched network where three paths for the same
> destination are provided at three ASBRs PE1, PE2, and PE3. We have one
> RR that is part of a cluster that consists of RR, PE2, X, and PE3. For
> any reason, an additional iBGP session is kept between PE1 and PE2 as
> well as between PE2 and X.
>
> +++ PE2 knows q and r, provided by the same peer-AS x. Due to the MED,
> path q is preferred. Path r is best external according to the draft, so
> r is provided to RR, X, and PE1.
> +++ Knowing q, r, and p, PE2 chooses p as best path (r has lower MED
> than q, p comes along with a lower IGP distance than q): p < q < r
> (according to best-external). Path r is still announced as best external.
> --- The routing is stable and X relies on that PE2 forwards traffic out
> of the system (via r). However, PE2 intends to forward traffic via X to
> PE3. Forwarding between PE2 and X forms a loop. Note that this behavior
> is stable, even if RR knows path q.
>
>
> Due to this (I know constructed but illustrative) example, I agree to
> Jay and Randy. From my point of view, the draft should contain a *very
> very clear* preamble that refers to the possible risks. The draft may
> even contain a small example, e.g. the configuration provided here.
>
> Maybe I have missed an important aspect in my considerations, in that
> case I highly appreciate corrections and clarifications.
>
>> You are still missing the point. When best-external is configured it
>> is not that ASBR/PE router (not acting as RR) will advertise something
>> different. It is that router will advertise it's best ebgp learned
>> path even if ibgp path is selected as best. For the latter ASBR/PE by
>> default would not advertise anything.
>>
>> Regardless best-external is a optional configuration. Where in the
>> draft you see a recommendation to modify the current 4271 default
>> behaviour ?
>>
>> That can happen due to consideration of next hop metric .. and this
>> has no bearing on the topic discussed here. As mentioned before IBGP
>> path can win best path selection based on MED or Local-Pref comparison
>> steps which are evaluated before comparing distance metric to bgp next
>> hop.
>>
>> R.
>> [email-masked] <mailto:[email-masked]>

---

From: Jakob Heitz <[email-masked]>
Date: Sat, 18 Feb 2012 22:25:56 -0500

There indeed is a loop.
Robert, go back and do it again, but remember that MED from different ASs are not comparable.

Now the reason for the loop is not best-external, although it makes your example easier.
The reason is that you are leaking routes from outside a RR cluster to a RR client.

I believe that the RR rfc4456 contains enough warnings about the trouble
you can get into when mixing MED and clusters in strange ways, particularly
the sentence:

   To prevent routing loops and maintain consistent routing view, it is
   essential that the network topology be carefully considered in
   designing a route reflection topology.

I have contrived a more complicated topology to illustrate.
It does not require best-external.
In the drawing, clusters are circled in green.
Known paths are indicated in brown, the best path is circled in red.
IGP distances are in yellow. BGP connections in black.

--
Jakob Heitz.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, February 17, 2012 2:25 PM
To: Uli Bornhauser
Cc: [email-masked] List
Subject: Re: [Idr] WGLC on the draft-ietf-idr-best-external-05

Hi Uli,

... = iBGP session

And to RR.

Ok.

I do not see a loop.

---

Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 19 Feb 2012 12:02:37 +0100

Jakob,

> Robert, go back and do it again, but remember that MED from different

Are we talking theory here or practice ? I was talking practice.

"always-compare-med" and "deterministic-med" are recommended and 
deployed configurations in vast majority of BGP networks today.

Best,
R.

---

From: Jakob Heitz <[email-masked]>
Date: Sun, 19 Feb 2012 10:32:04 -0500

I was talking standardization.

--
Jakob Heitz.

---

From: <[email-masked]>
Date: Mon, 20 Feb 2012 14:10:55 +0000

Hi Pedro, Rex, Enke, Pradosh, Hannes,

> This is to start a WGLC on draft-ietf-idr-best-eternal-05.txt which will run from 2/11 - 2/25.

Please find below some proposed comments.

I guess sections 8 to 10 should be sub-sections of 7 and hence be numbered 7.1 to 7.3.

"Early BGP implementations where very concerned with reducing state as they
   where limited to relatively low memory footprints (e.g. 16 MB)."
Sure, computing capacities have improved. But so does the number of BGP routes. So if your point is that control plane capacity is not a problem anymore, IMHO you need to talk about both the evolution of capacities and the evolution of routes / requirements. Then you could draw a conclusion.

"   o  Faster restoration of connectivity.  By providing additional

      paths, that may be used to fail over in case the primary path

      becomes invalid or is withdrawn."
Partially agreed. To some extent, those additional paths may not really be used for forwarding as the egress has not installed them in the FIB. IMO this should be discussed.

"   The objective of this protocol extension is to improve the quality of

   the routing information known to a particular BGP mesh with minimum

   additional cost in terms of processing and state."

I would propose :s/quality/quantity

"with minimum additional cost in terms of processing and state."
Compared to what? E.g. is an additional path provided by best-external has less processing and state that an additional path provided by add-path?
IMHO, the key benefit of external best is that it does not require protocol extension on peers.

Hence I would propose "   The objective of this protocol extension is to improve the quantity of

   the routing information known to a particular BGP mesh with no protocol extension and no implementation change on BGP peers"

§5. Advertisement Rules
All new (best external specific) advertisements are proposed as "MAY". Does this mean that vanillia (RFC 4271) implementations are de facto compliant with draft-ietf-idr-best-external? (Hence compliance with draft-ietf-idr-best-external does not mean anything?)
I would propose the additional text: "An implementation compliant with this specification MUST implement the above advertisement rules. They SHOULD be disabled by default". (Alternatively, you could restrict the "MUST" to rules 1 and 4 if you prefer, but IMHO 1 & 4 are expected to be implemented by an implementation claiming compliance with this specification.

« whenever a GP speaker »
I guess :s/GP/BGP

«  Inconsistency between routing and forwarding may happen, whenever a

   GP speaker chooses to advertise an external route into IBGP that is

   different from the overall best route and its overall best is

   external. »

IMHO, It would help the reader to state whether this can happen with best-external (my understanding is that this cannot). Or may be moving this section into appendix if it only applies to the original RFC 1771 specification and not to best external.

(I have the feeling that someone reading the specification quickly may think/fear that enabling best-external may lead to such inconsistency between routing & forwarding)

8. Fast Connectivity Restoration

A drawback is that the best-external route, advertised in iBGP, can't be readily used as backup because the backup egress has not installed it. IMO, this section should more explicitly talks about this. Otherwise, most people/ingress routers will assume that all is fine since they know the backup route. . The last sentence ("Note that...") is not enough IMHO. Otherwise it should say that the backup egress (i.e. routers compliant with best-external) SHOULD implement the preinstallation in the FIB of the back route).
In particular, when the nominal egress ASBR detects the failure of its external link/neighbor, it could locally switch to its pre-computed backup ASBR (aka PE-CE FRR). But when it does so, the backup ASBR has no way to know that the nominal has failed and hence will forward the traffic back to the nominal ASBR, forming a transient forwarding loop.

When BGP routes are MPLS labeled (e.g. SAFI 4, 128) may be one way to avoid this could be to advertise the best-external route with a label pointing to the external interface (hence bypassing the IP lookup/FIB and breaking the forwarding loop). IMO, the draft should talk about this and recommend (SHOULD) this behavior.
For IP routes, there may be solutions also. The document should also talk about this. In the absence of solutions, people should be warned about this (both in this section and in section 11 "deployment considerations").

"there are 2 or clusters/sub-AS-es"
I guess :s/or/or more

Many thanks,
Best regards,
Bruno

From: [email-masked] [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Saturday, February 11, 2012 4:09 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Idr] WGLC on the draft-ietf-idr-best-external-05

Sue and John

-----------------

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 20 Feb 2012 15:45:08 +0100

Hello Bruno,

I am rather of the opinion that we should keep forwarding and control 
plane in separate documents.

Just like drafts: add-paths (draft-ietf-idr-add-paths) and 
fast-connectivity-restoration (draft-pmohapat-idr-fast-conn-restore).

The reason being that I may use other forwarding paradigms then MPLS or
IP/GRE.

Hello Authors,

Since we are at it and since I know there is a lot of confusion reg 
potential overlap between best-external and add-paths perhaps a small 
clarification in the deployment section would be useful.

Best regards,
R.

> A drawback is that the best-external route, advertised in iBGP, can’t be
> readily used as backup because the backup egress has not installed it.
> IMO, this section should more explicitly talks about this. Otherwise,
> most people/ingress routers will assume that all is fine since they know
> the backup route. . The last sentence (“Note that…”) is not enough IMHO.
> Otherwise it should say that the backup egress (i.e. routers compliant
> with best-external) SHOULD implement the preinstallation in the FIB of
> the back route).
>
> In particular, when the nominal egress ASBR detects the failure of its
> external link/neighbor, it could locally switch to its pre-computed
> backup ASBR (aka PE-CE FRR). But when it does so, the backup ASBR has no
> way to know that the nominal has failed and hence will forward the
> traffic back to the nominal ASBR, forming a transient forwarding loop.
>
> When BGP routes are MPLS labeled (e.g. SAFI 4, 128) may be one way to
> avoid this could be to advertise the best-external route with a label
> pointing to the external interface (hence bypassing the IP lookup/FIB
> and breaking the forwarding loop). IMO, the draft should talk about this
> and recommend (SHOULD) this behavior.
>
> For IP routes, there may be solutions also. The document should also
> talk about this. In the absence of solutions, people should be warned
> about this (both in this section and in section 11 “deployment
> considerations”).
>

---

From: <[email-masked]>
Date: Mon, 20 Feb 2012 16:53:17 +0000

Hello Robert, all

>From: Robert Raszuk [mailto:[email-masked]] Sent: Monday, February 20, 2012 3:45 PM
>
>Hello Bruno,
>

As people wish.
But IMO the draft needs to state that best-external alone is not enough to provide fast connectivity restoration. A forwarding plane feature is required on the nominal egress (on the best external router). It could list a few, without going into details on the forwarding plane aspects.

>The reason being that I may use other forwarding paradigms then MPLS or

Well, I don't see this reason as a show stopper. The draft can explain the issue and the typical type of solutions required (typically, not performing a regular IP lookup on the nominal egress). Then summarize the solutions for typical deployments. If you use a specific forwarding paradigm, then it will be up to you to find the specific solution.

Best regards,
Bruno

>> A drawback is that the best-external route, advertised in iBGP, can't be
>> the backup route. . The last sentence ("Note that...") is not enough IMHO.
>> about this (both in this section and in section 11 "deployment
>> considerations").
>>

---

From: <[email-masked]>
Date: Mon, 20 Feb 2012 17:07:06 +0000

:s/nominal egress/backup egress

(actually, the router advertising a best-external route)

Sorry for the spam.

>But IMO the draft needs to state that best-external alone is not enough to
>provide fast connectivity restoration. A forwarding plane feature is
>required on the nominal egress (on the best external router). It could list
>a few, without going into details on the forwarding plane aspects.
>
>Well, I don't see this reason as a show stopper. The draft can explain the
>issue and the typical type of solutions required (typically, not performing
>a regular IP lookup on the nominal egress). Then summarize the solutions for
>typical deployments. If you use a specific forwarding paradigm, then it will
>be up to you to find the specific solution.
>
>Best regards,
>Bruno
>
>>Hello Authors,
>>
>____________________________________________________________________________
>_____________________________________________
>
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
>ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>As emails may be altered, France Telecom - Orange shall not be liable if
>this message was modified, changed or falsified.
>Thank you.
>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 20 Feb 2012 17:24:52 +0000

Comments In-Line..

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, February 20, 2012 11:53 AM
To: [email-masked]
Cc: [email-masked]; Susan Hares
Subject: Re: [Idr] WGLC on the draft-ietf-idr-best-external-05

Hello Robert, all

As people wish.
But IMO the draft needs to state that best-external alone is not enough to provide fast connectivity restoration. A forwarding plane feature is required on the nominal egress (on the best external router). It could list a few, without going into details on the forwarding plane aspects.
[Jim U>] Agreed. Convergence is also a function of getting paths all the way to the ingress PE.. Need to not be constrained by the notion of a single AS here...So as an ex.. a unique RD is required to ensure the backup paths are unique in a set of AS topologies..Is there a plan to incorporate this feature with the fast-connectivity draft? 

Best regards,
Bruno

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Feb 2012 03:52:28 +0530

>> plane in separate documents.

as v6 kept addressing separate from routing, right?  please no.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 20 Feb 2012 23:34:56 +0100

> as v6 kept addressing separate from routing, right?  please no.

Indeed .. much better would be to have single RFC which not only defines 
the v6 address format, but also in the very same doc defines all new 
protocol extensions to distribute the new address - BGP, OSPFv3, ISIS, 
DNS, DHCP you name it ... all in one spec.

What an awesome idea !!!

r.

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Feb 2012 10:06:05 +0530

> as v6 kept addressing separate from routing, right?  please no.

to be more clear and less sarcastic, jay, uli and others have pointed
out a non-trivial operational problem between the control and data plane
in this draft.  the way to solve that problem is not by removing the
data plane from this discussion or this document.

jay has made a reasonable seeming suggestion for solving the particular
problem he raised.

randy