Subject: Review Call: draft-hsmit-mpls-igp-spf-01.txt

From: Alex Zinin <[email-masked]>
Date: Fri, 19 Mar 2004 17:51:21 -0800

Folks-

 In preparation for the WG Last Call that will be started in a few weeks, we
 would like to solicit reviews of the draft-hsmit-mpls-igp-spf-01.txt document.
 The document is a WG item with the target status as an Informational RFC.

 Abstract below:

   This document describes how conventional hop-by-hop link-state
   routing protocols interact with new Traffic Engineering capabilities
   to create IGP shortcuts.  In particular this document describes how
   Dijkstra's SPF algorithm should be adapted so that link-state IGPs
   will calculate IP routes to forward traffic over tunnels that are
   set up by Traffic Engineering.

 The document is available at
 http://www.ietf.org/internet-drafts/draft-hsmit-mpls-igp-spf-01.txt
   
 Please send your comments to [email-masked]
   
-- 
Alex
http://www.psg.com/~zinin/

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

---

From: Christian Hopps <[email-masked]>
Date: Sat, 20 Mar 2004 09:45:41 -0800

>         Calculating IGP Routes Over Traffic Engineering Tunnels
>
>                     draft-shen-mpls-igp-spf-01.txt

[...]

Note, this correctly states when moved to PATHS.

>    During SPF, when a router finds the path to a new node (in other
>    words, this new node is moved from the TENTative list to the PATHS
>    list), the router must determine the first-hop information.  There
>    are three possible ways to do this:
>
>       - Examine the list of tail-end routers directly reachable via a
>         TE-tunnel. If there is a TE-tunnel to this node, we use the
>         TE-tunnel as the first-hop.
>
>       - If there is no TE-tunnel, and the node is directly connected, 
> we
>         will use the first-hop information from the adjacency database.
>
>       - If the node is not directly connected, and is not directly
>         reachable via a TE-tunnel, we will copy the first-hop
>         information from the parent node(s) to the new node.

[...]

> 5. Special cases and exceptions
>
>    The Shortest Path First algorithm will find equal-cost parallel 
> paths
>    to destinations. The enhancement described in this document does not
>    change this. Traffic can be forwarded over one or more native IP
>    paths, over one or more TE-tunnels, or over a combination of native
>    IP paths and TE-tunnels.
>
>    A special situation occurs in the following topology:
>
>
>    rtrA -- rtrB -- rtrC
>             |       |
>            rtrD -- rtrE
>
>
>    Assume all links have the same cost. Assume a TE-tunnel is set up
>    from rtrA to rtrD. When the SPF calculation puts rtrC on the
>    TENTative list, it will realize that rtrC is not directly connected,
>    and thus it will use the first-hop information from the parent. 
> Which
>    is rtrB.  When the SPF calculation on rtrA puts rtrD on the 
> TENTative
>    list, it realizes that rtrD is the tail-end of a TE-tunnel. Thus 
> rtrA
>    will install a route to rtrD via the TE-tunnel, and not via rtrB.

This incorrectly indicates "puts rtrD on the TENTative list..." If a TE 
nexthop will replace existing nexthops for rtrD it will be done when 
rtrD is placed in PATHS.

[...]

