Chris, Thank you very much for the explanation. Your explanation is what I was looking for. It would be very nice to have your examples included (as Use Cases) in the document. Linda Dunbar -----Original Message----- From: Chris Morrow <morrowc@xxxxxxxxxxxxxx> Sent: Tuesday, March 17, 2020 7:12 PM To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx> Cc: ops-dir@xxxxxxxx; sidrops@xxxxxxxx; last-call@xxxxxxxx; draft-ietf-sidrops-ov-egress.all@xxxxxxxx Subject: Re: Opsdir last call review of draft-ietf-sidrops-ov-egress-01 Just sniping a reply... which may be out to left (or right!) field :) On Tue, 17 Mar 2020 21:53:35 +0000, Linda Dunbar via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Linda Dunbar > Review result: Not Ready > > I have reviewed this document as part of the Ops area directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the Ops area directors. > Document editors and WG chairs should treat these comments just like > any other last call comments. > > The document claims that it highlights an important use case of origin > validation in eBGP egress policies, explaining specifics of correct > implementation in this context. But I don't see where the "Use Case" > is described. It seems to me that the document should have more > sections to describe the Use Case and the procedure of Egress Export > of the RPKI validated Origins. > > Section 3 Egress Processing only has one sentence stating that "When > applied to egress policy, validation state MUST be determined using > the effective origin AS of the route as it will (or would) be announced to the > peer." What other choices there are ? Are there any routers that support RFC > 6480 RPKI not performing this step? how? > I think the sense of this sentence is really: "Your router may have configured ASXXX and present itself (confedaration) as ASYYY to peer1 and ASBBB to peer2 (merger/acquisition issues). Please make sure that you validate the origin accordingly" There are a few example networks in the real world where this sort of thing could be super relevant. Particularly look at recent 'network that merges a bunch' Level3/CenturyLink/Savvis/GlobalCrossing/etc... AS3356/AS209/AS<iforget>/AS3459/AS3549. A single edge device terminating customers on the 3356 backbone may plausibly have customers that haven't swapped over to 3356 and are actually expecting the remote peer to be any of 6 or more ASN. It's important that the 'i originated this prefix, I'm 3356, wait 3549, want 3459...' decision is backed up in ROA content as well as validation logic. Looking at the abstract to maybe dig a little deeper: "For egress policy, it is important that the classification uses the effective origin AS of the processed route, which may specifically be altered by the commonly available knobs such as removing private ASs, confederation handling, and other modifications of the origin AS." So somewhere deep in my network, bb01.pop01 has: 192.0.2.0/24 staticly routed, redistributed in BGP and marked for external announcement (community/etc). That route, internally has an origin-AS of: 65507 because that's one of the several private ASN that make up my confederation: ASBAR. So, when I announce: 192.0.2.0/24 - origin 65507 I need to both swap the origin in the bgp announcement and validate against the local-as the peer sees me as. 192.0.2/0/24 - origin 3356 192.0.2.0/24 - origin 3549 ...etc... This will require me to make ROA for all of these origins, as well. I think anyway that's the goal of the document, really. though, also, I could have missed the forest for the trees here. -chris > My two cents. > > Linda Dunbar > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
