RE: Last Call:draft-betts-itu-oam-ach-code-point-03.txt (Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC
Having thought about this for some time, I think I concur with Russ' reasoning and the allocation should be made. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Russ Housley Sent: Freitag, 2. März 2012 00:52 To: Sprecher, Nurit (NSN - IL/Hod HaSharon) Cc: IETF Subject: Re: Last Call:draft-betts-itu-oam-ach-code-point-03.txt (Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC Nurit: Some people are using the lack of a code point as the reason that the cannot support the ITU-T document. My approach tells the ITU-T that a code point is available to them IFF they are able to reach consensus. The removes IETF from the discussion. This creates a situation where G.8113.1 succeeded or fails based on the ITU-T members actions, with no finger pointing at the IETF. This is completely a Layer 9 consideration, and it has noting to do with the technical content of the document. Russ On Mar 1, 2012, at 2:33 PM, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote: Russ, I propose to simply re-discuss it when and IFF G.8113.1 is mature and approved... Best regards, Nurit -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Russ Housley Sent: Thursday, March 01, 2012 9:12 PM To: IETF Subject: Re: Last Call:draft-betts-itu-oam-ach-code-point-03.txt (Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC Right now, there is no ITU-T approved document to reference. I am certainly not an expert on ITU-T process, but my understanding is that earliest that we could see an approved G.8113.1 is December 2012. My point is that we don't want to assign a code point until the ITU-T approves their document. However, if we are willing to assign a code point to G.8113.1 once it is approved, then this would be an approach where the code point assignment would block on the approval of the normative reference. I like this approach from the political point of view. With this approach the IETF tells the ITU-T that if and only if they are able to achieve consensus on G.8113.1, then a code point will be assigned. FWIW, this seems entirely appropriate to me. If we do it this way, I think it is important to note --for the benefit of those more historically involved with the ITU and others-- that we routinely block our own documents on normative references to work that is still in progress and, usually, do not do related code point allocations until the blocking referenced documents are ready. Once the present I-D is judged to be sufficiently ready, this approach would therefore be IETF approval and a formal guarantee to the ITU that a code point will be allocated if an when G.8113.1 is approved and published, but not assignment of that code point until the referenced base document is finished. Completely normal procedurally. To be clear John our normal requirement would be that the technical community achieved consensus that the base document was ready. I have never seen ITU-T consensus on the contents of G.8113.1 at any meeting that I have observed. What in your view is the criteria for determining that G.8113.1 has achieved consensus? This is not an IETF problem, and I do not think that the IETF ought to be discussing the internal workings of the ITU-T process. The point is to come up with a mechanism that allows the code point to be assigned if and only if the ITU-T does come to a consensus by whatever means is allowed by their own process. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
How does the IETF put a big red warning sign on a document produced by another standards body? http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-07. Actual coloring of course is impossible. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Hi, This is good input and made me realize what I disliked in the document which made me oppose to its publication. People (rightfully) pressed on the significance of the document to be about a general principle - one solution to any given problem. The IETF, _without_ external help, has a history of going down this road. Nobody stood up to stop that. Nobody wrote such a document then. Why now? Turf war, not invented here syndrome? I think it doesn't really matter. What would make my opposition go away is if we could write a more general document in which we point our own failings in the past, take this current issue into consideration and make it clear - in general - that the IETF is committed to follow this general principle more strictly in the future. _That_ would be a useful document and one which I would support. And it would be good if we could have such kind of pushback for multiple solutions in the future. WG chairs can take this document, show it to their WG and say Guy s, this is a guiding IETF principle. Get your act together and come up with a single solution. We will not have two or more.. Just ranting about this particular case is not helpful with all the multi-solutions we have created ourselves. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Stephen Kent Sent: Montag, 10. Oktober 2011 21:41 To: ietf@ietf.org Subject: Re: Last Call draft-sprecher-mpls-tp-oam-considerations- 01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC I support this doc, and concur with Stewart's comments. Contrary to what some have suggested, we sometimes (ofttimes?) have more than one standard for no good technical reason. Sometimes very large, competing companies back different standards for parochial reasons, to the detriment of consumers, service providers, etc. This appears to be one of those cases. Moreover, not opposing a two-standard approach sends a bad message, and encourages similar, bad behavior in the future. As the co-chair of PKIX, which has two standards for cert management (CMC and CMP), for exactly the bad reasons I cite above, I am intimately familiar with this sort of problem. I failed, in my role as PKIX co-chair, to prevent this in that WG. Let's not repeat that sort of mistake here. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Ross, See inline. This is not actually correct. The IETF has a very long history of pushing back on multiple redundant solutions to the same problem. There are a great many cases of ADs, working group chairs, and others pushing quite hard to prevent multiple solutions when one would work fine. I didn't mean to say that the IETF in general allows multiple solutions but I think it is accurate to say that the IETF has a less than 100% success rate of preventing multiple solutions. In the very many previous cases it was not necessary to write a document because the second (or third, or ...) solution was within the same standards body, and it was possible to either prevent publication, or publish the second solution as informational, or publish the second solution with a disclaimer up front saying some form of we recommend this other solution [add normative reference] which is the agreed IETF standard. You are making a point on which I picked earlier because it is stated in the document as well. In case there are multiple solutions, documenting, but at the same time discouraging the other one has happened before. Why is this not possible in this case? Make one the default, the other optional with a big red warning sign. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Dave, could you be more precise about what you think the utility of this document is in this particular situation. I mean, what will its effect be in the current situation. What will change after this document has been published. It seems everybody believes the situation will be resolved once this document receives its RFC number. I cannot see that. Could you give me more detail? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of David Allan I Sent: Donnerstag, 6. Oktober 2011 01:05 To: ietf@ietf.org; m...@ietf.org Subject: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam- considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC I think it is unfortunate that we are in a situation where such a document has utility. But ultimately it does. Therefore I support the publication of draft-sprecher... D MPLS Working Group, Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship. This draft is clearly close and relevant to the work you do, but after discussing with the chairs I came to the conclusion that it does not comment on the technical or process decisions of the MPLS working groups, and it does not attempt to make any technical evaluations or definitions within the scope of the MPLS working group. It is more of a philosophical analysis of the way the IETF approaches the two solutions problem with special reference to MPLS-TP OAM. Thus, I am accepting the document as AD Sponsored rather than running it through the MPLS working group. My reasoning is that the working group has got plenty to do working on technical issues without being diverted into wider IETF philosophy. As an AD Sponsored I-D it is subject to a four week IETF last call. That is plenty of opportunity for everyone to comment and express their views. Please send your comments to the IETF mailing list as described below, or (in exceptional circumstances) direct to the IESG. Thanks, Adrian ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Hi Loa, Let me answer with a counter-question. If the sole purpose of this document is to stop the development of two OAM solutions, do you think this RFC-to-be will achieve that? Seriously? The problem I see here is that we start a habit of writing politically motivated documents. We have this issue documented already all over the place in the form of minutes, web sites, press releases etc. I think this is enough and the right place. Let the I* and liaisons figure this out so that we all can go back to protocol design and development. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: Loa Andersson [mailto:l...@pi.nu] Sent: Mittwoch, 5. Oktober 2011 12:48 To: ietf@ietf.org; Rolf Winter Subject: Re: Last Call: draft-sprecher-mpls-tp-oam-considerations- 01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Rolf, are you saying that if we just liaise RFC1958 to the ITU-T they will stop developing a competing OAM for MPLS? Sometimes the life is simple, though I doubt that it is this simple. My 2c's is that this a good draft and should be progressed. /Lao On 2011-10-04 11:16, Rolf Winter wrote: Hi, I think Brian makes an excellent point here. RFC 1958 already contains exactly the same basic message (just with far less (unnecessary) words). I don't think we need this document as it doesn't really add anything to what RFC 1958 says. I'll provide a more detailed review later. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Freitag, 30. September 2011 21:48 To: huubatw...@gmail.com Cc: ietf@ietf.org Subject: Re: Last Call:draft-sprecher-mpls-tp-oam-considerations- 01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Huub, On 2011-09-30 20:19, Huub van Helvoort wrote: All, Section 1,1 also contains the text: [RFC5317] includes the analysis that it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. This is a quote from slide 113 in the PDF version of RFC5317 and should be read in realtion to the statement on slide 12 of the same RFC: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the *agreed upon starting point* for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements So the quoted text in the draft is one of the assumptions. The fact that there are currently *two* OAM mechanisms (and not a *single*), i.e. one for PW and one for LSP proves that the assumption was not correct. I'm sorry, I don't understand your logic. You seem to be saying that the fact that two solutions have been designed proves that the assumption that a single solution is possible was false. That doesn't follow at all. The engineering profession has a long history of producing multiple solutions where a single one was possible, and this seems to be just another such case. This isn't news. I quote from RFC 1958 (June 1996): 3.2 If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Hi Loa, There actually are some nuggets in the document but you have to look hard for them. E.g. section 4.2 analyzes TDM PWs and states that even within the IETF the exact same situation has arisen before, and three solutions have been specified. However, the IETF made one of them the default solution, so at least there is a baseline type to use and interoperability is guaranteed. If the IETF has gone down that particular path, then I don't see a reason why we cannot do the same thing again (yes, yes I know it is not optimal, I wish life was simple but I was recently convinced of the opposite). The document makes another good point in this regard: the party that is not using the default needs to bear all the cost (operational and such) which is a good point to make. This whole situation right now feels like some sort of attrition warfare and I don't think it is efficient use of our time. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: Loa Andersson [mailto:l...@pi.nu] Sent: Mittwoch, 5. Oktober 2011 13:51 To: Rolf Winter Cc: ietf@ietf.org Subject: Re: Last Call: draft-sprecher-mpls-tp-oam-considerations- 01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Rolf, I don't remember saying the sole purpose, the IETF way is to document requirements, specifications, processes and agreements in RFCs; this is just another document in this tradition. ANd as such a very good document. /Loa On 2011-10-05 13:31, Rolf Winter wrote: Hi Loa, Let me answer with a counter-question. If the sole purpose of this document is to stop the development of two OAM solutions, do you think this RFC-to-be will achieve that? Seriously? The problem I see here is that we start a habit of writing politically motivated documents. We have this issue documented already all over the place in the form of minutes, web sites, press releases etc. I think this is enough and the right place. Let the I* and liaisons figure this out so that we all can go back to protocol design and development. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: Loa Andersson [mailto:l...@pi.nu] Sent: Mittwoch, 5. Oktober 2011 12:48 To: ietf@ietf.org; Rolf Winter Subject: Re: Last Call:draft-sprecher-mpls-tp-oam-considerations- 01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Rolf, are you saying that if we just liaise RFC1958 to the ITU-T they will stop developing a competing OAM for MPLS? Sometimes the life is simple, though I doubt that it is this simple. My 2c's is that this a good draft and should be progressed. /Lao On 2011-10-04 11:16, Rolf Winter wrote: Hi, I think Brian makes an excellent point here. RFC 1958 already contains exactly the same basic message (just with far less (unnecessary) words). I don't think we need this document as it doesn't really add anything to what RFC 1958 says. I'll provide a more detailed review later. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Freitag, 30. September 2011 21:48 To: huubatw...@gmail.com Cc: ietf@ietf.org Subject: Re: Last Call:draft-sprecher-mpls-tp-oam-considerations- 01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Huub, On 2011-09-30 20:19, Huub van Helvoort wrote: All, Section 1,1 also contains the text: [RFC5317] includes the analysis that it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. This is a quote from slide 113 in the PDF version of RFC5317 and should be read in realtion to the statement on slide 12 of the same RFC: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the *agreed upon starting point* for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements So the quoted text in the draft is one of the assumptions. The fact that there are currently *two* OAM mechanisms (and not a *single*), i.e. one for PW and one for LSP proves that the assumption was not correct. I'm sorry, I don't understand your logic. You seem
RE: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Hi, Here's the review I promised earlier. I still think it would be best to not publish the draft for the reasons I mentioned earlier. In case the IETF wants to move this document forward I think at least a number of things need to change: a) The document makes a number of assertions that I think are not correct. E.g. it states that the solutions must be implementable in software. I cannot recall that there was any assertion about whether some, all or none of the things that the requirements documents prescribe should be build in HW or SW. A vendor needs to build equipment that fulfills the requirements, the standard needs to specify mechanisms that fulfill the requirements. If a vendor can build it in SW fine, if it has to be done in HW fine. But the main point is that everything needs to fulfill the specs which fulfill the requirements. b) The complexity sausage needs to go. The section does not help the goal of the document or the relevant parts are duplicated later in the text. c) Some text passages are overly dramatic and could use a little down-toning (e.g. (something that would inevitably drive all customers away!)). Others use absolute figures for speculative things (like increases cost by a factor of two etc.). Yet others are not very polite to certain vendors like forces all serious router vendors to implement both protocols. I am not sure the IETF wants to call router vendors to be not serious if they only implement either OSPF or ISIS. The basic message is the text needs a serious cleanup of language. d) Section 6 needs to go. I do not think that these coexistence models are agreed by the wider IETF community and I don't think they help the message of the document. e) The document should provide more references for some of the statements that caused dispute on the list. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Rolf Winter Sent: Dienstag, 4. Oktober 2011 11:17 To: Brian E Carpenter; huubatw...@gmail.com Cc: ietf@ietf.org Subject: RE: Last Call: draft-sprecher-mpls-tp-oam-considerations- 01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Hi, I think Brian makes an excellent point here. RFC 1958 already contains exactly the same basic message (just with far less (unnecessary) words). I don't think we need this document as it doesn't really add anything to what RFC 1958 says. I'll provide a more detailed review later. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Freitag, 30. September 2011 21:48 To: huubatw...@gmail.com Cc: ietf@ietf.org Subject: Re: Last Call: draft-sprecher-mpls-tp-oam-considerations- 01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Huub, On 2011-09-30 20:19, Huub van Helvoort wrote: All, Section 1,1 also contains the text: [RFC5317] includes the analysis that it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. This is a quote from slide 113 in the PDF version of RFC5317 and should be read in realtion to the statement on slide 12 of the same RFC: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the *agreed upon starting point* for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements So the quoted text in the draft is one of the assumptions. The fact that there are currently *two* OAM mechanisms (and not a *single*), i.e. one for PW and one for LSP proves that the assumption was not correct. I'm sorry, I don't understand your logic. You seem to be saying that the fact that two solutions have been designed proves that the assumption that a single solution is possible was false. That doesn't follow at all. The engineering profession has a long history of producing multiple solutions where a single one was possible, and this seems to be just another such case. This isn't news. I quote from RFC 1958 (June 1996): 3.2 If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good
RE: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Hi, I think Brian makes an excellent point here. RFC 1958 already contains exactly the same basic message (just with far less (unnecessary) words). I don't think we need this document as it doesn't really add anything to what RFC 1958 says. I'll provide a more detailed review later. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Freitag, 30. September 2011 21:48 To: huubatw...@gmail.com Cc: ietf@ietf.org Subject: Re: Last Call: draft-sprecher-mpls-tp-oam-considerations- 01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Huub, On 2011-09-30 20:19, Huub van Helvoort wrote: All, Section 1,1 also contains the text: [RFC5317] includes the analysis that it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. This is a quote from slide 113 in the PDF version of RFC5317 and should be read in realtion to the statement on slide 12 of the same RFC: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the *agreed upon starting point* for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements So the quoted text in the draft is one of the assumptions. The fact that there are currently *two* OAM mechanisms (and not a *single*), i.e. one for PW and one for LSP proves that the assumption was not correct. I'm sorry, I don't understand your logic. You seem to be saying that the fact that two solutions have been designed proves that the assumption that a single solution is possible was false. That doesn't follow at all. The engineering profession has a long history of producing multiple solutions where a single one was possible, and this seems to be just another such case. This isn't news. I quote from RFC 1958 (June 1996): 3.2 If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLS On-demand Connectivity Verification and Route Tracing) to Proposed Standard
Hi, I have made this comment before, I just want to make sure it is not lost. This draft is proposing a way to specify the length of sub-TLVs that is inconsistent with RFC 4379. I believe it would be better to align this with 4379 as the draft is updating it and I see no technical reason why this should be done differently from 4379. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The IESG Sent: Donnerstag, 11. August 2011 15:46 To: IETF-Announce Cc: m...@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLS On-demand Connectivity Verification and Route Tracing) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS On-demand Connectivity Verification and Route Tracing' draft-ietf-mpls-tp-on-demand-cv-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-08-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Label Switched Path Ping (LSP-Ping) is an existing and widely deployed Operations, Administration and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). This document describes extensions to LSP-Ping so that LSP- Ping can be used for On-demand Connectivity Verification of MPLS Transport Profile (MPLS-TP) LSPs and Pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP-Ping to perform Connectivity Verification and Route Tracing functions in MPLS-TP networks. Finally this document updates RFC 4379 by adding a new address type and requesting an IANA registry. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ No IPR declarations have been submitted directly on this I-D. ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
tsv-dir review of draft-ietf-pwe3-fat-pw-06
Hello, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. Generally, this is a well written document. This draft is basically ready for publication, but has a few nits the authors might consider before publication. And here go my comments. First a few on the content but most are purely editorial. CONTENT: Section 3 says: If a flow LSE is present, it MUST be checked to determine whether it carries a reserved label. If it is a reserved label the packet is processed according to the rules associated with that reserved label, otherwise the LSE is discarded. However section 1.2 states: Note that the flow label MUST NOT be an MPLS reserved label. Isn't that a contradiction to a certain extend. I mean, if there is a reserved label in the flow LSE, isn't that an error and should not be processed? section 8.4: The second bullet in the section under: The issues described above are mitigated by the following two factors:. I wonder whether that isn't a bit farfetched. I mean, in principle you suggest that customers could change e.g. the way their applications behave to let the ingress PE to be able to better apply the flow label. That sounds like asking a customer to change something on their application end to have a better network connectivity. section 8.5. Isn't a bigger problem here that you cannot guarantee that the OAM packets follow the same ECMP path and that violates the fate sharing requirement? section 12: You essentially say that the behaviour of IP packets are well defined regarding congestion and nothing needs to be done. Other payload needs to be dealt with by PW congestion avoidance (whatever that means). So IP packets that are not reacting to congestion (such as UDP) are no concern but other packets with the same behaviour are? Is that a correct reading of the text? EDITORIAL: Abstract: Remove the END at the end. Intro: page 3. first para: s/equipments[RFC4385]/equipments [RFC4385]/ page 3. first para: s/times )/times)/ page 3. fourth para: s/the type PW/the type of PW/ page 3. fourth para: s/[RFC5286] ./[RFC5286]./ section 1.2: page 5. first para: s/which knows flow LSE/which knows a flow LSE/ section 2: s/identify flows/identifies flows/ section 4: page 7: s/is unable process/is unable to process/ section 4.1: page 8: s/(seeSection 11 )/(see Section 11)/ page 8: s/T= 0/T=0/ section 7: s/Ingress and Egress PE's/ingress and egress PEs/ section 8.1: page 12: s/past[I-D.stein-pwe3-pwbonding]/past [I-D.stein-pwe3-pwbonding]/ section 8.3: page 12: s/An example of such a case is the of the/An example of such a case is the one of the/ or /An example of such a case is the/ section 8.4: Option one says: The operator can choose to do nothing and the system will work as it does without the flow label. Isn't this option to not use the flow label. If so a better wording would maybe be: The operator can choose to do nothing, i.e. to not employ the flow label Option 3: 2/flows,/flows./ Why is section 9 not section 8.7? I mean it is concerned with applicability which is what section 8 is about. section 9: s/This is can be regarded as/This can be regarded as/ section 10: s/be will preceded/be preceded/ section 12: s/multiple ECMP/multiple ECMPs/ Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
tsv-dir review of draft-ietf-netconf-4741bis-07
Hi,
I've reviewed this document as part of the transport area directorate's ongoing
effort to review key IETF documents. These comments were written primarily for
the transport area directors, but are copied to the document's authors for
their information and to allow them to address any issues raised. The authors
should consider this review together with any other last-call comments they
receive. Please always CC tsv-...@ietf.org if you reply to or forward this
review.
This draft is basically ready for publication, but has nits that should be
fixed before publication. There are no transport-related concerns that I could
spot.
Some nits:
Section 2.1: second paragraph (below), second sentence doesn't parse quite
right for me. Especially as the following sentence seems to imply the opposite.
I read this as The client can change things that cannot be changed
-- NETCONF connections are long-lived, persisting between protocol
operations. This allows the client to make changes to the state of
the connection that will persist for the lifetime of the connection.
For example, authentication information specified for a connection
remains in effect until the connection is closed.
You have Authentication in titles twice (in 2.2 and 2.3). Can do without in
2.2 as you dedicate a whole section on it.
Section 2.2. NETCONF connections must is not a MUST. Is this intentional
(BTW, you don't mention integrity in the security considerations section any
more).
NETCONF transport protocols therefore MUST explain how a NETCONF username is
derived from the authentication mechanisms supported by the transport
protocol. I read this as every transport protocol that NETCONF can run over
(SSH e.g.) needs to specify this, but I think this is not what you require or
even can ask for. But maybe I misunderstand the sentence.
Regarding this error:
enum operation-failed {
description
Request could not be completed because the requested
operation failed for some reason not covered by
any other error condition.;
}
This is send if the XML is not well formed. Maybe you could dedicate a message
to this that makes trouble shooting a little easier such as XML-format-error
or something.
That's about it.
Best,
Rolf
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3
6BL | Registered in England 2832014
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
tsv-dir review of draft-baker-ietf-core-11
Hi, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. Generally, the document is well written and the following are suggestions to improve the document. There is no show stopper in the document itself but I feel it is sometimes a bit unbalanced regarding detail, explanation and recommendation of the various protocols presented. I hope these comments are helpful. General observations: You lack a definition of what the Smart Grid is. You clearly write the document for Smart Grid folks (they should know what Smart Grid is) but is there a generally accepted definition of what the Smart Grid consists of, what the requirements are, what the technological assumptions are etc? If there is such a document then you should reference it, otherwise you should state in the document what you think the Smart Grid is and why these Smart Grid folks need this document. This would also explain why you have included certain things and left other things out (which is something I couldn't tell from the document). As an example, in Section 2.3 you write While the following protocols are not critical to the design of a specific system, they are important to running a network, and as such are surveyed here. What is the relevance to Smart Grid? Why is only DNS and Network Management mentioned? Having text that explains what the Smart Grid is makes it much easier to understand why you included these specific things in the document. Section 2.2.: I am not a security expert but I find either the title of the section wrong or the list not quite right. So the section is about authentication and a requirement is the protection of the channel against DoS. I believe that is not part of authentication. The same applies to integrity. Maybe you just want to refer to some of the RFC 4949 definitions here? Generally, I find the security section less coherent than the preceding sections. Section 2.3: I think you conflate confidentiality and privacy here (but again, please check with a sec person). I am also not sure what you want to express with the last sentence. (Or how it would work in practice). Section 4: I don't see much value in this section. At least, it is not well titled as is mainly talks about firewalls and NATs. Also, if you decide to keep the section, you might want to change the examples to something less real by using RFC 5737 IP addresses. Other technologies: could delay tolerant networking be of interest. After all, the Core charter says that devices may be off at any time. Nits: Section 2.1: s/While Internet architecture/While the Internet architecture/ Section 2.1: move (ISO-OSI) to come right after Interconnect Section 2.1: s/host /host/ Section 2.1: s/internet gateway/Internet gateway/ Caption figure 1: s/ISO OSI/ISO-OSI/ (at least the rest of the text uses that spelling) Figure 2: You use slighlty different terminology from RFC 1122 and RFC 1812. Is that intentional? Section 2.1.2: s/to large extent/to a large extent/ Section 2.1.2: The session identification in an IP datagram is often called the five-tuple (I personally would use flow instead of session) Section 2.1.3: s/is the network that/is the network protocol that/ Section 2.1.3.1: s/network abstraction network/network abstraction/ Section 2.1.3.1: s/those protocol/those protocols/ Section 2.1.4: s/IPv4 and IPv6 various media types/IPv4 and IPv6 over various media types/ Section 3.1.2: s/Header (AH) [RFC4302]/Header (AH) [RFC4302],/ Section 3.2: s/since IPv4 free pool/since the IPv4 free pool/ Section 3.2.1.3: s/some networks site networks/some site networks/ Section 3.2.2: s/dropped../dropped./ Section 3.2.2.1: s/using Address Resolution Protocol/using the Address Resolution Protocol/ Section 2.2.2.2: You write: Active research exists in mobile ad hoc routing and other routing paradigms; these result in new protocols and modified forwarding paradigms. This (or a similar) statement applies to all other protocols that you mention in the document but you do not mention ongoing research. Why is this statement more relevant to routing v4? Section 3.2.4.3: expand CLNS Section 3.2.4.6: s/between device/between devices/ Section 3.2.5.1: s/A the highest/At the highest/ Section 3.2.5.1: s/SSM has inherent/SSM has an inherent/ Section 3.3: s/that built for/that were built for/ Section 3.3.1: s/properly not/probably not/ Section 3.4.3: s/The current versions of the time protocol are/The current version of the time protocol is/ Section 3.7.2: s/Representation
