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

From: Christian Hopps <[email-masked]>
Date: Thu, 1 Apr 2004 09:19:21 -0800

On Mar 25, 2004, at 8:55 PM, Naiming Shen wrote:
>  ] 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.

We should not be talking about implementation issues here. I'm not sure 
where the confusion is on this point anymore.

The algorithm is very simple. For each prefix there is a set of ECMP 
paths to reach said prefix. This set of paths is determined by IGP 
metric only. From this set of paths the TE metric may be used used to 
select a subset of paths to install in the RIB.

Again the point is that under no circumstances may the TE metric be 
used to select the initial set of ECMP paths. It doesn't matter if the 
TE metric is lower equal or greater. I feel that the draft currently 
gives examples that seem to imply that one may be using the TE metric 
to choose this set of initial ECMP paths.

Thanks,
Chris.

> 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

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

---

From: Naiming Shen <[email-masked]>
Date: Thu, 01 Apr 2004 09:26:44 -0800

I'll update the example. thanks.

 ] On Mar 25, 2004, at 8:55 PM, Naiming Shen wrote:
 ] >  ] 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.
 ] 
 ] We should not be talking about implementation issues here. I'm not sure 
 ] where the confusion is on this point anymore.
 ] 
 ] The algorithm is very simple. For each prefix there is a set of ECMP 
 ] paths to reach said prefix. This set of paths is determined by IGP 
 ] metric only. From this set of paths the TE metric may be used used to 
 ] select a subset of paths to install in the RIB.
 ] 
 ] Again the point is that under no circumstances may the TE metric be 
 ] used to select the initial set of ECMP paths. It doesn't matter if the 
 ] TE metric is lower equal or greater. I feel that the draft currently 
 ] gives examples that seem to imply that one may be using the TE metric 
 ] to choose this set of initial ECMP paths.
 ] 
 ] Thanks,
 ] Chris.
 ] 
 ] 
 ] 
 ] > 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
 ] 

- Naiming