> 6. Metric adjustment of IP routes over TE-tunnels
>
>    When an IGP route is installed in the routing table with a TE-tunnel
>    as next hop, an interesting question is what should be the cost or
>    metric of this route ?  The most obvious answer is to assign a 
> metric
>    that is the same as the IGP metric of the native IP path as if the
>    TE-tunnels did not exist.  For example, rtrA can reach rtrC over a
>    path with a cost of 20. X is an IP prefix advertised by rtrC. We
>    install the route to X in rtrA's routing table with a cost of 20.
>    When a TE-tunnel from rtrA to rtrC comes up, by default the route is
>    still installed with metric of 20, only the next-hop information for
>    X is changed.
>
>    While this scheme works well, in some networks it might be useful to
>    change the cost of the path over a TE-tunnel, to make the route over
>    the TE-tunnel less or more preferred than other routes.
>
>    For instance when equal cost paths exist over a TE-tunnel and over a
>    native IP path, by adjusting the cost of the path over the 
> TE-tunnel,
>    we can force traffic to prefer the path via the TE-tunnel, to prefer
>    the native IP path, or to load-balance among them. Another example 
> is
>    when multiple TE-tunnels go to the same or different destinations.
>    Adjusting TE-tunnel metrics can force the traffic to prefer some TE-
>    tunnels over others regardless of underlining IGP cost to those
>    destinations.
>
>    Setting a manual metric on a TE-tunnel does not impact the SPF
>    algorithm itself.  It only affects comparison of the new route with
>    existing routes in the routing table. Existing routes can be either
>    IP routes to another router that advertises the same IP prefix, or 
> it
>    can be a path to the same router, but via a different outgoing
>    interface or different TE-tunnel.  All routes to IP prefixes
>    advertised by the tail-end router will be affected by the TE-tunnel
>    metric. Also the metrics of paths to routers that are downstream of
>    the tail-end router will be influenced by the manual TE-tunnel
>    metric.
>
>    This mechanism is loop free since the TE-tunnels are source-routed.
>    The end result of TE-tunnel metric adjustment is more control over
>    traffic loadsharing. If there is only one way to reach a particular
>    IP prefix through a single TE-tunnel, then no matter what metric is
>    assigned, the traffic has only one path to go.

The mechanism is loop free b/c the source routed tunnels are only 
utilized after a node is placed in PATHS. This is critical, and I think 
should be stated. Simply shoving a packet down a source routed tunnel 
doesn't guarantee that it won't loop back. The fact that the tunnel was 
chosen only after SPF guaranteed the tunnel endpoint was truly 
downstream towards the destination is what makes it loop free.

>    When the manual TE-tunnel metric is configured to be larger than
>    the IGP native path metric, this TE-tunnel can not be used in the
>    SPF calculation. Otherwise a routing loop may be formed. Here is
>    an example:

Note stating "this TE-tunnel can not be used in the SPF calculation" is 
confusing, as its critical that TE-tunnels *not* be used in the SPF 
calculation.

This is stated earlier in this section:

"Setting a manual metric on a TE-tunnel does not impact the SPF 
algorithm itself."

The only thing the TE tunnel metric can affect is whether TE tunnel 
nexthop is chosen over the IGP nexthop when a route is being installed, 
and when *IGP metric* based ECMP routes are being considered.

> Shen, Smit                 Expires June 2004                    [Page 
> 4]
> 
> Internet Draft          IGP ShortCut Over MPLS LSPs        December 
> 2003
>
>
>       (src)  2         2
>         A ------ B ------- C
>         |        =========>|
>        5|            30    |2
>         |                  |
>         D ---------------- E (dst)
>                  5
>
>    There is a TE-tunnel from B->C with manual tunnel metric of 30.
>    The shortest path from source A to destination E is A->B->C->E with
>    the path metric of 6, thus A will use B as the nexthop router. If
>    this TE tunnel could be used by B's SPF calculation with the
>    metric of 30 for the span of B->C, then B->C->E will have the path
>    metric of 32, but B->A->D->E path will only have the metric of 12.
>    So B would send the traffic back to A, a routing loop formed.
>
> 6.1. Absolute and relative metrics
>
>    It is possible to represent the TE-tunnel metric in two different
>    ways: an absolute (or fixed) metric or a relative metric, which is
>    merely an adjustment of the dynamic IGP metric as calculate by the
>    SPF computation.  When using an absolute metric on a TE-tunnel, the
>    cost of the IP routes in the routing table does not depend on the
>    topology of the network. Note that this fixed metric is not only 
> used
>    to compute the cost of IP routes advertised by the router that is 
> the
>    tail-end of the TE-tunnel, but also for all the routes that are
>    downstream of this tail-end router.  For example, if we have TE-
>    tunnels to two core routers in a remote POP, and one of them is
>    assigned with absolute metric of 1, then all the traffic going to
>    that POP will traverse this low-metric TE-tunnel.
>
>    By setting a relative metric, the cost of IP routes in the routing
>    table is based on the IGP metric as calculated by the SPF
>    computation.  This relative metric can be a positive or a negative
>    number.  Not configuring a metric on a TE-tunnel is a special case 
> of
>    the relative metric scheme. No metric is the same as a relative
>    metric of 0.  The relative metric is bounded by minimum and maximum
>    allowed metric values while the positive metric disables the
>    TE-tunnel in the SPF calculation.

