Subject: Re: WG Last Call: draft-ietf-rtgwg-igp-shortcut-00.txt

From: Alex Zinin <[email-masked]>
Date: Tue, 4 May 2004 17:19:23 -0700

This concludes the WG Last Call.

A few comments on the document from me:

 1. Security considerations section is weak. It needs to at least point the
    reader to the relevant protocol specifications.

 2. None of the references is actually used in the document.

We only received comments from Joel during the Last Call and he agreed to try
and come up with a more elaborate version by the end of this week.

-- 
Alex
http://www.psg.com/~zinin/

Monday, April 19, 2004, 4:19:35 PM, Alex Zinin wrote:
> Folks-

>  This is to start a 2-week WG Last Call for draft-ietf-rtgwg-igp-shortcut-00.txt.
>  The document target status is Informational. The Last Call ends on May 3rd, 2004.
>  Please send your comments to [email-masked].

>  The document is available from the WG web-page or at the following URL:

>    http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-igp-shortcut-00.txt

>  The Abstract from the document is included 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.

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

---

From: Alex Zinin <[email-masked]>
Date: Wed, 5 May 2004 09:05:40 -0700

Tuesday, May 4, 2004, 5:19:23 PM, Alex Zinin wrote:
[...]
>  2. None of the references is actually used in the document.

Please ignore this comment. The doc does use the refs.

Alex

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 06 May 2004 18:01:49 -0400

This note is an effort to provide clear explanation of what changes I think 
are needed to make this document an acceptable information RFC.  I will 
assign numbers in what follows to the specific issues I feel need to be 
addressed.  I can not provide full replacement text, but I believe I can 
provide reasonably clear guidance as to what the problem is.

First, except for a small aspect of clarity, the technical material in 
sections 4 and onward appears sound to me.  It describes a valid way to 
select useful shortcuts, and a valid set of behaviors to use with those.

1) The references to routing tables and metrics could use some 
clarification.  I finally concluded that the routing table being referred 
to was an intermediate conceptual structure between the per-protocol RIBs 
and the actual FIB.  And I concluded that the metrics being referred to 
were internal implementation specific metrics used for selecting routes 
from the conceptual RIB for the FIB.  This is indeed a useful way to look 
at things.  Specifically, at the beginning of section 6, it would help if 
there were additional text describing what "routing table" and what 
"metric" are meant in the ensuing discussion.

I am much more concerned by the early portions of text that attempt to 
describe the applicability of this document.  One can argue that the 
abstract and introduction do not matter much, since they are just stage 
setting.  However, for an informational document such as this, the stage 
setting and applicability are critical.  It is necessary to tell the reader 
when the document may be of use.  Incorrect assertions about what is 
necessary for interoperability, or about the relationship to other RFCs is 
not acceptable.

2) With regard to the Abstract (section 2) the document states that the 
document describes how the SPF should be adapted so that link-state IGPs 
will calculate IP routes to forward traffic over tunnels that are set up by 
Traffic Engineering.  I have two concerns with this.
2a) "should" is an inappropriate term to use in a document like 
this.  "can" or "may" are entirely reasonable.  The particular algorithm 
recommended in this document works, but it is not the only mechanism that 
can be used to enable IGP forwarding over tunnels.
2b) The relationship between this work and Traffic Engineering needs a lot 
more explanation.  This is one of the key reasons I can not provide 
text.  Reading teh Traffic Engineering Applicability RFC, I see that the TE 
group explicitly says that TE tunnels are for use instead of shortest path 
routes.  I see that they talk about affinities, and about selecting traffic 
to make use of specific tunnels.  The algorithms defined in this shortcut 
document, while they will send some traffic over tunnels, do not as 
described meet the applicability of the TE document.  I do assume that 
there is actually an underlying consistency that can be found, but without 
text I do not know what it is.

I believe that the last paragraph of the introduction (section 4) 
mis-describes the constraints that must be met, and the reasons that TE 
tunnels can be used in conjunction with the algorithm given, or in fact in 
conjunction with a range of other algorithms.  I would propose that the 
last paragraph be reword along the following lines.

