RE: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06
I will try to come up with a way to address the MAC move topic. The challenge is to word it in such a way that it does not imply a new protocol for communicating such a move (Savi was/is prohibited by charter from doing protocol development.) Yours, Joel -Original Message- From: Ted Lemon [mailto:ted.le...@nominum.com] Sent: Wednesday, March 27, 2013 10:57 PM To: Joel Halpern Direct Cc: Black, David; Joel M. Halpern; McPherson, Danny; s...@ietf.org; ietf@ietf.org; gen-...@ietf.org; Jean-Michel Combes; Joel Halpern Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 On Mar 27, 2013, at 12:45 PM, Joel Halpern Direct jmh.dir...@joelhalpern.com wrote: Then it will be done. I will wait for the AD to decide what other changes are needed, and then will either make this change or include it in an RFC Editor note. Old: If the bridging topologies which connects the switches changes, or if LACP [IEEE802.3ad] changes which links are used to deliver traffic, the switch may need to move the SAVI state to a different port, are the state may need to be moved or reestablished on a different switch. New: If the bridging topologies which connects the switches changes, or if LACP [IEEE802.3ad], VRRP, or other link management operations, change which links are used to deliver traffic, the switch may need to move the SAVI state to a different port, are the state may need to be moved or reestablished on a different switch. I think you probably meant or, not are, in the second word of the second-to-last line of the new text. As far as I am concerned, given that David is happy with your recent change, I'm happy with it too. However, since you are asking, if you were willing to also accommodate David's other request (see below) by adding some text to the document in section 5, that would be an added bonus: A paragraph has been added to 5.2.3 to address all three of the above concerns. I guess that's ok, but I would have liked to see some text pointing out that a MAC move can be detected by the switches and used to update SAVI state about which port(s) a MAC is accessed through. So if you can do this, it would be much appreciated; if you can't do it, I think the document is valuable enough to move forward without this additional work.
RE: Gen-ART review of draft-ietf-savi-threat-scope-06
I think I can add text to address this. I will look more closely tomorrow, and send you a proposal. Thank you for all your efforts reviewing this. Yours, Joel Sent from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: Black, David [david.bl...@emc.com] Received: Tuesday, 26 Mar 2013, 7:45pm To: Ted Lemon [ted.le...@nominum.com] CC: McPherson, Danny [dmcpher...@verisign.com]; Fred Baker [f...@cisco.com]; Joel Halpern [joel.halp...@ericsson.com]; gen-...@ietf.org [gen-...@ietf.org]; Jean-Michel Combes [jeanmichel.com...@gmail.com]; s...@ietf.org [s...@ietf.org]; ietf@ietf.org [ietf@ietf.org] Subject: RE: Gen-ART review of draft-ietf-savi-threat-scope-06 Ted, Remembering that this is an informational draft, which does a pretty good job of informing the reader about the problem space, is it your opinion that the issues you have raised _must_ be addressed before the document is published, or do you think the document is still valuable even if no further text is added to address your concern? At a minimum, in section 4.1.2, this should be addressed: b) the new text implies that LACP is the only way to cause this situation - it's not, so LACP should be used as an example. I'm not sure I've seen Fred's response, but that change would suffice. An RFC Editor note should suffice. Thanks, --David -Original Message- From: Ted Lemon [mailto:ted.le...@nominum.com] Sent: Monday, March 25, 2013 9:38 PM To: Black, David Cc: McPherson, Danny; Fred Baker; joel.halp...@ericsson.com; gen-...@ietf.org; Jean-Michel Combes; s...@ietf.org; ietf@ietf.org Subject: Re: Gen-ART review of draft-ietf-savi-threat-scope-06 On Mar 25, 2013, at 9:04 PM, Black, David david.bl...@emc.com wrote: Summary: This draft is on the right track, but has open issues, described in the review. While I identified the same issue you did with switching systems that do link aggregation and other magic, I think that the document is useful whether this is fixed or not. It's true that it doesn't have a full section that talks specifically about this problem, but I think it's unlikely that the authors are going to add one-when I mentioned it to Joel, he didn't express excitement at the prospect. I think Fred's response, while a little salty, accurately represents the situation: the working group produced this document, the document does what it's supposed to do, one could continue to polish it indefinitely, but then the document would never get published. Remembering that this is an informational draft, which does a pretty good job of informing the reader about the problem space, is it your opinion that the issues you have raised _must_ be addressed before the document is published, or do you think the document is still valuable even if no further text is added to address your concern?
Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06
Then it will be done. I will wait for the AD to decide what other changes are needed, and then will either make this change or include it in an RFC Editor note. Thank you, Joel On 3/27/2013 12:42 PM, Black, David wrote: That would do nicely. Thanks, --David -Original Message- From: Joel M. Halpern [mailto:j...@joelhalpern.com] Sent: Wednesday, March 27, 2013 12:30 PM To: Black, David Cc: Ted Lemon; McPherson, Danny; s...@ietf.org; ietf@ietf.org; gen- a...@ietf.org; Jean-Michel Combes; joel.halp...@ericsson.com Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 Would it suffice to replace Old: If the bridging topologies which connects the switches changes, or if LACP [IEEE802.3ad] changes which links are used to deliver traffic, the switch may need to move the SAVI state to a different port, are the state may need to be moved or reestablished on a different switch. New: If the bridging topologies which connects the switches changes, or if LACP [IEEE802.3ad], VRRP, or other link management operations, change which links are used to deliver traffic, the switch may need to move the SAVI state to a different port, are the state may need to be moved or reestablished on a different switch. ? Proposed changes on the second - fourth lines above. Yours, Joel On 3/26/2013 7:45 PM, Black, David wrote: Ted, Remembering that this is an informational draft, which does a pretty good job of informing the reader about the problem space, is it your opinion that the issues you have raised _must_ be addressed before the document is published, or do you think the document is still valuable even if no further text is added to address your concern? At a minimum, in section 4.1.2, this should be addressed: b) the new text implies that LACP is the only way to cause this situation - it's not, so LACP should be used as an example. I'm not sure I've seen Fred's response, but that change would suffice. An RFC Editor note should suffice. Thanks, --David -Original Message- From: Ted Lemon [mailto:ted.le...@nominum.com] Sent: Monday, March 25, 2013 9:38 PM To: Black, David Cc: McPherson, Danny; Fred Baker; joel.halp...@ericsson.com; gen- a...@ietf.org; Jean-Michel Combes; s...@ietf.org; ietf@ietf.org Subject: Re: Gen-ART review of draft-ietf-savi-threat-scope-06 On Mar 25, 2013, at 9:04 PM, Black, David david.bl...@emc.com wrote: Summary: This draft is on the right track, but has open issues, described in the review. While I identified the same issue you did with switching systems that do link aggregation and other magic, I think that the document is useful whether this is fixed or not. It's true that it doesn't have a full section that talks specifically about this problem, but I think it's unlikely that the authors are going to add one-when I mentioned it to Joel, he didn't express excitement at the prospect. I think Fred's response, while a little salty, accurately represents the situation: the working group produced this document, the document does what it's supposed to do, one could continue to polish it indefinitely, but then the document would never get published. Remembering that this is an informational draft, which does a pretty good job of informing the reader about the problem space, is it your opinion that the issues you have raised _must_ be addressed before the document is published, or do you think the document is still valuable even if no further text is added to address your concern? ___ savi mailing list s...@ietf.org https://www.ietf.org/mailman/listinfo/savi
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
Most of what you describe Sander sounds reasonable, and sounds aligned with what is i the deployment documents. The WG debated the EID allocation extensively. One could argue that there is no need for it, that we could merely request that PI allocations be granted for LISP EID usage individually. The WG felt that if we could get all IPv6 LISP EID allocations from a single block that was not used for anything else, that would simplify avoiding lookups in the mapping system that were inevitably going to fail. Thus the allocations request. Yours, Joel On 11/16/2012 4:12 PM, Sander Steffann wrote: Hi Joel, Why does any operator have a reason to carr any routes other than their paying customers? Because it provides connectivity for their customers. If we get this block allocaed, then it results in 1 extra routing entry in the global routing table to support LISP inter-working. An entry that some of their customers may use, whether the operator carrying it knows that or not. In fact, it would take significant extra work for the operator to somehow block this aggregate. If LISP fails, this is a small cost to find out. If LISP succeeds, this results in significant reduction in core tabl sizes for everyone. That still assumes the altruistic routing of the prefix. And I am afraid that if the usage of this block gets a bad reputation that all LISP usage will share that reputation. I really like LISP but I am still not convinced that it's a good idea. If we can find a way to get the EID prefix routed in a reliable way then I would love it! I really care about LISP and I am afraid that: people see unreliable routing for EID /16 = assume LISP is unreliable. That is why I am pushing so hard to get this sorted out. Hmmm. What about the following strategy: - Start with the EID prefix being handed out like PI - Either through the RIRs if they are willing to take the responsibility - Or from a separate registry - Some altruistic /16 PITRs might show up in the global BGP table - A holders of a (assume) /48 from the EID prefix can arrange PITRs for their own space - And announce it as a separate route in the global BGP table (for now) - Keep the routing and reliability under their own control - If the experiment is a success we advise ISPs to: - Install their own PITRs for the /16 - Filter out the /48s at their border The filtering of the more-specifics once they have their own PITRs will make sure that they use those PITRs and that they will use the most optimal path to the locators as soon as possible. It will also keep their routing table smaller. If enough big transit providers offer /16 PITRs to their customers then the more-specifics might be filtered on a larger scale. So, summary: The ways to reach a PITR would be a) Run your own PITR (big networks, LISP users) b) Use one from your transit(s) (smaller networks that don't have their own) c) Use an altruistic one as last resort As long as (a) and (b) aren't a reality the LISP users who don't want to rely on (c) can run/rent/etc a PITR for their own space. I think the routing community would really appreciate it if all those more-specific routes would be temporary until wide deployment of (a) and (b) make them unnecessary. And if this doesn't become a success we have a bunch of /48 prefixes to the separate PITRs in the BGP table. It won't be much, otherwise we would have declared success. So the risk of messing the BGP table up is very limited. And when can tell people: if you are bothered by those more-specifics in your routing table you can always deploy your own PITRs and filter the more-specifics at your border. That might keep everyone happy. What do you think? Thanks, Sander
Re: notes from discussion of KARP design guidelines
Joe, THE KARP WG Chairs have reviewed your comments, in order to figure out what the best way to address them. We would appreciate it if you could engage in discussion of this proposal on the KARP working group email list. If you feel we are still not understanding your point, we would be happy to make some time avaialble for discussion at the WG session in Quebec City. (Comments from anyone else, particularly WG members, on the proposals being made by the WG chairs are appreciated as well.) Rather than a line by line response, we have tried to find the common themes and respond to them. If we have missed major issues, please let us know. You raised concern about the use of the term on-the-wire. Rather than replace the term, we would prefer to add descriptive text early in the document. This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. With regard to your comment about identifiers, we can add in the description of protocol reviews indications that such reviews should be clear about what IDs the review considers need protecting, as that is important context for the protocol review. As noted in other exchanges, the document abstract needs a complete rewrite. It should be just an abstract, with the rest of the context either removed or moved to the introduction. In doing so, we will add text describing briefly the general concept of the routing protocol transport. In general however, protocol specific behaviors are to be left to the protocol analysis documents. Equally, descriptions of detailed threats will be left either to the threat document or to the individual protocol analysis document as appropriate. There are several items in your comments indicating that you would like to see more discussion in the design guidelines of the protocol layering. That does not seem to be a useful addition to this document. Again, individual protocol analysis documents will deal with that where it is appropriate, and avoid it where it is a distraction. We do not see useful general statements of guidance that can be put into this document. Adding some general text in the discussion of communication modes elaborating on the difference between the communication as seen by the routing and security components, and the actual communication (e.g. that what is seen as multicast may be delivered as broadcast or multiple uni-cast) does seem a helpful addition to the document, and we will do that. Yours, Joel and Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