I've always thought that positive relative metrics are silly. Do we 
really need this method for disabling use of the tunnel in the IGP?

Chris.

---

From: Naiming Shen <[email-masked]>
Date: Sat, 20 Mar 2004 23:15:31 -0800

Christian,

thanks for the good comments, in replies inline.

<cut...>

 ] >
 ] >    rtrA -- rtrB -- rtrC
 ] >             |       |
 ] >            rtrD -- rtrE
 ] >
 ] >
 ] >    Assume all links have the same cost. Assume a TE-tunnel is set up
 ] >    from rtrA to rtrD. When the SPF calculation puts rtrC on the
 ] >    TENTative list, it will realize that rtrC is not directly  ] connected,
 ] >    and thus it will use the first-hop information from the parent. 
 ] > Which
 ] >    is rtrB.  When the SPF calculation on rtrA puts rtrD on the 
 ] > TENTative
 ] >    list, it realizes that rtrD is the tail-end of a TE-tunnel. Thus 
 ] > rtrA
 ] >    will install a route to rtrD via the TE-tunnel, and not via rtrB.
 ] 
 ] This incorrectly indicates "puts rtrD on the TENTative list..." If a TE  ] 
 ] nexthop will replace existing nexthops for rtrD it will be done when 
 ] rtrD is placed in PATHS.

You are correct. This one should have meant
 "takes rtrD off the TENTative list...".

<cut...>

 ] >
 ] >    This mechanism is loop free since the TE-tunnels are source-routed.
 ] >    The end result of TE-tunnel metric adjustment is more control over
 ] >    traffic loadsharing. If there is only one way to reach a particular
 ] >    IP prefix through a single TE-tunnel, then no matter what metric is
 ] >    assigned, the traffic has only one path to go.
 ] 
 ] The mechanism is loop free b/c the source routed tunnels are only 
 ] utilized after a node is placed in PATHS. This is critical, and I think  ] 
 should be stated. Simply shoving a packet down a source routed tunnel 
 ] doesn't guarantee that it won't loop back. The fact that the tunnel was  ] 
 ] chosen only after SPF guaranteed the tunnel endpoint was truly 
 ] downstream towards the destination is what makes it loop free.

True, your reasoning is stronger, will add that.

 ] 
 ] >    When the manual TE-tunnel metric is configured to be larger than
 ] >    the IGP native path metric, this TE-tunnel can not be used in the
 ] >    SPF calculation. Otherwise a routing loop may be formed. Here is
 ] >    an example:
 ] 
 ] Note stating "this TE-tunnel can not be used in the SPF calculation" is  ] 
 ] confusing, as its critical that TE-tunnels *not* be used in the SPF 
 ] calculation.

I'm not sure why this is confusing. It simply says the there may be
a problem using such a tunnel with such a metric. We don't want to
say that if certain conditions don't exist, then it's ok to use those
tunnels.

 ] 
 ] This is stated earlier in this section:
 ] 
 ] "Setting a manual metric on a TE-tunnel does not impact the SPF 
 ] algorithm itself."
 ] 
 ] The only thing the TE tunnel metric can affect is whether TE tunnel 
 ] nexthop is chosen over the IGP nexthop when a route is being installed,  ] 
 ] and when *IGP metric* based ECMP routes are being considered.
 ]

<cut...>
 
 ] >
 ] > 6.1. Absolute and relative metrics
 ] >
 ] >    It is possible to represent the TE-tunnel metric in two different
 ] >    ways: an absolute (or fixed) metric or a relative metric, which is
 ] >    merely an adjustment of the dynamic IGP metric as calculate by the
 ] >    SPF computation.  When using an absolute metric on a TE-tunnel, the
 ] >    cost of the IP routes in the routing table does not depend on the
 ] >    topology of the network. Note that this fixed metric is not only 
 ] > used
 ] >    to compute the cost of IP routes advertised by the router that is  ] 
 ] > the
 ] >    tail-end of the TE-tunnel, but also for all the routes that are
 ] >    downstream of this tail-end router.  For example, if we have TE-
 ] >    tunnels to two core routers in a remote POP, and one of them is
 ] >    assigned with absolute metric of 1, then all the traffic going to
 ] >    that POP will traverse this low-metric TE-tunnel.
 ] >
 ] >    By setting a relative metric, the cost of IP routes in the routing
 ] >    table is based on the IGP metric as calculated by the SPF
 ] >    computation.  This relative metric can be a positive or a negative
 ] >    number.  Not configuring a metric on a TE-tunnel is a special case  ] 
 ] > of
 ] >    the relative metric scheme. No metric is the same as a relative
 ] >    metric of 0.  The relative metric is bounded by minimum and maximum
 ] >    allowed metric values while the positive metric disables the
 ] >    TE-tunnel in the SPF calculation.
 ] 
 ] I've always thought that positive relative metrics are silly. Do we 
 ] really need this method for disabling use of the tunnel in the IGP?
 ] 

I don't have strong opinions either way. This is mainly for completeness.
Some implementations do have mechanism to assign positive metric. It's
mainly an implementation issue to allow it or not. But from documentation
point of view, it helps to explicitly mentioning this.

thanks.

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

- Naiming

---

From: Christian Hopps <[email-masked]>
Date: Mon, 22 Mar 2004 13:50:50 -0800

On Mar 20, 2004, at 11:15 PM, Naiming Shen wrote:
>  ] Note stating "this TE-tunnel can not be used in the SPF 
> calculation" is=20=
>  ]
>  ] confusing, as its critical that TE-tunnels *not* be used in the 
> SPF=20
>  ] calculation.
>

I'm only concerned that the above text is indicating that one uses the 
TE metric rather than the IGP metric in the SPF algorithm specifically 
I'm focussed on the phrase "SPF calculation" above.

Note the example that follows in the text. Regardless of whether the TE 
tunnel metric is more or less it MUST not affect the path choice, the 
example and the text above seem to imply that it can.

Which again, is why the following is stated earlier in the document.

>  ] "Setting a manual metric on a TE-tunnel does not impact the SPF=20
>  ] algorithm itself."
>  ]
>  ] The only thing the TE tunnel metric can affect is whether TE 
> tunnel=20
>  ] nexthop is chosen over the IGP nexthop when a route is being 
> installed,=20=
>  ]

Chris.

---

From: Naiming Shen <[email-masked]>
Date: Thu, 25 Mar 2004 18:46:28 -0800

] 
 ] On Mar 20, 2004, at 11:15 PM, Naiming Shen wrote:
 ] >  ] >    When the manual TE-tunnel metric is configured to be larger 
 ] > than
 ] >  ] >    the IGP native path metric, this TE-tunnel can not be used in 
 ] > the
 ] >  ] >    SPF calculation. Otherwise a routing loop may be formed. Here 
 ] > is
 ] >  ] >    an example:
 ] >  ]
 ] >  ] Note stating "this TE-tunnel can not be used in the SPF 
 ] > calculation" is=20=
 ] >  ]
 ] >  ] confusing, as its critical that TE-tunnels *not* be used in the 
 ] > SPF=20
 ] >  ] calculation.
 ] >
 ] > I'm not sure why this is confusing. It simply says the there may be
 ] > a problem using such a tunnel with such a metric. We don't want to
 ] > say that if certain conditions don't exist, then it's ok to use those
 ] > tunnels.
 ] 
 ] I'm only concerned that the above text is indicating that one uses the 
 ] TE metric rather than the IGP metric in the SPF algorithm specifically 
 ] I'm focussed on the phrase "SPF calculation" above.
 ] 
 ] Note the example that follows in the text. Regardless of whether the TE 
 ] tunnel metric is more or less it MUST not affect the path choice, the 
 ] example and the text above seem to imply that it can.

I think my example in the draft was not good. By (dst), which I meant
some prefix/subnet. There are posibility that multiple nodes inject
the same subnet. Even though the shortcut does not change the SPF,
it does change the metric assigned into routes, and the lower ones
will win, which can cause a loop. something like the following diagram:

      (src)  2         2
        A ------ B ------- C
        |        =========>|
      20|            30    |2
        |                  |
        D                  E (dst X)
       (dst X)

does this diagram change make sense?

