Re: [Gen-art] Gen-ART Last Call review of draft-ietf-mpls-oam-ipv6-rao-02

["Carlos Pignataro (cpignata)" <[e-mail]>]

Thank you.


> On Jan 26, 2015, at 5:05 PM, Brian E Carpenter <[e-mail]> wrote:
> 
> Looks good to me, thanks.
> 
>   Brian
> 
> On 27/01/2015 09:36, Carlos Pignataro (cpignata) wrote:
>> Hi, Brian,
>> 
>> On Jan 25, 2015, at 4:47 PM, Brian E Carpenter <[e-mail]<mailto:[e-mail]>> wrote:
>> 
>> Hi Carlos,
>> 
>> On 26/01/2015 08:49, Carlos Pignataro (cpignata) wrote:
>> Hi, Brian,
>> 
>> Thanks for your review! Please see inline.
>> 
>> On Jan 25, 2015, at 2:29 PM, Brian E Carpenter <[e-mail]<mailto:[e-mail]>> wrote:
>> 
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>> 
>> Document: draft-ietf-mpls-oam-ipv6-rao-02.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2015-01-26
>> IETF LC End Date: 2015-02-04
>> IESG Telechat date:
>> 
>> Summary: Almost ready
>> --------
>> 
>> Minor issues:
>> -------------
>> 
>> 1. Hop-by-hop options, and therefore Router Alert, are well known to
>> cause a serious performance issue or are simply ignored by many
>> routers (as warned in http://tools.ietf.org/html/rfc7045#section-2.2).
>> A pointer to that warning would be appropriate.
>> 
>> 
>> I do not believe this concern is very applicable to the MPLS OAM RAO. The whole point of RAO in an MPLS LSP is to be intercept the packet and punt it to a slow path, and it is not injected back. The MPLS OAM Router Alert option is invisible to the MPLS Label-switched hops, and when the LSP finishes, it is only processed once.
>> 
>> I am also not sure I understand the suggested action behind this comment. Are you suggesting we add a pointer to that Section, or that exact paragraph to the Security Considerations?
>> 
>> Well, maybe what you could do is add a statement that this type of RAO
>> is not subject to the problem of being ignored, because the appropriate
>> router will process it (on the slow path) by design. The generic problem
>> is that HbH options might be ignored even if the designer assumes otherwise,
>> which is why we added the warning in RFC 7045, and you're saying that
>> problem doesn't apply here.
>> 
>> Sounds good — I added the following paragraph (and Informational reference). All, can you please review?
>> 
>>   IPv6 packets containing the MPLS OAM Router Alert Option are
>>   encapsulated with an MPLS Header and not expected to be inspected by
>>   every label switched hop within an MPLS LSP.  Consequently, this
>>   value of the Router Alert Option will be processed by the appropriate
>>   router and is not subject to the problem of being ignored as
>>   described in Section 2.2 of [RFC7045].
>> 
>> 
>> 
>> 2. I'm a bit surprised to realise that new definitions of Router Alert
>> options are not routinely notified to the 6MAN WG.
>> 
>> We had run this through 6MAN, both on list and presenting twice in IETF meetings.
>> 
>> I must have been asleep, sorry!
>> 
>> 
>> No worries, thanks for the review!
>> 
>> — Carlos.
>> 
>>  Brian
>> 
>> Thanks!
>> 
>> Carlos.
>> 
>