3) This document describes a mechanism by which Link-state IGPs can make 
use of these shortcuts, and how tehy can install routes in the internal 
routing table (and then in the forwarding tables) that point out over these 
TE-tunnels.  The tunnels under consideration are tunnels created explicitly 
by the node performing the calculation, and with an end-point known to this 
node.  For use in algorithms such as the one described here, it does not 
matter whether the tunnel itself is strictly routed, or if only the head 
and tail end-points of the tunnel are known.  It is important that the 
mechanisms used by routers to choose to inject packets into tunnels are 
such that different routers, with potentially different algorithms, do not 
induce packet loops in the non-tunneled network.  (While it may be 
sub-optimal, it is not a failure of routing if a packet crosses the same 
link once in a tunnel and once un-encapsulated.)  A simple constraint can 
ensure that when a router chooses to inject a packet into a tunnel it is 
not risking inducing an unacceptable loop.  For a packet addressed to a 
destination D, a router may inject the packet into to a tunnel for which 
the router is the head end iff the tunnel end-point is closer, according to 
the IGP metric, to the destination D than the injecting router is.  The 
algorithms that follow are one way that a router may obey this rule and 
make intelligent choices about when to use TE tunnels for traffic.  This 
algorithm may be used in conjunction with other mechanisms such as affinity 
based tunnel selection.

Yours,
Joel M. Halpern

>At 04:19 PM 4/19/2004 -0700, Alex Zinin wrote:
>>Folks-
>>
>>Alex Zinin

---

From: Naiming Shen <[email-masked]>
Date: Thu, 06 May 2004 18:35:09 -0700

Joel,

thanks so much for the detailed comments. will try to incorporate them
into the draft.