thanks.

 ] 
 ] Which again, is why the following is stated earlier in the document.
 ] 
 ] >  ] This is stated earlier in this section:
 ] >  ]
 ] >  ] "Setting a manual metric on a TE-tunnel does not impact the SPF=20
 ] >  ] algorithm itself."
 ] >  ]
 ] >  ] The only thing the TE tunnel metric can affect is whether TE 
 ] > tunnel=20
 ] >  ] nexthop is chosen over the IGP nexthop when a route is being 
 ] > installed,=20=
 ] >  ]
 ] >  ] and when *IGP metric* based ECMP routes are being considered.
 ] 
 ] Chris.
 ] 
 ] > - Naiming
 ] >
 ] > _______________________________________________
 ] > Rtgwg mailing list
 ] > [email-masked]
 ] > https://www1.ietf.org/mailman/listinfo/rtgwg
 ] 
 ] 
 ] _______________________________________________
 ] Rtgwg mailing list
 ] [email-masked]
 ] https://www1.ietf.org/mailman/listinfo/rtgwg

- Naiming

---

From: Christian Hopps <[email-masked]>
Date: Thu, 25 Mar 2004 19:19:09 -0800

> will win, which can cause a loop. something like the following diagram:

There is no possibility of a loop here. B will choose C for E because 
of the SPF, the TE metric plays no part in the SPF at all. That is, B 
will choose C, E will go into TENT, B will then choose E through C by 
putting E in PATHS next. The draft can say that B uses the IGP because 
its metric to dst x is 4 and the TE metric is 32, but talking about it 
in the context of the SPF is misleading.

More to the point, a vendor could actually have an option "always 
prefer TE tunnels to IGP" and B could then use the metric 30 tunnel, 
there would *still* be no loop.

The draft should clearly state that the TE metric only arbitrates for 
nexthop selection once the best routes have been discovered. In the 
above example why would A even be looking at D as a route for dst x?

Thanks,
Chris.

---

From: Naiming Shen <[email-masked]>
Date: Thu, 25 Mar 2004 20:10:55 -0800

] 
 ] On Mar 25, 2004, at 6:46 PM, Naiming Shen wrote:
 ] >  ] Note the example that follows in the text. Regardless of whether 
 ] > the TE
 ] >  ] tunnel metric is more or less it MUST not affect the path choice, 
 ] > the
 ] >  ] example and the text above seem to imply that it can.
 ] >
 ] > I think my example in the draft was not good. By (dst), which I meant
 ] > some prefix/subnet. There are posibility that multiple nodes inject
 ] > the same subnet. Even though the shortcut does not change the SPF,
 ] > it does change the metric assigned into routes, and the lower ones
 ] > will win, which can cause a loop. something like the following diagram:
 ] >
 ] >       (src)  2         2
 ] >         A ------ B ------- C
 ] >         |        =========>|
 ] >       20|            30    |2
 ] >         |                  |
 ] >         D                  E (dst X)
 ] >        (dst X)
 ] >
 ] > does this diagram change make sense?
 ] 
 ] There is no possibility of a loop here. B will choose C for E because 
 ] of the SPF, the TE metric plays no part in the SPF at all. That is, B 
 ] will choose C, E will go into TENT, B will then choose E through C by 
 ] putting E in PATHS next. The draft can say that B uses the IGP because 
 ] its metric to dst x is 4 and the TE metric is 32, but talking about it 
 ] in the context of the SPF is misleading.
 ] 
 ] More to the point, a vendor could actually have an option "always 
 ] prefer TE tunnels to IGP" and B could then use the metric 30 tunnel, 
 ] there would *still* be no loop.
 ] 
 ] The draft should clearly state that the TE metric only arbitrates for 
 ] nexthop selection once the best routes have been discovered. In the 
 ] above example why would A even be looking at D as a route for dst x?
                          ^^^

I think you meant B above.
Here is why regardless of lsp tunnels:

         10           20
    a ------------> b -- Y
    |
    +-------------> c -- Y
         15           5

assume node 'a' is the source of the SPF, it has metric 10 to reach
node 'b' and metric 15 to reach node 'c'. node 'b' announce routes Y
with metric of 20, and node 'c' announces route Y with metric of 5.
are you saying from node 'a' to destination of Y, it should take
node 'b' instead of node 'c' ?

thanks.

 ] 
 ] Thanks,
 ] Chris.
 ] 
 ] 
 ] > thanks.
 ] >
 ] >  ]
 ] >  ] Which again, is why the following is stated earlier in the document.
 ] >  ]
 ] >  ] >  ] This is stated earlier in this section:
 ] >  ] >  ]
 ] >  ] >  ] "Setting a manual metric on a TE-tunnel does not impact the 
 ] > SPF=20
 ] >  ] >  ] algorithm itself."
 ] >  ] >  ]
 ] >  ] >  ] The only thing the TE tunnel metric can affect is whether TE
 ] >  ] > tunnel=20
 ] >  ] >  ] nexthop is chosen over the IGP nexthop when a route is being
 ] >  ] > installed,=20=
 ] >  ] >  ]
 ] >  ] >  ] and when *IGP metric* based ECMP routes are being considered.
 ] >  ]
 ] >  ] Chris.
 ] >  ]
 ] >  ] > - Naiming
 ] >  ] >
 ] >  ] > _______________________________________________
 ] >  ] > Rtgwg mailing list
 ] >  ] > [email-masked]
 ] >  ] > https://www1.ietf.org/mailman/listinfo/rtgwg
 ] >  ]
 ] >  ]
 ] >  ] _______________________________________________
 ] >  ] Rtgwg mailing list
 ] >  ] [email-masked]
 ] >  ] https://www1.ietf.org/mailman/listinfo/rtgwg
 ] >
 ] > - Naiming
 ] 
 ] 
 ] _______________________________________________
 ] Rtgwg mailing list
 ] [email-masked]
 ] https://www1.ietf.org/mailman/listinfo/rtgwg

- Naiming

---

From: Christian Hopps <[email-masked]>
Date: Thu, 25 Mar 2004 20:20:17 -0800

>  ] > will win, which can cause a loop. something like the following 

Absolutely not. The cost to Y through b by SPF is 30. The cost to Y 
through c is 20. Clearly c is the only nexthop A should (MUST) use to 
Y. I'm saying TE metric has nothing to do with choosing the set of best 
cost paths to Y. When that set is chosen, and only when, you can do 
whatever you want in selecting which ones you want to use, including 
the use of the TE metric; however, TE MUST not play any part in 
selecting the initial set of best cost paths.

Chris.

---

From: Naiming Shen <[email-masked]>
Date: Thu, 25 Mar 2004 20:55:57 -0800

] 
 ] On Mar 25, 2004, at 8:10 PM, Naiming Shen wrote:
 ] >  ] On Mar 25, 2004, at 6:46 PM, Naiming Shen wrote:
 ] >  ] >  ] Note the example that follows in the text. Regardless of 
 ] > whether
 ] >  ] > the TE
 ] >  ] >  ] tunnel metric is more or less it MUST not affect the path 
 ] > choice,
 ] >  ] > the
 ] >  ] >  ] example and the text above seem to imply that it can.
 ] >  ] >
 ] >  ] > I think my example in the draft was not good. By (dst), which I 
 ] > meant
 ] >  ] > some prefix/subnet. There are posibility that multiple nodes 
 ] > inject
 ] >  ] > the same subnet. Even though the shortcut does not change the SPF,
 ] >  ] > it does change the metric assigned into routes, and the lower ones
 ] >  ] > will win, which can cause a loop. something like the following 
 ] > diagram:
 ] >  ] >
 ] >  ] >       (src)  2         2
 ] >  ] >         A ------ B ------- C
 ] >  ] >         |        =========>|
 ] >  ] >       20|            30    |2
 ] >  ] >         |                  |
 ] >  ] >         D                  E (dst X)
 ] >  ] >        (dst X)
 ] >  ] >
 ] >  ] > does this diagram change make sense?
 ] >  ]
 ] >  ] There is no possibility of a loop here. B will choose C for E 
 ] > because
 ] >  ] of the SPF, the TE metric plays no part in the SPF at all. That is, 
 ] > B
 ] >  ] will choose C, E will go into TENT, B will then choose E through C 
 ] > by
 ] >  ] putting E in PATHS next. The draft can say that B uses the IGP 
 ] > because
 ] >  ] its metric to dst x is 4 and the TE metric is 32, but talking about 
 ] > it
 ] >  ] in the context of the SPF is misleading.
 ] >  ]
 ] >  ] More to the point, a vendor could actually have an option "always
 ] >  ] prefer TE tunnels to IGP" and B could then use the metric 30 tunnel,
 ] >  ] there would *still* be no loop.
 ] >  ]
 ] >  ] The draft should clearly state that the TE metric only arbitrates 
 ] > for
 ] >  ] nexthop selection once the best routes have been discovered. In the
 ] >  ] above example why would A even be looking at D as a route for dst x?
 ] >                           ^^^
 ] >
 ] > I think you meant B above.
 ] > Here is why regardless of lsp tunnels:
 ] >
 ] >          10           20
 ] >     a ------------> b -- Y
 ] >     |
 ] >     +-------------> c -- Y
 ] >          15           5
 ] >
 ] > assume node 'a' is the source of the SPF, it has metric 10 to reach
 ] > node 'b' and metric 15 to reach node 'c'. node 'b' announce routes Y
 ] > with metric of 20, and node 'c' announces route Y with metric of 5.
 ] > are you saying from node 'a' to destination of Y, it should take
 ] > node 'b' instead of node 'c' ?
 ] 
 ] Absolutely not. The cost to Y through b by SPF is 30. The cost to Y 
 ] through c is 20. Clearly c is the only nexthop A should (MUST) use to 
 ] Y. I'm saying TE metric has nothing to do with choosing the set of best 
 ] cost paths to Y. When that set is chosen, and only when, you can do 
 ] whatever you want in selecting which ones you want to use, including 
 ] the use of the TE metric; however, TE MUST not play any part in 
 ] selecting the initial set of best cost paths.
 ] 

