Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt

[Stephen Kent]

Andy,



...
Steve,

Given what I said initially in this thread, I thought we were talking 
about the same thing. I guess not. We could tease this apart, but is 
it worth it if “Randy’s view” covers all situations?


-andy
Randy's approach covers both cases, at the cost of some added complexity 
for what I suspect
is the most common case. Whether that's preferable to two similar, but 
slightly different
mechanisms, where one is optimized for the (purported) most common case 
is a matter of
engineering taste. The WG will have to decide at some point, when we 
have complete, detailed

proposals for both.

Steve

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer

[Sriram, Kotikalapudi]

Your explanations make it very clear, thanks.

Thanks, Andrei. 
Looks like we've converged on pretty much all issues that we've discussed so 
far in this thread.
One comment inline below.

[...]
 If my considerations are correct, there are only two cases -
 upstreams/transit providers, for which RLP doesn't matter, and others
 (customers and peers) where an RLP indicates a leak and has to be dealt
 accordingly.

 Yes, I agree that detecting route leaks from customers/peers matters.
 Detecting route leaks from upstreams/transit providers does not really matter
 (as explained above).

I guess what I am arguing for is that the semantics of RLP 01 should be
propagate only down rather than do not propagate up and any updates
with the RLP field set from a peer or a customer should be treated as a
leak.

OK, I see now what you meant. Your suggestion is good. 
In the draft, currently in Section 3.2.2 do not propagate up 
is interpreted (implicitly) as propagate only down for a peer.  
But with this change (as suggested above by you) , we no longer have to 
make that distinction. The semantics of RLP 01 would be the same 
whether an update is received from a customer or a peer. 
Then route leak detection algorithm would be the same for customer or peer,
and sections 3.2.1 and 3.2.2 can be merged into one. Thanks.

Sriram   

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr