IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2014-01-23. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
2.3 Status Changes
2.3.1 New Items
2.3.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 Status Changes
3.3.1 New Items
3.3.2 Returning Items
3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items
3.4.2 Returning Items
1229 EST break
1235 EST back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
7. Agenda Working Group News
1250 EST entered executive session
(at 2014-01-23 07:30:06 PST)
Based on a quick skim of this document and the judgement that it has no direct impact on the routing infrastructure, I am balloting No Objection.
This is an algorithm to generate stable, private, and mostly unique addresses. It does not affect interoperability at all if people choose a different method. Anyone can accomplish the same task in a number of different ways. This is just a nice method to use if someone wanted to use it. This should just be an Informational document explaining a nice way to generate stable, private, mostly unique addresses without all of the MUSTs and SHOULDs, which are not interoperability requirements in the first place. Standardizing this is silly in the extreme.
(0) Just modifying my disucss to discuss a part of Brian's discuss:-) I'm sure we'll sort it out easily enough though. I very much do not think that it'd be a good plan to store every address that has been generated using this algorithm. That would be making a privacy-enhancing feature damage privacy. See  for an example.  http://www.theguardian.com/technology/2011/apr/20/iphone-tracking-prompts-privacy-fears (1) Section 5: Why mention only MD5 and SHA1? Why not HMAC-SHA256? As-is, implementers are likely to get this wrong in various ways, e.g. allowing MD5 collisions to be generated on purpose with different inputs perhaps as a way to assign blame to an innocent victim. If HMAC-MD5 or better (*) HMAC-SHA256 were recommended instead, it is far more likley that implementers will do the right thing and it seems just as easy to do today's right thing as what's mentioned here. (*) Even though HMAC-MD5 is still ok, its better (for audit reasons) if we reduce the number of copies of MD5 runtime code on systems and do not introduce new instances of that code. (2) Why might a sys admin want to display the secret key? If there's a reason shouldn't you say so that coders don't do the wrong thing? The concern is that once established, this key might be re-used for other purposes and display might then become an interesting attack vector.
- Probably not worth investigating, but I'd wonder if a bad-actor with the 64 bit prefix to play about with could force an IID on a node that used plain MD5 with a guessable or known secret_key. I don't think that's doable today but its yet another reason to avoid very outdated hash functions like md5. This is a non-issue if discuss#1 is resolved by ditching MD5.
Section 2., paragraph 4: > Note that the result of F() in the algorithm above is no more secure > than the secret key. If an attacker is aware of the PRF that is > being used by the victim (which we should expect), and the attacker > can obtain enough material (i.e. addresses configured by the victim), > the attacker may simply search the entire secret-key space to find > matches. To protect against this, the secret key should be of a > reasonable length. Key lengths of at least 128 bits should be > adequate. The secret key is initialized at system installation time > to a pseudo-random number, thus allowing this mechanism to be enabled > /used automatically, without user intervention. Isn't there a requirement (MUST) or at least a recommendation (RECOMMENDED) to say something about the minimum length of the secret key? Just to let implementers know from what length on the secret is 'safe' as input?
Please Tim's OPS DIR review (currently under discussion) First, I would note that I have already contributed comments/text to this draft, as acknowledged by Fernando. It’s been a few versions since I last read it. The goal of the draft has considerable merit, and I believe the document is worthy of publication, subject to comments belwo being considered. I would classify the document as ‘Ready with issues’. Issues: 1. In the discussion in section 5 on the algorithm, it may be desirable to suggest that implementations allow a choice of IID generation based on ‘classic’ SLAAC with EUI-64 or via this new proposed method, with a default of the new method. 2. In the algorithm section, there is a comment that interface names MUST remain the same across boots or down/up events for the stable privacy address to remain stable. I have (admittedly some time ago, and in rare cases) seen Linux installations where network interface names can ‘swap’, thus changing the address in use on the interface under the proposed algorithm, whereas with existing EUI64 SLAAC the IIDs would remain the same even if the interface name for a physical interface changed. This is probably rather more likely if replacing a network card on motherboard with on-board NIC(s). Perhaps Fernando can comment on whether this is a realistic concern with modern OSes. 3. I assume the IID may/will vary for a different OS run on the same host, e.g. where the host is dual-boot, or where a new OS installed (or the same OS re-installed). A different OS may well use a different F(), given that’s not specified. With EUI-64, a dual-boot host would likely have the same address under either OS (well, not Windows any more…). This may be worth making explicit. 4. The draft talks (in one place in Section 3) about stable privacy addresses being allocated by DHCPv6; some further discussion of how this might be achieved may be useful given the secret key is presumed to be generated on and reside on the host, not the DHCPv6 server. Or would this be described in a separate future draft? This may be a case where the administrator being able to display or change the secret key needs to be more than a MAY as currently satted in the text. 5. Design goal 1 might add “and same interface” for scenarios where a host has two interfaces in the same subnet (with the same prefix). This scenario is one that may cause ‘interesting’ effects with addresses if interface names swap and no Network_ID is used. 6. I’d suggest not mentioning MD5. Nits: 1. Some references are included multiple times, e.g. [RFC4941], rather than only at the first instance. 2. Design goal 2, perhaps say “must” rather than “do”? 3. In section 4 the author states the goal of stable IIDs within a given subnet. It may be better to say for a given prefix, given a renumbering process will change the prefix and with it the IID, though by loose language you might refer to it as the same subnet. In response to recent discussion on 6man, I don’t believe it’s practical or desirable for a node to store addresses related to locations (networks) visited. I agree with the author that the static address per network should be generated statelessly.
This is a very well-written and clear document. Thank you for that.
I am taking the somewhat curious route of raising a DISCUSS on a document that I am shepherding. I will return to a Yes when these issues are resolved. Thomas Narten raised a good point that this document does not mention the work published in RFCs 4436 and 6059 (from the concluded DNA WG). Two of the points he raised are worth addressing in this document prior to publication. 1. [Resolved] - Storing addresses is going to raise privacy issues. 2. DNA provides some ability to manage the Network_ID component of the cryptographic hash. For wired networks, that may be quite useful as long as the Network_ID can be stored securely.
As Adrian says, this does not look like it impacts the routing systems so based on a quick skim, no objection. I am, however, left pondering as to whether a simple call to the system RNG wouldn't work well enough most of the time.
The document seems to gloss over the problem of interface name stability for removable interfaces.There is some mention of naming interfaces based on slots in the appendixes, but no talk about what to do if interface names aren't stable across inserts and removals of network hardware. I'm not convinced that there is anything that can be done about this here, but it might be worth mentioning as an issue, and I didn't see it mentioned.
I have no objection to the publication, but I have a few small points you may want to consider before passing this document to the RFC Editor. === Section 2 o The data model should include read-only counters in order to gather statistics for octets, packets and errors, sent and received. Very pedantically, out-errors is not a count of errors sent. It is a count of what could not be sent because of some error. --- Section 4 Paragraphs 1, 2, 4, and 5 When I see "typically" or "in most cases" or "generally" (or "usually" or "normally") I look for the explanation of the variation. I don't find one in these cases. Is that significant? --- Section 4 There are two scalars in IF-MIB (ifNumber and ifTablelastChange). It would be good if this section mentioned those objects and why they are not mapped to anything in this YANG module. --- The two tables in Section 4 give good guidance on mapping between this YANG module and the objects in the tables in IF-MIB. For one object in ifXEntry, the text explains why there is no mapping (ifPromiscuousMode). Two objects in ifEntry are deprecated so it is probably reasonable to not mention them (ifOutQLen, ifSpecific). And the low capacity counters are also covered in the text. However, that leaves eight objects unmentioned. It would be helpful to show how these are mapped or explain why they are not needed. ifEntry ifDescr DisplayString, ifMtu Integer32, ifAdminStatus INTEGER, ifOperStatus INTEGER, ifLastChange TimeTicks, ifXEntry ifHighSpeed Gauge32, ifConnectorPresent TruthValue, ifCounterDiscontinuityTime TimeStamp
1.1: Maybe it won't be confusing but I think those definitions mean a USB stick GSM modem would be a system controlled interface and not a user controlled interface which seems counterintuitive. Would it be worth adding an example like that to avoid potential confusion?
I had not reviewed a YANG data model previously. This document is about as clear as I can imagine a document with this content being. Nice work!
I agree with Adrian's comments on the relationship between this YANG module and the IF-MIB.
Alexey Melnikov raised two valid points in his Gen-ART review. I'm hoping the draft is revised according to the discussion that took place after the review.
From Carlos' OPS-DIR review: This is a really well written document. It addresses operational considerations of backwards compatibility of the new protocol constructs defined. Other considerations for operational impact are covered in the base protocol. Nits: RFC 5342 was obsoleted by RFC 7042 and the pointer should probably be updated.
This draft is nicely written. Thank you for that. I did have one comment. Please consider it along with any other comments you receive. In 2.2.3 Appointed Forwarders Sub-TLV o Start.VLAN, End.VLAN: These fields are the VLAN IDs of the appointment range, inclusive. To specify a single VLAN, the VLAN's ID appears as both the start and end VLAN. As specified in [RFC6439], appointing an IS forwarder on a port for a VLAN not enabled on that port has no effect. If the range specified is or includes the value 0x000 or 0xFFF, such values are ignored as they are not valid VLAN numbers and a port cannot be enabled for them. and in 2.3.6 Interested VLANs and Spanning Tree Roots Sub-TLV - VLAN.start and VLAN.end: This VLAN ID range is inclusive. Setting both VLAN.start and VLAN.end to the same value indicates a range of one VLAN ID. If VLAN.start is not equal to VLAN.end and VLAN.start is 0x000, the sub-TLV is interpreted as if VLAN.start was 0x001. If VLAN.start is not equal to VLAN.end and VLAN.end is 0xFFF, the sub-TVL is interpreted as if VLAN.end was 0xFFE. If VLAN.end is less than VLAN.start, the sub-TLV is ignored. If both VLAN.start and VLAN.end are 0x000 or both are 0xFFF, the sub-TLV is ignored. I THINK these descriptions are saying the same thing, but the description in 2.3.6 was more precise and more clear to me. If they are saying the same thing, I'd suggest using the 2.3.6 description in both places. For extra credit, the point from 2.2.3 that "0x000 and 0xFFF are not valid VLAN numbers and a port cannot be enabled for them" could usefully appear in both places.
I'm holding this Discuss for two issues raised by IANA. I will move to "Yes" when they have been addressed. 1. The authors need to update the next version of the document to clarify the value 0 in the new Error subcode registry and use the term "Unassigned", rather than "Not allocated". We can handle this with an RFC Editor note, but I need the authors to agree some text. 2. You indicated that "There is no top value to the range." in section 5.5.3. That means that the new created registry "RSVP-TE OAM Configuration Registry" has no maximum values (bit numbers). We want to make sure we understood it correctly. This can be answered by email. Are you indicating that there can be any number of bits allocated over time? Of course, there is a practical limit to this set by the length field of TLVs, Objects, and Messages.
This is an extremely trivial DISCUSS, and it will take about 17 milliseconds to fix it. In the subsections of Section 5.5, registration policies are specified ("IETF Review" and "Experimental") without reference to any definition of those policies (RFC 5226). I suggest this change: OLD IANA is requested to create sub-registries as defined in the following subsections: NEW IANA is requested to create sub-registries as defined in the following subsections. The registration procedures specified are as defined in [RFC5226]. END (And, of course, add a normative reference to RFC 5226.)
A very minor editorial point in the abstract: I found myself wishing that the abstract used "OAM" a few times, instead of repeating the expansion five times. Please consider making it "Operations, Administration and Maintenance (OAM)" the first time, and just "OAM" the other four.
This is a well written document and I just have a few nits that you might consider. There were a number of terms that as far as I could see were unexpanded on first use and are not "well known". I picked up DWDM, RSVP-TE, LSP, WSON, TDM, SDH/SONET. Please can I suggest an quick abbreviation scrub. With the text "the ADMIN_STATUS Object is specified for RSVP-TE in [RFC3473]. " This ref should go a little earlier in the para, when you first use the term "If this is not possible, a PathErr SHOULD be sent " and "a ResvErr may be sent" Presumable these are "messages" or "responses" 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OAM Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ sub-TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: indicates a new type: the OAM Configuration TLV (IANA to assign). Is the length syntax well known in this context?
Thanks for clearly identifying the new security consideration and explaining how it can be mitigated.
lools like -12 addressed outstanding opsdir comments.
Thanks for addressing my Discuss and Comments
I thought about making this a trivial DISCUSS, but decided that you'll fix it either way, so I'll just leave it as a COMMENT: In Section 3.1, you say, 'The remaining values (0x10 through 0x80) are to be assigned by IANA using the "IETF Consensus" policy defined in [RFC5226].' The policy defined in 5226 is called "IETF Review", not "IETF Consensus". Please fix that here; thanks.
As noted by Scott in his OPS-DIR review: I do note that the ID does not actually say why a reorganization id a good thing to do. It might be good to add a sentence or two to explain the advantages of this work.
My aim is to vote yes, but I think that it is worth discussing the following point: Updates: RFC-ietf-mpls-gach-adv, RFC-ietf-mpls-tp-ethernet-addressing Given that these texts are in the RFC Editor's queue, albeit about to be released by a blocking reference, it would be clearer to the reader if we were to modify the IANA section directly using an RFC Editor's note and remove the update that this RFC proposes. Given that the shepherd and the AD are the same for all three drafts this should be straightforward to address. In addressing this the note about changing the references should also be addressed.
There are three parts to my Discuss. --- Section 2.1.1 reads strangely. Your use of "appears" twice in the first paragraph is uncomfortable. It is not advisable to state your understanding of how the use of ICMP was adopted in the working group, and it is irrelevant. That use of ICMP has IETF consensus and is in no way hidden in the document. It is fine to say that RPL should not be a model for future uses of ICMP and so similar message types should not be defined in future. Your observations about reliability and security guarantees in routing protocol transport requirements miss the mark by a long way (or is BGP the only routing protocol?). The two IGPs in common use these days are designed to run over IP or native Ethernet and must make their own provisions for reliability, while security is built in to the protocols as much as acquired from IPsec. The main things that ICMP gives RPL are a checksum, a protocol ID, and no requirement to be encapsulated in UDP (I make no comment about which of those is good). Can I suggest: OLD RPL, the IPv6 Routing protocol for low-power and lossy networks (see [RFC6550]) appears to be something of an outlier among the existing ICMP message types, as the expansion of its acronym appears to be an actual routing protocol using ICMP for transport. This should be considered anomalous and is not a model for future ICMP message types. Our understanding is that the working group initially defined a discovery protocol extending existing ICMPv6 Neighbor Discovery messages before moving to its own native ICMP type. It is typically the case that routing protocols have transport requirements that are not met by ICMP. For example, there will be reliability guarantees and security guarantees that are not provided by ICMP, forcing protocol developers to design their own mechanisms. Given the availability of other IETF standard transports for routing, this reinvention should be avoided. NEW RPL, the IPv6 Routing protocol for low-power and lossy networks (see [RFC6550]) uses ICMP as a transport. This should be considered anomalous and is not a model for future ICMP message types. That is, ICMP is not intended as a transport for other protocols and should not be used in that way in future specifications. END --- I really take issue with quite a bit of the content of section 4. As the authors observe... this may serve to muddle the differences even further. Ultimately the difference may not matter that much ...perhaps it would be wiser to leave out what is a disctraction fom the main AUP. But, in case the authors prefer to try to address my gripes... 1. There is a difference between a plane and a protocol that this text does not show. Indeed it seems to use the word "plane" to mean "protocol". 2. The term "layering" in telecommunications networks is not usually used to refer to this separation of function, but to either protocol layering (a la OSI model) or technology layering (that leads to network layering). The control plane and management plane are not layers but may utlise network partitions (sometime in band and sometimes physical). 3. The references to [I-D.ietf-opsawg-oam-overview] and [RFC6192] are somewhat arbitrary. It is true that the referenced documents provide descriptions, but are they normative? 4. It will be a surprise to people running routing protocols to find that they do notform part of the control plane. 5. I think if you were to observe (as you sort of do) that control plane interactions are between nodes for the purpose of operating the network, while management plane interactions are between nodes and external boxes for the same purpose, you would get closer to the truth. 6. Since you reference [I-D.ietf-opsawg-oam-overview] you might usefully spend time describing OAM protocols and their purposes. You could note that OAM protocols typically run in the data plane yet serve the purpose of control and management plane protocols. Then you could observe that ICMP is an OAM protocol, and move on. 7. Your final sentence reads... ICMP should not be used as a routing or network management protocol. ...which may be true, but I think you mean ICMP should not be used as a transport for any other protocol. That last sentence notwithstanding (and it is already present in other parts of the document) I strongly recommend to delete Section 4. --- Section 5 From a security perspective, ICMP plays a part in the Photuris protocol. Reference please.
I'm not yet recording a position on this document; I'd like to get a bit more info. The shepherd writeup says, "This document is not the product of any WG. It is AD sponsored. However, it has been reviewed by the OPSAREA and INTAREA WGs" I went looking through the archives (Googling) and found this message (and its thread): http://www.ietf.org/mail-archive/web/ipv6/current/msg19850.html That had two reviews, one of which said, "I don't understand the motivation of the document" and the other of which said, "I'm not an expert on this stuff, but here are some comments." I couldn't find any other significant reviews, and importantly I couldn't find any messages that indicated this was important work that needed to be published as a BCP. Can someone give me some pointers to where this was actually discussed, and some indication that there is some consensus in the community that the AUP documented here is a good and necessary thing? It's fine if it's only a few experts (of which I am not one) think it's important to say this stuff and everyone else just shrugs and says, "Whatever". But I'd like to see some indication of that. I hope I'm just a bad googler.
- I'm not sure that AUP is a good term here really - I guess discussion of Brian's discuss might sort out this comment but I didn't find the acceptable uses described at the top of section 2 clear. - Would it be worth adding something to the security considerations that e.g. new ICMP stuff needs to consider how ICMP can be abused (e.g. )?  https://www.nordu.net/articles/smurf.html
I have no objection to the publication of this draft, if this is the stick to keep bad ideas about extending ICMP away.
I have absolutely no objection to this document. The only comment I have is that (modulo Pete's comment) I think it should be Standards Track (an Applicability Statement), and not BCP. It's not worth arguing about it and holding anything up for that, but I'll note that, as it was last called as BCP, the IESG can decide to change the status without causing any delay to the document.
I have no objection to publishing this draft, but the current discussions taking place during IESG Evaluation seem to identify changes that would be very helpful if the document reflected at least some of them.
I am going to start this as a DISCUSSion and we will see where it goes from there... First of all, I agree with a large majority of Adrian's DISCUSS points. I am having a really hard time seeing what this document will accomplish. If it had been written 20 years ago, I think it would have had a significant impact on the development of many protocols and probably would have improved some of them. That being said, I don't see the benefit now. In ICMPv4, not counting the two Types defined for Experimentation, the last Type was registered 8.5 years ago. Are we expecting a rash of ICMPv4 messages to be defined in the near future? One could argue that ICMPv6 is a different story. However, the base spec for ICMPv6 (RFC 4443) clearly states that ICMPv6 is going to be used as an integral part of the IPv6 protocol suite. It supports link-local functions like neighbor discovery and multicast group management. It also supports Internet-wide functions like Path MTU Discovery and mobility management in addition to the general purpose error/informational messaging. In other words, the core IPv6 architecture assumes ICMPv6 will be an integral part of the protocol suite. That also means that the statement in section 2.3 about why firewalls and routers have more control over ICMPv6 messages is rather incomplete. Given the above, is the intent of this AUP to preclude the extension of ICMPv6? Will an update to an existing (e.g., mobility) protocol that currently use ICMPv6 be required to migrate to a different approach? I am not sure that the two broad categories in section 2 are clear enough with respect to how the IPv6 architecture envisions the use of ICMPv6.
I support the Discusses of Adrian and Brian, and would particularly like to discuss the following with the authors. "It is typically the case that routing protocols have transport requirements that are not met by ICMP. For example, there will be reliability guarantees and security guarantees that are not provided by ICMP, forcing protocol developers to design their own mechanisms. Given the availability of other IETF standard transports for routing, this reinvention should be avoided." This is somewhat belittling of the routing protocol designers, who have existence proof that they understand the finer points of their art. It should be removed. "3. ICMP's role in the internet" Surely ICMP is first and foremost the IP layer OAM? Similarly Section 4 is seeming confused because it does not consider ICMP as an OAM protocol. Section 3 and 4 could and should be simplified by focusing on the role of ICMP rather than its name which pre-dates the IETF's more developed understanding of OAM protocols.
Was odd to see photuris dredged up here. Since it lost out to isakmp / IKE around 1996 I'm not sure that it's illustrative of much with respect to ICMP except as a side channel into the inner-workings of the ipsec working-group. I find on revisiting this that I'm somewhat unsatisfied with the ontology described in section 4 (something it admits to). the premise of and AUP hinges in fact no there being appropriate or inappropriate actions. I doubt this is really discuss-worthy however.
Thank you for writing an important document for guiding the future standards development in this area. I have no objection to its publication, but I found a small list of nits you may wish to fix before proceeding. === The RFC Editor will want to move the Introduction to be the first section in the document. If you are revising this document, you might want to take care of that yourselves to make sure that no errors are introduced when it happens. --- This is a good example of when use of upper case words is useful to emphasize the reuirements language, but you are not using them in the sense of RFC 2119. in such cases it is common to vary the bolierplate to say something like: Although this is not a protocol specification, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are used for clarity and emphasis of requirements language and are to be interpreted as described in [RFC2119]. However, I think you should limit your use of this language to within the text of the requirements themselves. For example, look at the first paragraph of Section 4.2: here is is unclear whether the text is stating requirements or guiding the requirements that will be stated later (R2). You may also want to think about the meaning of "SHOULD" in a requirement. Under what circumstances are the developers of a solution allowed to discard this requirement? --- H-VPLS, VPWS and VLAN need to be expanded on first use. --- The concept of "redundancy group" could do with fuller introduction maybe by giving it an entry of its own in Section 2. Similarly, "multi-home group" is used in Section 4 in a way that its meaning can be deduced, but there is no formal definition. --- (R2) A solution MUST be able to exercise as many ECMP paths as possible between any pair of PEs in conjunction with the all-active load-balancing described above. Forgive my pedantry, but "as many as possible" is open to willful misinterpretation. I think you want (R2) A solution MUST be able to exercise all ECMP paths between any pair of PEs in conjunction with the all-active load-balancing described above. --- Section 4.3 The latter is desirable when offering a geo-redundant solution that ensures business continuity for critical applications in the case of power outages, natural disasters, etc. In fact, it is more than "desirable", it is part of the definition of geo-redundancy, isn't it? --- Section 4.4 s/R4:/(R4)/ --- Section 4.6 Readers may find the first sentence ambiguous... There are applications, which require an Ethernet network, rather than a single device, to be multi-homed to a group of PEs. I think... s/which/that/ It is the network that is multi-homed not the the single device. But I may have this wrong. Think about rewording it? --- Section 5 lines 1, 4, and 8 s/usage/use/ --- Section 6 Implementations SHOULD revert to using default values for parameters as and where applicable. Not clear whether this is part of R6e, R6f in its own right, or general discriptive text. "As and where applicable" may be considered by an implementer as an easy way out of having to do anything! You might want to constrain them by making a statement of that applicability in your document. --- Section 7 It is worth noting that the term 'bridge domain' as used above refers to a MAC forwarding table as defined in the IEEE bridge model, and does not denote or imply any specific implementation. A reference for the "IEEE bridge model" would be nice. --- Section 7 It looks to me that this section includes a number of specific requirements that have not been numbered. It would be helpful to call these out explicitly to distinguish them from the descriptive text. --- Section 9 appears to have a number of requirements that are not specifically called out as numbered requirements. --- Section 10 s/(R12)/(R12a)/ --- I would move Section 11 down so that the requirements in Section 12 are not orphaned.
Just a curiosity question from the Transport Area side of life: Section 4.1., paragraph 2: > i. Layer 2: Source MAC Address, Destination MAC Address, VLAN > ii. Layer 3: Source IP Address, Destination IP Address > iii. Layer 4: UDP or TCP Source Port, Destination Port Has SCTP ever been considered for Flow-based Load Balancing in the scope of this draft? I know that SCTP is not that heavily used by now, but this could change in the near future, especially when it comes to data centers.
Vijay Gurbani raised an issue with R13 and R14 that I thought had merit. Should this result in some edits?
- I'm very surprised not to see any operational requirements, like OAM and fault. Can you please justify why you omitted those? (no objection on this point for now) - The IESG recently reviewed a L2VPN requirements doc, "Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in L2VPN", draft-ietf-l2vpn-etree-reqt: I don't quite get the link between the two documents: complimentary, cover different use cases, overlapping, etc.? - 4.5. Flexible Redundancy Grouping Support (R5) In order to simplify service provisioning and activation, the multi-homing mechanism SHOULD allow arbitrary grouping of PE nodes into redundancy groups where each redundancy group represents all multi-homed groups that share the same group of PEs. This is best explained with an example: consider three PE nodes - PE1, PE2 and PE3. The multi-homing mechanism MUST allow a given PE, say PE1, to be part of multiple redundancy groups concurrently. For example, there can be a group (PE1, PE2), a group (PE1, PE3), and another group (PE2, PE3) where CEs could be multi-homed to any one of these three redundancy groups. I don't understand "in order to simplify service provisioning and activation" as a justification for this requirement. As the title says, it's about flexibility. If it's really about "simplify service provisioning", then it should be in section 6 - Agreed with Barry on the MAY in a requirements document
Minor editorial point: The Introduction reads oddly to me, with four paragraphs in a row that all start with some version of "also": "Furthermore," "Also," "In addition," and "Moreover." I think you can just delete them all, really. (R1c), and others: I'm always skeptical of "MAY" in protocols, but I *really* wonder about it in requirements. What does it mean to say that a solution MAY support something? That seems to me to be entirely a non-requirement. (R3d), and others: Favourable comment here... As Adrian does, I always think it's important to explain SHOULDs, and especially so when SHOULD is used in requirements. Unlike Adrian, though, I think the explanatory text in each section does this quite well; thanks.
This draft was easy to read and quite clear, with a couple of exceptions. Please consider these comments along with any other comments you receive. In 4.3. Geo-redundant PE Nodes (R3b) A solution MUST NOT assume that the IGP cost from a remote PE to each of the PEs in the multi-homed group is the same. I'm guessing how to read "MUST NOT assume". Is it saying something like this? (R3b) A solution MUST support different IGP costs from a remote PE to each of the PEs in a multi-homed group. In 6. Ease of Provisioning Requirements Implementations SHOULD revert to using default values for parameters as and where applicable. I'm not clear on how I would know that an implementation is reverting "as and where applicable". Is there any guidance about that you could include? I'm also supportive of comments made by Adrian and Barry (well, actually, "the other ADs").
I have no objection to the publication of this document. Here are a few thoughts for consideration... === Please add "(GRT)" after "Global Routing Table" in Section 4. --- Section 4.4 seems inconclusive. Would you consider adding some recommendations to the existing observations? -- I'd be interested to know whether you consider MPLS (data plane) security requirements are added by this architecture or if you think that existing IP (and higher) security is sufficient.
(1) 3.7: seems to not say enough about what's needed here - the parenthetic "(securely)" isn't at all descriptive. I think this should be easy enough to fix via a bit of text and maybe some references that just call out the security and privacy requirements associated with such logs. Some mention of RFC2804 would maybe be useful as part of that, not sure. (2) Section 8: Are there really *no* security considerations when we add a big concentrator in the middle of the network? Not even a bigger DoS impact if that machine is DoSed? That is very hard to believe.
Section 4., paragraph 1: > The BGP/MPLS IP VPN [RFC4364] framework for CGN segregates the 'pre- > translated' realms within the service provider space into Layer-3 What is 'pre-translated'? I guess you mean private IP addresses or private realm, isn't it? I wonder why this document is not reusing already established terminology, e.g., from RFC 1918?
Thanks for writing this useful document. Before recommending the approval of the document, I wanted to discuss one thing. The last sentence of Section 6 is odd. Can this be removed? I believe you have already talked about this on e-mail and plan to do so, so I'm just checking that this was indeed the plan, and can then move on to approve the document. In more detail: the sentence currently it gives an odd impression. We already have shared address space (as the document notes elsewhere), so it is not clear to me what the above might entail, particularly when (a) regular address space assignments go through the RIR system not IANA (b) use of unassigned address space is probably not something that we want to recommend and (c) if we need to do something beyond the existing shared address space allocation, then that probably deserves its own document.
This document was mostly accessible to readers not skilled in the art. Thank you. I did have some questions. Please consider them, along with any other comments you may receive. In section 3.7. Transactional Logging for CGN Systems CGNs may require transactional logging since the source IP and related transport protocol information is not easily visible to external hosts and system. If needed, the CGN systems should be able to generate logs which identify 'internal' host parameters (i.e. IP/Port) and associated them to external translated parameters imposed by the translator. The logged information should be stored on the CGN hardware and/or exported to an external system for processing. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I would have guessed that an "external system" would be a log collector *inside* the operator's network, but the rest of this section seems to be using "external" to describe something that is *outside* the operator's network, and here it looks like "external" is *outside the CGN hardware*. Or am I misreading this text? In 4.2. Internal Service Delivery First, the provider can reduce the load on the translator since internal services do not need to be factored into the scaling of the CGN hardware (which may be quite large). ^^^^^^^^^^^^^^^^^^^^^^^^^^ is this actually saying First, the provider can reduce the load on the translator since internal services (which may be quite large) do not need to be ^^^^^^^^^^^^^^^^^^^^^^^^^^ factored into the scaling of the CGN hardware. (in other words, the load from internal services is quite large)? You might address the following comment by asking the Nomcom for smarter ADs, but in 4.4.2. Traffic Engineering Traffic Engineering can also be used to direct traffic from an access node towards a translator. Traffic Engineering, like MPLS-TE, may be difficult to setup and maintain. Traffic Engineering provides additional benefits if used with MPLS by adding potentials for faster path re-convergence. Traffic Engineering paths would need to be updated and redefined overtime as CGN translation points are augmented or moved. is "Traffic Engineering" obviously distinct from MPLS-TE? ... if everyone but me knows what is meant here, that's great, but if there was a reference given for "Traffic Engineering", I would know, too :-) There is a reference given for MPLS-TE, but not for "Traffic Engineering".
- What is a "server layer"? I think I can guess but a ref/definition would be good. - Section 8: I would have thought that a layering like this could introduce new (or perhaps make obvious previously unrecognised) security issues if the layers are actually operated by/for different entities. Is that a potential deployment here? Or if this layering descruption is designed to only be used within a single administrative domain, then saying that would seem to be relevant.
No objection from my side, but idnits is rightfully yelling: == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: RFC 5654 requirement 33 requires the capability to carry a client MPLS-TP or MPLS layer over a server MPLS-TP or MPLS layer [RFC5654]. This is possible in all cases with one exception. When an MPLS LSP exceeds the capacity of any single component link it MAY be carried by a network using multipath techniques, but MAY NOT be carried by a single MPLS-TP LSP due to the inherent MPLS-TP capacity limitation imposed by MPLS-TP Operations, Administration, and Maintenance (OAM) fate sharing constraints and MPLS-TP LM OAM packet ordering constraints (see Section 3.1).
- 2. Definitions Please refer to the terminology related to multipath introduced in [I-D.ietf-rtgwg-cl-requirement]. I trust that draft-ietf-rtgwg-cl-requirement, which is work in progress, is quite stable, right? - IPFRR should be expanded, and I need a reference. Below is David Black's OPS DIR review I have reviewed this document as part of the operations directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operations area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: This draft is on the right track but has open issues, described in the review. I apologize for this review showing up a couple of days after the end of IETF Last Call. This draft discusses considerations for what are effectively MPLS-in-MPLS tunnels for multipathing - an LSP carries another LSP, with the inner (client) LSPs being distributed across multiple outer (server) LSPs that use different paths. This draft is motivated by considerations specific to MPLS-TP that complicate multipathing when one of the two MPLS instances is MPLS-TP. I consider the following to be open issues that need attention (each letter is used to tag the issue in the text that follows - [B] occurs multiple times, as there are multiple aspect to that issue): [A] Summary text in Introduction appears to be wrong. [B] Section 3.2 needs a summary. [C] Entropy label "sandwich" seems peculiar and at least needs an explanation. [D] Discussion of multipath impacts on MPLS OAM should be added to Section 4. --- Comments on draft text [A] Section 1 (Introduction) 2nd paragraph: RFC 5654 requirement 33 requires the capability to carry a client MPLS-TP or MPLS layer over a server MPLS-TP or MPLS layer [RFC5654]. This is possible in all cases with one exception. When an MPLS LSP exceeds the capacity of any single component link it MAY be carried by a network using multipath techniques, but MAY NOT be carried by a single MPLS-TP LSP due to the inherent MPLS-TP capacity limitation imposed by MPLS-TP Operations, Administration, and Maintenance (OAM) fate sharing constraints and MPLS-TP LM OAM packet ordering constraints (see Section 3.1). Section 3.1 concerns carrying MPLS-TP over MPLS, whereas the above exception appears to concern the reverse, and Section 4 on carrying MPLS over MPLS-TP allows for MPLS LSPs that exceed component link capacity. Was the exception intended to be for an MPLS-TP LSP that exceeds the capacity of any single component link? Also, "MAY NOT" is not an RFC 2119 term (for good reason - it's equivalent to "MAY OR MAY NOT"). I think "cannot" was intended her, but "MUST NOT" is another possibility. [B] Section 3.2 contains a lot of useful details, but it could really use a summary at the end on the options and recommendations for meeting the four requirements (this summary could be a new Section 3.3). It's a bit difficult to discern what's going on, as I had to read this section more than once in order to discern the following: [C] In Section 3.2, use of an MPLS entropy label to meet requirement MP#1 requires that it be "below the MPLS-TP label" whereas, to meet requirement MP#2, the MPLS entropy label needs to be "just above the MPLS-TP LSP label". This combination appears to suggest "sandwiching" the MPLS-TP label between two entropy labels that effectively carry the same information (albeit, applied and removed at different places in the network) - was that intended? This is important, as there seems to be no reasonable alternative to the entropy label for meeting requirement MP#2, and the draft's alternative to the entropy label for meeting requirement MP#1 is "some form of configuration" - the entropy label would seem to be preferred to that based on my reading of this draft and the comment in RFC 5706 section 2.2 that "Anything that can be configured can be misconfigured." [B] A summary of requirements for implementation and deployment at the end of Section 3.2 would have made this much more obvious. That should be provided in addition to addressing the above question about duplicate use of the MPLS entropy label. --- Relevant Q&A based on RFC 5706 Appendix A I'm omitting management concerns, as both MPLS and MPLS-TP have extensive management infrastructure, and this draft's notion of stacking LSPs so that one instance of MPLS (or MPLS-TP) can be a server to (i.e., carry) another is not novel to this draft. A.1.1. Has deployment been discussed? [B] Yes, although Section 3.2 is weak on deployment requirements (some of which are implementation requirements) and could use a summary. A.1.2. Has installation and initial setup been discussed? No, although because this draft reuses existing functionality in different configurations, this really reduces to the A.1.9 configuration question below. In practice, quite a bit of operator knowledge and insight is required to get initial setup right, e.g., as traffic engineering LSPs to avoid congestion problems (needed to meet requirement MP#3) requires significant knowledge of network structure and expected traffic flows. This should be obvious to anyone who works w/MPLS, but it's probably worth stating for completeness. A.1.6. Have suggestions for verifying correct operation been discussed? Yes and no. Section 3.2 discusses OAM, and contains this important requirement for OAM traffic: An Entropy Label must be used to insure that all of the MPLS-TP payload and OAM traffic are carried on the same component, except during very infrequent transitions due to load balancing. [D] OTOH, there is no discussion of OAM traffic for the MPLS LSP in Section 4; that should be added. A.1.9. Is configuration discussed? [B] Not much. Configuration is required to meet requirements MP#3 and MP#4, and is one of the options for MP#1. A summary of what has to be configured as part of the summary at the end of Section 3.2 would be a good idea. A.2.* [skipped, see above] A.3 Documentation There's quite a bit of operational material contained in this draft; a separate section on operations and management considerations would not be appropriate. There is a useful implementation status section which appears to imply that MPLS-TP over MPLS is not currently deployable due to absence of entropy label support, and because deployed MPLS equipment does not generally support multipathing. Nonetheless, data center experience indicates significant value and widespread use of multipathing based on link aggregation and ECMP; corresponding benefits can be expected for use of multipathing in the Internet beyond data centers. --- Editorial comments/nits: - Section 3.1, after RFC 5960 quotes: [RFC5960] paragraph 3 requires that packets within a specific ordered Insert "Section 3.1.1., before "paragraph 3" and likewise for "paragraph 6" later in the same paragraph in the draft. - Section 3.2, requirement MP#3: MP#3 It SHOULD be possible to insure that MPLS-TP LSPs will not be "insure" -> "ensure" or "assure". Surely this draft does not envision operators taking out insurance policies on MPLS TP LSP behavior . - Section 3.2, last paragraph on p.8: An MPLS-TP LSP may not traverse multipath links on the path where MPLS-TP forwarding requirements cannot be met. "may not" is meaningless - I believe "MUST NOT" was intended here. - Section 4, middle of 3rd para: Editorial suggestions for clarity: OLD For those LSP that are larger than component link capacity, their capacity are not integer multiples of convenient capacity increments such as 10Gb/s. NEW For those LSPs that are larger than a component link capacity, the LSP capacities need not be (and often are not) integer multiples of convenient capacity increments such as 10Gb/s. In particular, "are not" seems wrong, as the "integer multiples" case is possible, so I changed "are not" to "need not be (and often are not)" in the suggested new text.
I have a number of Discuss point on this text which I think will be easily addressed. "The ability to completely exclude MPLS-TP LSPs from the multipath hash and load split SHOULD be supported. " Surely this has to be a MUST since if it is not supported it breaks the MPLS-TP invariants on mis-ordering and fate sharing. "For those client LSP that are MPLS-TP LSP, a single EL value must be chosen. " This sounds like all MPLS-TP must use a single common value of EL. Thus is surely not the case. The requirement is that all packets for a particular MPLS-TP LSP must use a common EL value, but other MPLS-TP LSP may use a different value, and indeed there is good reason to encourage them to do so. I think that you later get to this point, but I find the text that you are using to build the case for the ELI quite confusing. "MPLS-TP LSPs can be carried as client LSPs within an MPLS server LSP if an Entropy Label Indicator (ELI) and Entropy Label (EL) is pushed below the server layer LSP label(s) in the label stack, just above the MPLS-TP LSP label entry [RFC6790]." I think that you need to clarify that this does not mean that the client needs to do this, the server can and should do it. "An MPLS-TP LSP must not traverse a server layer MPLS LSP which traverses any form of multipath not supporting termination of the entropy search at the EL label." Surely that is a protocol correctness MUST NOT? Then I think in the next sentence "the ingress LSR MUST be aware." There surely needs to be a requirements and some discussion on bi-directional co-routing, since this is not natural in MPLS. "however a change in path should not occur solely for load balancing." Since this is saying - please don't do it because you will break MPLS-TP's invariant, I think that needs SHOULD NOT with appropriate sentence rewording if needed.
I am wondering if it would be useful to discuss the case where it is desired to get MPLS-TP over MPLS, but load balancing is not needed. At first thought one might believe that all that is needed is to defeat ECMP with an intermediate control word. However the presence of L13 will be a problem. However a CW and a direct mapping of the MPLS-TP OAM to the PW-ACH would be a stateless mapping. I raise this point in response to the note that their are few networks that support ELI end to end, in which case the alternative mapping described above might be useful. I notice that Curtis is the sole author and yet is noted as editor, is this intentional.
This needs to get held up until the proposed update associated with David Black's review is out. Stewart's dicuss is sufficient for that, I would otherwise hold one if I felt it were necessary. Thanks
I am an author.
As someone who has gone to the effort of implementing PKCS#12, this is an enthusiastic Yes.
It'd maybe be good to note in 1.1 that "this standard" etc is language carried over fron the pkcs series to avoid confusion.
A hopefully very quick DISCUSS that I can immediately clear, and mostly for the shepherd: The shepherd report says that consultation with the IETF Trust took place and they were fine with the idea that RSA transferred copyright through Kathleen assertion, but it doesn't specifically say whether the Trust folks had a look at what copyrights RSA had reserved to itself in the Abstract. I'm no lawyer, but I'm worried that conflicts with the standard copyright template. If the answer is, "Yeah, we (the Trust) will work with the RFC Editor to make sure it says the right thing", I'm fine with this going forward. I just want to make sure that everyone is on-board.
I don't think I've seen an answer to Bert Wijnen's OPS DIR review (note that a mistake in the OPSDIR address might explain it) Here is Bert's feedback: From an operational and NM aspect, I do not see any issues. I do have some general questions/comments though. (None of them blocking though) - The documents iften says "this standard". That feels weird. It is targeted for INFORMATIONAL document and if with "this standard" it is meant to say "ietf standard", then that status is something that may change over the liftime of an RFC. I think it might be better to use "this document" or "this memo". - IN the security considerations section it syas: and relevant guidelines (e.g., SP 800-61-1) should be taken And in the change log it says: A reference was added to SP 800-132 for its recommendations... But I am missing the "citation" and the item in the REFERENCES section. I guess those active in security AREA all know where to find this, but for other readers it might be handy to have that refeneces in the list of references.
I'm making this a COMMENT for now, and will chat with Sean about it. Depending upon how that chat goes, it might morph into a DISCUSS. Or not. We'll see: I wonder why this is being published in the IETF stream, rather than the Independent stream, given that it's Informational, and not Standards Track. And given that it's Informational, and not Standards Track, I have an issue with the many times it calls itself "this standard" all through the document. Apart from that, I certainly have no objection to the publication of this as an RFC, and I'm glad to see that change control is being given to the IETF, so future versions could be put on Standards Track.
Barry and Benoit raise an important point that should be addressed.
Teetering on the brink of a Discuss. There appears to be an IETF Last Call comment that was not addressed. I think the second issue (that of an apparent contradiction) needs to be resolved and is sort of Discussable. === Section 2.1 says... Reservations of special-purpose AS Numbers are made through Internet Standards actions. Section 2.2 says... Reservation of special-purpose IPv4 addresses are made through Internet Standards actions. Section 2.3 says... Reservation of special-purpose IPv6 addresses are made through Internet Standards actions. Section 3 says... "IETF Review" as defined in [RFC5226] is required to reserve special- purpose AS numbers, IPv4 addresses, or IPv6 addresses. 1. 2.1, 2.2, and 2.3 should have a reference to 5226 2. Section 3 contradicts 2.1, 2.2, and 2.3. 3. Why is Section 3 present since there are no instructions for IANA?
- I didn't get the logic for why the registry content should be included here again, such duplication seems like a bad plan. - I also didn't get the reason for this draft, and neither did the secdir reviewer. Sorry if I've missed the explanations for the above in mail.
I'm going to elevate Adrian's comment to a DISCUSS. He's right that the IANA Considerations should be removed (well, should say that there are no IANA actions, and that the information in there should be in the proper place(s) in the document. Sections 2.1, 2.2, and 2.3 should say "through IETF Review [RFC5226]," instead of "through Internet Standards actions."
I have nothing to add beyond Barry's discuss points.
I have no problems with the publication of this document, but I am concerned with the disagreement between the table listed in section 2.3 and RFC 6890 (which maps to the IANA registry: https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml). Why does the table in 2.3 *try* to aggregate the entries? It appears that the attempt to aggregate has led to entries being omitted. For example: * The table in 2.3 says that link-local addresses fall under the 0::/8 range. They don't. Link-local addresses are in the FE80::/10 range. * The table says 0::/8 covers the site-local address range, but it doesn't. Additionally, site-local addresses are deprecated and not included in the IANA registry. * There is no mention of the registration added by RFC 6052. * There is no mention of the registration added by RFC 4193. For clarity and correctness, I would recommend copying the registry verbatim in the document. The same goes for the IPv4 special addresses in section 2.2 as well.
... but modulo the need to tidy up the IANA text as proposed by Barry.
like some others teetering on the brink of discuss: > However, the 16-bit AS numbers are really just zero through 65535 of the 32-bit AS number space. they are, but really implementation wise they fill the least signficant 16 bits. which is why the silly dot notation existed.
I'm curious: given the file-name, was this proposed to and rejected by appsawg? As a personal comment, I don't think its at all a good plan to introduce yet more linkages between personal identifiers which is precisely what this does. But that's for the ISE to judge I guess. I'm also not quite sure whether or not this draft does what's called for in the security considerations of draft-ietf-appsawg-acct-uri. But that's also for the ISE to judge. I'm pretty sure this draft does not define the security considerations fully, but I'm not sure if this draft counts as a protocol making "use" of acct URIs. (Were it up to me, I'd say yes it is, and that the security considerations ought be more thorough.) In addition, protocols that make use of 'acct' URIs are responsible for defining security considerations related to such usage, e.g., the risks involved in dereferencing an 'acct' URI, the authentication and authorization methods that could be used to control access to personal data associated with a user's account at a service, and methods for ensuring the confidentiality of such information. I also note that 6117 says: However, in some cases, the inclusion of those protocols and URI Schemes into ENUM specifically could introduce new security issues. In these cases, those issues or risks MUST be covered in the "Security Considerations" section of the Enumservice Specification. Authors should pay particular attention to any indirect risks that are associated with a proposed Enumservice, including cases where the proposed Enumservice could lead to the discovery or disclosure of Personally Identifiable Information (PII). If someone were to ask me, I'd say that this draft doesn't fully cover that, but again that's for the ISE and relevant designated expert to decide.