we are not talking about changing the paths to the spf nodes. we are
only discussing how to determine the paths to reach the prefixes with
TE tunnel being used. unless as you suggested, an implementation 
have an 'always use TE tunnel' for the routes, there is certainly
the possibility of routing loop if higher than 'normal' metric being
used for the routes. again, this is also implementation issues, one
can store the TE tunnel metric along with the hop-by-hop metric; later
when one comes to another nodes announcing the same route, only
compare with the hop-by-hop metric.

since the route preference duing calculation is part of the spf
implementation, I would think we need to mention this possibility
of looping issues.

thanks.

 ] Chris.
 ] 
 ] >
 ] > thanks.
 ] >
 ] >  ]
 ] >  ] Thanks,
 ] >  ] Chris.
 ] >  ]
 ] >  ]
 ] >  ] > thanks.
 ] >  ] >
 ] >  ] >  ]
 ] >  ] >  ] Which again, is why the following is stated earlier in the 
 ] > document.
 ] >  ] >  ]
 ] >  ] >  ] >  ] This is stated earlier in this section:
 ] >  ] >  ] >  ]
 ] >  ] >  ] >  ] "Setting a manual metric on a TE-tunnel does not impact 
 ] > the
 ] >  ] > SPF=20
 ] >  ] >  ] >  ] algorithm itself."
 ] >  ] >  ] >  ]
 ] >  ] >  ] >  ] The only thing the TE tunnel metric can affect is whether 
 ] > TE
 ] >  ] >  ] > tunnel=20
 ] >  ] >  ] >  ] nexthop is chosen over the IGP nexthop when a route is 
 ] > being
 ] >  ] >  ] > installed,=20=
 ] >  ] >  ] >  ]
 ] >  ] >  ] >  ] and when *IGP metric* based ECMP routes are being 
 ] > considered.
 ] >  ] >  ]
 ] >  ] >  ] Chris.
 ] >  ] >  ]
 ] >  ] >  ] > - Naiming
 ] >  ] >  ] >
 ] >  ] >  ] > _______________________________________________
 ] >  ] >  ] > Rtgwg mailing list
 ] >  ] >  ] > [email-masked]
 ] >  ] >  ] > https://www1.ietf.org/mailman/listinfo/rtgwg
 ] >  ] >  ]
 ] >  ] >  ]
 ] >  ] >  ] _______________________________________________
 ] >  ] >  ] Rtgwg mailing list
 ] >  ] >  ] [email-masked]
 ] >  ] >  ] https://www1.ietf.org/mailman/listinfo/rtgwg
 ] >  ] >
 ] >  ] > - Naiming
 ] >  ]
 ] >  ]
 ] >  ] _______________________________________________
 ] >  ] Rtgwg mailing list
 ] >  ] [email-masked]
 ] >  ] https://www1.ietf.org/mailman/listinfo/rtgwg
 ] >
 ] > - Naiming
 ] 
 ] 
 ] _______________________________________________
 ] Rtgwg mailing list
 ] [email-masked]
 ] https://www1.ietf.org/mailman/listinfo/rtgwg

- Naiming