Thank you.
> On Jan 26, 2015, at 5:05 PM, Brian E Carpenter <[email protected]> > 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 >> <[email protected]<mailto:[email protected]>> 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 >> <[email protected]<mailto:[email protected]>> 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. >> > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
