Re: [Int-area] Your availability for a pre-WGLC document review

[Francois Le Faucheur <[e-mail]>]

Hi Fred,

Thanks much for the review. Some thoughts (& historical background on the I-D) embedded: 

On 14 Sep 2010, at 08:02, Fred Baker wrote:

> 
> On Sep 12, 2010, at 1:20 AM, Christian Vogt wrote:
> 
>> Fred, Joel, and Suresh:
>> 
>> The Intarea working group has a deliverable, draft-ietf-intarea-router-alert-considerations [1], which we believe is near-ready for working group last call.  However, before initiating the last call, we would like to get some experts to review the document.  Would you be able to provide such a review?  
>> 
>> Many thanks in advance!  Please send your comments to the Intarea working group mailing list.
>> 
>> - Christian
>> 
>> 
>> [1] http://tools.ietf.org/html/draft-ietf-intarea-router-alert-considerations
>> 
> 
> 
> I believe that the document is close to being ready for WGLC, but I have one suggested edit and one thought that the working group can deal with according to its taste.
> 
> I think the BGP discussion in the document is extraneous to the primary topic, which is a certain option. Joel's comments, while on target for the BGP discussion, are extraneous to anything related to that option. This suggests to me that the BGP discussion should be removed - it is an interesting comparison and contrast, but to the extent that it draws attention away from the option it fails the document's primary purpose.

As indicated in response to Joel, my personal preference would be to refine the statements as needed and keep this analysis/comparison in.  We're almost there in terms of refining the statements to make them accurate and I do see a lot of value in this comparison: "why is OK to open up a control plane hole for BGP and not for Router Alert?" is a question that everyone asks or should be asking; so may as well help answer it.

But, this is just my take. It would be good to get more opinions.   

> 
> Regarding the option, it does serve a very real purpose, which is to enable network devices on a unicast or multicast path through the network that may or may not have every router en route configured to use a certain protocol let that protocol inspect and modify the datagrams. The original case was RSVP, whose PATH message is directed from source to destination and needs to be inspected and updated by the RSVP processes en route. It has also been picked up by other control plane protocols such as IGMP. The issues were and I believe still are that 
> (a) not every interface on the path will have the protocol enabled, which means that it is insufficient for control plane processes to simply emulate the routing of datagrams - the next hop router will in many cases not be in a position to process the message;
> (b) those interfaces on the path that need to process the message cannot simply flip a few bits and pass it along - there is more processing required, and in many cases the next message is in fact generated by the process in question, not simply forwarded.
> 
> I will quibble a point; while the original implementation of the router alert was to punt the packet to a central processor, the real point is to punt the packet to a place that can do control plane processing. One could imagine that being on the line card or somewhere else. 

In an earlier version (draft-rahman-rtg-router-alert-considerations-01), the document explored exactly these sort of thoughts and included specific suggestions/recommendations about how to implement Router-Alert. This was discussed and the conclusion of the RTG Working Group was that, while interesting, those erred on the "implementation specific" side and did not belong in this document and instead should be replaced by more generic recommendations.

> 
> In any event, it would be useful to have in the document recommended requirements for a replacement technology. The document says what about the mechanism is doesn't like (and argues the case effectively); it should also state what characteristics an acceptable replacement technology should have. Simplistic statements that force the protocol in question to fail one or both of the points above will be of little real value.

In an earlier version (draft-rahman-tg-router-alert-considerations-00), the document explored potential alternative/replacement technology. This was discussed and the conclusion from the RTG Working Group was to separate discussion on current situation versus discussion on alternatives (in part because it was urgent/feasible to close on description of current situation, while it was less-urgent/far-from-clear-that-we-could-reach-any-concensus on whether/what should/may be done in the future).
The material we had regarding "acceptable replacement technology" was moved out into a standalone I-D: draft-narayanan-rtg-router-alert-extensions-00.


Cheers

Francois