Regards.

 ] This note is an effort to provide clear explanation of what changes I think 
 ] are needed to make this document an acceptable information RFC.  I will 
 ] assign numbers in what follows to the specific issues I feel need to be 
 ] addressed.  I can not provide full replacement text, but I believe I can 
 ] provide reasonably clear guidance as to what the problem is.
 ] 
 ] 
 ] First, except for a small aspect of clarity, the technical material in 
 ] sections 4 and onward appears sound to me.  It describes a valid way to 
 ] select useful shortcuts, and a valid set of behaviors to use with those.
 ] 
 ] 1) The references to routing tables and metrics could use some 
 ] clarification.  I finally concluded that the routing table being referred 
 ] to was an intermediate conceptual structure between the per-protocol RIBs 
 ] and the actual FIB.  And I concluded that the metrics being referred to 
 ] were internal implementation specific metrics used for selecting routes 
 ] from the conceptual RIB for the FIB.  This is indeed a useful way to look 
 ] at things.  Specifically, at the beginning of section 6, it would help if 
 ] there were additional text describing what "routing table" and what 
 ] "metric" are meant in the ensuing discussion.
 ] 
 ] 
 ] I am much more concerned by the early portions of text that attempt to 
 ] describe the applicability of this document.  One can argue that the 
 ] abstract and introduction do not matter much, since they are just stage 
 ] setting.  However, for an informational document such as this, the stage 
 ] setting and applicability are critical.  It is necessary to tell the reader 
 ] when the document may be of use.  Incorrect assertions about what is 
 ] necessary for interoperability, or about the relationship to other RFCs is 
 ] not acceptable.
 ] 
 ] 2) With regard to the Abstract (section 2) the document states that the 
 ] document describes how the SPF should be adapted so that link-state IGPs 
 ] will calculate IP routes to forward traffic over tunnels that are set up by 
 ] Traffic Engineering.  I have two concerns with this.
 ] 2a) "should" is an inappropriate term to use in a document like 
 ] this.  "can" or "may" are entirely reasonable.  The particular algorithm 
 ] recommended in this document works, but it is not the only mechanism that 
 ] can be used to enable IGP forwarding over tunnels.
 ] 2b) The relationship between this work and Traffic Engineering needs a lot 
 ] more explanation.  This is one of the key reasons I can not provide 
 ] text.  Reading teh Traffic Engineering Applicability RFC, I see that the TE 
 ] group explicitly says that TE tunnels are for use instead of shortest path 
 ] routes.  I see that they talk about affinities, and about selecting traffic 
 ] to make use of specific tunnels.  The algorithms defined in this shortcut 
 ] document, while they will send some traffic over tunnels, do not as 
 ] described meet the applicability of the TE document.  I do assume that 
 ] there is actually an underlying consistency that can be found, but without 
 ] text I do not know what it is.
 ] 
 ] I believe that the last paragraph of the introduction (section 4) 
 ] mis-describes the constraints that must be met, and the reasons that TE 
 ] tunnels can be used in conjunction with the algorithm given, or in fact in 
 ] conjunction with a range of other algorithms.  I would propose that the 
 ] last paragraph be reword along the following lines.
 ] 
 ] 3) This document describes a mechanism by which Link-state IGPs can make 
 ] use of these shortcuts, and how tehy can install routes in the internal 
 ] routing table (and then in the forwarding tables) that point out over these 
 ] TE-tunnels.  The tunnels under consideration are tunnels created explicitly 
 ] by the node performing the calculation, and with an end-point known to this 
 ] node.  For use in algorithms such as the one described here, it does not 
 ] matter whether the tunnel itself is strictly routed, or if only the head 
 ] and tail end-points of the tunnel are known.  It is important that the 
 ] mechanisms used by routers to choose to inject packets into tunnels are 
 ] such that different routers, with potentially different algorithms, do not 
 ] induce packet loops in the non-tunneled network.  (While it may be 
 ] sub-optimal, it is not a failure of routing if a packet crosses the same 
 ] link once in a tunnel and once un-encapsulated.)  A simple constraint can 
 ] ensure that when a router chooses to inject a packet into a tunnel it is 
 ] not risking inducing an unacceptable loop.  For a packet addressed to a 
 ] destination D, a router may inject the packet into to a tunnel for which 
 ] the router is the head end iff the tunnel end-point is closer, according to 
 ] the IGP metric, to the destination D than the injecting router is.  The 
 ] algorithms that follow are one way that a router may obey this rule and 
 ] make intelligent choices about when to use TE tunnels for traffic.  This 
 ] algorithm may be used in conjunction with other mechanisms such as affinity 
 ] based tunnel selection.
 ] 
 ] 
 ] Yours,
 ] Joel M. Halpern
 ] 
 ] 
 ] >At 04:19 PM 4/19/2004 -0700, Alex Zinin wrote:
 ] >>Folks-
 ] >>
 ] >>  This is to start a 2-week WG Last Call for 
 ] >> draft-ietf-rtgwg-igp-shortcut-00.txt.
 ] >>  The document target status is Informational. The Last Call ends on May 
 ] >> 3rd, 2004.
 ] >>  Please send your comments to [email-masked].
 ] >>
 ] >>  The document is available from the WG web-page or at the following URL:
 ] >>
 ] >>    http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-igp-shortcut-00.t
xt
 ] >>
 ] >>  The Abstract from the document is included 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.
 ] >>
 ] >>--
 ] >>Alex Zinin
 ] >>
 ] >>
 ] >>_______________________________________________
 ] >>Rtgwg mailing list
 ] >>[email-masked]
 ] >>https://www1.ietf.org/mailman/listinfo/rtgwg
 ] >
 ] >
 ] >_______________________________________________
 ] >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: Alex Zinin <[email-masked]>
Date: Sun, 9 May 2004 11:53:59 -0700

Naiming,

 How much time do you need to revise the doc?

 Regards.

---

From: Naiming Shen <[email-masked]>
Date: Sun, 09 May 2004 22:55:52 -0700

Hi Alex,

 ] Naiming,
 ] 
 ]  How much time do you need to revise the doc?
 ] 

I'm on a trip next week, will try to address this in the following
week. So will be around two weeks time and hope that's cool.

thanks.

 ]  Regards.
 ] 
 ] -- 
 ] Alex
 ] http://www.psg.com/~zinin/
 ] 
 ] Thursday, May 6, 2004, 6:35:09 PM, Naiming Shen wrote:
 ] 
 ] > Joel,
 ] 
 ] > thanks so much for the detailed comments. will try to incorporate them
 ] > into the draft.
 ] 
 ] > Regards.
 ] 
 ] 
 ] 

- Naiming

---

From: Alex Zinin <[email-masked]>
Date: Sun, 9 May 2004 23:05:51 -0700

Thanks a lot, Naiming!