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

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

HI,
Just resending (earlier "send" used an incorrect alias for the Intarea WG).
Cheers
Francois

On 20 Sep 2010, at 16:36, Francois Le Faucheur wrote:

> 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
> 
> <logo.gif>
> 
> Francois Le Faucheur
> Distinguished Engineer
> Corporate Development
> [e-mail]
> Phone: [phone]
> Mobile: [phone]
> 
> 
> 
> Cisco Systems France
> Greenside
> 400 Ave de Roumanille
> 06410 Sophia Antipolis
> France
> Cisco.com
> 
> 
> 
> <green.gif>
> Think before you print.
> 
> This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
> 
> Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.
> 
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> 



Francois Le Faucheur
Distinguished Engineer
Corporate Development
[e-mail]
Phone: [phone]
Mobile: [phone]



Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com


 

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html