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
All, Why section 5.1 is an author's impression: Statement: SONET and SDH were defined as competing standards Fact: SONET was developed first by ANSI based on the 24 channel PDH hierarchy existing in North America and Japan. The basic rate based on DS3. Some time later ETSI developed SDH based on the 30 channnel PDH deployed in Europe. The basic rate based on E4 (3x DS3). To be able to deploy SONET and SDH worldwide the regional SDO experts came together in ITU-T to define a frame structure and a frame-rate that would allow interconnection of SONET and SDH. A compromise was agreed and approved in an ITU-T meeting in Seoul in 1988. Statement: Significant confusion resulted from this situation. Fact: The result of the compromise is documented in ITU-T recommendation G.707 which includes the frame definition and frame-rates, and documents how SONET and SDH can interconnect. Statement: Equipment manufacturers needed to select the market segment they intended to address. The cost of chipsets for a limited market increased. Fact: Most equipment vendors did/do sell their equipment in both regions. I was involved in chip designs for SONET/SDH in several companies, they all support SONET and SDH in a single chip, and the selection is a matter of provisioning, the addition cost to support both was minimal (single chip: higher volume = lower cost) Statement: Service providers needed to consider the merits of the two standards and their long-term role in the industry when examining their investment options. Fact: Because the regions or applicability of SONET and SDH are well known SPs do not have to make this consideration. Statement: Only a limited number of equipment manufactures were available for selection. Question: What do you consider a limited number? Statement: As SONET was considered to be the variant, interworking had to be performed before the SDH-based segment was reached. Fact: SONET is *NOT* a variant it is equivalent to SDH. The reason for placing the interconnection functionality on the SONET side was that in a previous agreement on interconnection the functionality was placed on the European side. Conclusion: There is a single frame structure used by both SONET and SDH. This is documented in ITU-T recommendation G.707 (ANSI and ETSI still have their SONET resp. SDH standard available in their own documentation, but they are aligned with G.707). It depends on the application of the frame structure in an environment with 24 channel legacy PDH to call it SONET and in an evironment with 30 channel legacy PDH to call it SDH. The meeting in Seoul in 1988 shows that SDOs can compromise to find a common frame structure that can be used in different regions/applications. Best regards, Huub. ___ 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
At 12:42 26-09-2011, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM' draft-sprecher-mpls-tp-oam-considerations-01.txt as an Informational RFC 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-10-24. Exceptionally, comments may be Given that previous discussions about MPLS-TP raised a few controversies, I wondered what this document was about and why it wasn't a working group document. The document mentions that it is intended to explain why it would be unwise to standardize multiple solutions for MPLS-TP OAM. And the objective is to determine whether there is IETF Consensus for that. According the shepherd write-up, this document is an analysis of wider IETF policy and process. Could the document shepherd please clarify what he means by that? In Section 4.3: The application layer of the Internet is, however, predicated on a business model that allows for free or shared software (such as in open source developments), and is only possible with the existence of a royalty free codec. I cannot parse the above sentence. There were some arguments [1] from an IETF participant: The IETF should *NOT* document any comment on any multiple standards developed by other SDOs The IETF should refrain from documenting things that might offend other SDOs I could not find anything offensive. For example, Section 5.3 mentions that: Sometimes, customers were obliged to obtain an additional device from their service providers in order to roam when travelling abroad (for example, when travelling from Europe to the U.S). There is a cost when the user has to work around such issues. The IETF already has a policy about inter-SDO impact. Quoting Section 2.2 of RFC 4041: [The IETF] must allow for other moral frameworks and fully respect other people's right to subscribe to other belief systems. Such people are, however, wrong and doomed to spend eternity in a dark corner with only dial-up access. So it has been written. Regards, -sm 1. http://www.ietf.org/mail-archive/web/ietf/current/msg69674.html ___ 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
On Sep 29, 2011, at 1:06 AM, Huub van Helvoort wrote: All, I propose to completely remove section 5 of this draft. The reason: The IETF should *NOT* document any comment on any multiple standards developed by other SDOs which are outside of the IETF's scope. Especially standards like like SONET/SDH, CDMA/GSM. The current text reflects the author's impressions, and since I don't believe that the authors were involved in the debates when these standards were developed, they *DO NOT KNOW ENOUGH* to comment authoritatively on them. Isn't that why this draft is targeted as an *individual and informational* draft? Since that is the case, I don't see how your point is relevant to the document at hand. The IETF should refrain from documenting things that might offend other SDOs concerning standards issues in which IETF was or is not involved. That is your opinion. However, please observe that other SDOs document and cross-reference each others' works all the time often adding their 2 cents. For example, take what the BBF does with many IETF standards. --Tom Best regards, Huub. ___ 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
A few more thoughts on this thread. All, I propose to completely remove section 5 of this draft. The reason: The IETF should *NOT* document any comment on any multiple standards developed by other SDOs which are outside of the IETF's scope. Especially standards like like SONET/SDH, CDMA/GSM. The current text reflects the author's impressions, and since I don't believe that the authors were involved in the debates when these standards were developed, they *DO NOT KNOW ENOUGH* to comment authoritatively on them. Why do you suddenly think that it is important for only people with knowledge of a topic to contribute to standards? Where does that leave the ITU-T's input on MPLS? I can give you many examples of where people who had no qualification as experts in a particular field have contributed to standards, but I will refrain from doing so so as to not offend other SDOs as you say below. 8) The IETF should refrain from documenting things that might offend other SDOs concerning standards issues in which IETF was or is not involved. Since when does offending other SDOs become a concern of any other SDO? Along these lines, let us take the flip-side of that example you give and ask ourselves why the ITU-T's comments on MPLS do not offend IETF folks (or other SDOs for that matter) and why there was not a concern of offending when those were made? --Tom Best regards, Huub. ___ 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
On 09/29/2011 09:18 AM, Thomas Nadeau wrote: A few more thoughts on this thread. All, I propose to completely remove section 5 of this draft. The reason: The IETF should *NOT* document any comment on any multiple standards developed by other SDOs which are outside of the IETF's scope. Especially standards like like SONET/SDH, CDMA/GSM. The current text reflects the author's impressions, and since I don't believe that the authors were involved in the debates when these standards were developed, they *DO NOT KNOW ENOUGH* to comment authoritatively on them. Why do you suddenly think that it is important for only people with knowledge of a topic to contribute to standards? Where does that leave the ITU-T's input on MPLS? I can give you many examples of where people who had no qualification as experts in a particular field have contributed to standards, but I will refrain from doing so so as to not offend other SDOs as you say below. 8) I would say that having knowledge of a topic is a requirement, but that *expert* knowledge of a topic is not a requirement. Just look at the IETF mailing lists. There are plenty of people with something to say who do not to have expert knowledge of a topic. Almost certainly of us at one time or another. Sometimes new ideas come from looking at a problem without the preconceptions that come with being an expert. Sometimes experts really do know better. This is why we have discussions to build consensus as to which ideas should be kept or discarded. Both experts and nonexperts can have valuable contributions and improve each others understanding. -Andrew Not an expert on standards or even SONET/SDH, CDMA/GSM The IETF should refrain from documenting things that might offend other SDOs concerning standards issues in which IETF was or is not involved. Since when does offending other SDOs become a concern of any other SDO? Along these lines, let us take the flip-side of that example you give and ask ourselves why the ITU-T's comments on MPLS do not offend IETF folks (or other SDOs for that matter) and why there was not a concern of offending when those were made? --Tom Best regards, Huub. ___ 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 ___ 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
All, From my personal knowledge, the comments from Huub are accurate. (I was an active participant at the 1988 ITU meeting in Seoul where the SDH frame format was agreed). The IETF should not publish a consensus approved draft that contains inaccurate information about a standard that was developed outside the IETF. The gross inaccuracy in the characterization of SONET/SDH leads me to question the validity of the document. Regards, Malcolm Huub van Helvoort huubatw...@gmail.com Sent by: ietf-boun...@ietf.org 29/09/2011 02:00 AM Please respond to huubatw...@gmail.com To ietf@ietf.org cc 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 All, Why section 5.1 is an author's impression: Statement: SONET and SDH were defined as competing standards Fact: SONET was developed first by ANSI based on the 24 channel PDH hierarchy existing in North America and Japan. The basic rate based on DS3. Some time later ETSI developed SDH based on the 30 channnel PDH deployed in Europe. The basic rate based on E4 (3x DS3). To be able to deploy SONET and SDH worldwide the regional SDO experts came together in ITU-T to define a frame structure and a frame-rate that would allow interconnection of SONET and SDH. A compromise was agreed and approved in an ITU-T meeting in Seoul in 1988. Statement: Significant confusion resulted from this situation. Fact: The result of the compromise is documented in ITU-T recommendation G.707 which includes the frame definition and frame-rates, and documents how SONET and SDH can interconnect. Statement: Equipment manufacturers needed to select the market segment they intended to address. The cost of chipsets for a limited market increased. Fact: Most equipment vendors did/do sell their equipment in both regions. I was involved in chip designs for SONET/SDH in several companies, they all support SONET and SDH in a single chip, and the selection is a matter of provisioning, the addition cost to support both was minimal (single chip: higher volume = lower cost) Statement: Service providers needed to consider the merits of the two standards and their long-term role in the industry when examining their investment options. Fact: Because the regions or applicability of SONET and SDH are well known SPs do not have to make this consideration. Statement: Only a limited number of equipment manufactures were available for selection. Question: What do you consider a limited number? Statement: As SONET was considered to be the variant, interworking had to be performed before the SDH-based segment was reached. Fact: SONET is *NOT* a variant it is equivalent to SDH. The reason for placing the interconnection functionality on the SONET side was that in a previous agreement on interconnection the functionality was placed on the European side. Conclusion: There is a single frame structure used by both SONET and SDH. This is documented in ITU-T recommendation G.707 (ANSI and ETSI still have their SONET resp. SDH standard available in their own documentation, but they are aligned with G.707). It depends on the application of the frame structure in an environment with 24 channel legacy PDH to call it SONET and in an evironment with 30 channel legacy PDH to call it SDH. The meeting in Seoul in 1988 shows that SDOs can compromise to find a common frame structure that can be used in different regions/applications. Best regards, Huub. ___ 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
Tom, Please see in line below. Regards, Malcolm Thomas Nadeau tnad...@lucidvision.com Sent by: ietf-boun...@ietf.org 29/09/2011 07:48 AM To huubatw...@gmail.com cc The IESG iesg-secret...@ietf.org, ietf@ietf.org, IETF-Announce ietf-annou...@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 On Sep 29, 2011, at 1:06 AM, Huub van Helvoort wrote: All, I propose to completely remove section 5 of this draft. The reason: The IETF should *NOT* document any comment on any multiple standards developed by other SDOs which are outside of the IETF's scope. Especially standards like like SONET/SDH, CDMA/GSM. The current text reflects the author's impressions, and since I don't believe that the authors were involved in the debates when these standards were developed, they *DO NOT KNOW ENOUGH* to comment authoritatively on them. Isn't that why this draft is targeted as an *individual and informational* draft? Since that is the case, I don't see how your point is relevant to the document at hand. [MB] The last call is for consensus approval by the IETF so this draft, if published, will be the opinion of the IETF. Therefore the point raised by Huub is relevant. The IETF should refrain from documenting things that might offend other SDOs concerning standards issues in which IETF was or is not involved. That is your opinion. However, please observe that other SDOs document and cross-reference each others' works all the time often adding their 2 cents. For example, take what the BBF does with many IETF standards. [MB] Big difference between referencing the work of another SDO from a standard and issuing a standard that make inaccurate comments about a standard that was developed in another SDO. --Tom Best regards, Huub. ___ 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 ___ 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
Tom, Please see in line below. Regards, Malcolm Thomas Nadeau tnad...@lucidvision.com Sent by: ietf-boun...@ietf.org 29/09/2011 09:18 AM To huubatw...@gmail.com cc The IESG iesg-secret...@ietf.org, ietf@ietf.org, IETF-Announce ietf-annou...@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 A few more thoughts on this thread. All, I propose to completely remove section 5 of this draft. The reason: The IETF should *NOT* document any comment on any multiple standards developed by other SDOs which are outside of the IETF's scope. Especially standards like like SONET/SDH, CDMA/GSM. The current text reflects the author's impressions, and since I don't believe that the authors were involved in the debates when these standards were developed, they *DO NOT KNOW ENOUGH* to comment authoritatively on them. Why do you suddenly think that it is important for only people with knowledge of a topic to contribute to standards? Where does that leave the ITU-T's input on MPLS? I can give you many examples of where people who had no qualification as experts in a particular field have contributed to standards, but I will refrain from doing so so as to not offend other SDOs as you say below. 8) [MB] This individual draft is now in IETF last call. At this stage it should represent the opinion of those who are experts in the field. Clearly during the development of a draft all interested participants, expert or not, should provide input. Best regards, Huub. ___ 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 ___ 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
All, First, let me say I have no absolutely desire to enter into debate into the substantive matter of this draft. If the purpose of the draft is to be 'Informational' then the reader would have a reasonable expectation for the information to be correct, especially if it is referencing matters beyond its immediate scope. And the section 5.1 is simply factually wrong. Huub's comments on SONET/SDH give an accurate critique. If the authors did want to make meaningful reference to where two separate standards emerged, then the primary rates (T1 and E1), their associated voice coding (mu-law and A-law), and PDH multiplexing hierarchies might be a more meaningful place to start. With a great deal of hard work and good will on all sides, SONET/SDH achieved an single effective standard bridging these two largely incompatible worlds. Andy From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of malcolm.be...@zte.com.cn Sent: 29 September 2011 16:10 To: huubatw...@gmail.com Cc: ietf-boun...@ietf.org; 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 All, From my personal knowledge, the comments from Huub are accurate. (I was an active participant at the 1988 ITU meeting in Seoul where the SDH frame format was agreed). The IETF should not publish a consensus approved draft that contains inaccurate information about a standard that was developed outside the IETF. The gross inaccuracy in the characterization of SONET/SDH leads me to question the validity of the document. Regards, Malcolm Huub van Helvoort huubatw...@gmail.commailto:huubatw...@gmail.com Sent by: ietf-boun...@ietf.orgmailto:ietf-boun...@ietf.org 29/09/2011 02:00 AM Please respond to huubatw...@gmail.commailto:huubatw...@gmail.com To ietf@ietf.orgmailto:ietf@ietf.org cc 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 All, Why section 5.1 is an author's impression: Statement: SONET and SDH were defined as competing standards Fact: SONET was developed first by ANSI based on the 24 channel PDH hierarchy existing in North America and Japan. The basic rate based on DS3. Some time later ETSI developed SDH based on the 30 channnel PDH deployed in Europe. The basic rate based on E4 (3x DS3). To be able to deploy SONET and SDH worldwide the regional SDO experts came together in ITU-T to define a frame structure and a frame-rate that would allow interconnection of SONET and SDH. A compromise was agreed and approved in an ITU-T meeting in Seoul in 1988. Statement: Significant confusion resulted from this situation. Fact: The result of the compromise is documented in ITU-T recommendation G.707 which includes the frame definition and frame-rates, and documents how SONET and SDH can interconnect. Statement: Equipment manufacturers needed to select the market segment they intended to address. The cost of chipsets for a limited market increased. Fact: Most equipment vendors did/do sell their equipment in both regions. I was involved in chip designs for SONET/SDH in several companies, they all support SONET and SDH in a single chip, and the selection is a matter of provisioning, the addition cost to support both was minimal (single chip: higher volume = lower cost) Statement: Service providers needed to consider the merits of the two standards and their long-term role in the industry when examining their investment options. Fact: Because the regions or applicability of SONET and SDH are well known SPs do not have to make this consideration. Statement: Only a limited number of equipment manufactures were available for selection. Question: What do you consider a limited number? Statement: As SONET was considered to be the variant, interworking had to be performed before the SDH-based segment was reached. Fact: SONET is *NOT* a variant it is equivalent to SDH. The reason for placing the interconnection functionality on the SONET side was that in a previous agreement on interconnection the functionality was placed on the European side. Conclusion: There is a single frame structure used by both SONET and SDH. This is documented in ITU-T recommendation G.707 (ANSI and ETSI still have their SONET resp. SDH standard available in their own documentation, but they are aligned with G.707). It depends on the application of the frame structure in an environment with 24 channel legacy PDH to call it SONET and in an evironment with 30 channel legacy PDH to call it SDH. The meeting in Seoul in 1988 shows that SDOs can compromise to find a common frame structure that can be used in different regions/applications. Best regards, Huub. ___ Ietf mailing list Ietf@ietf.orgmailto: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
Dear all, As also being one of the participants directly involved in the SONET/SDH standardization process from its inception, I would like to echo Andy's sentiments. Best regards, Eve From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of andy.bd.r...@bt.com Sent: Thursday, September 29, 2011 11:37 AM To: malcolm.be...@zte.com.cn; huubatw...@gmail.com Cc: ietf-boun...@ietf.org; 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 All, First, let me say I have no absolutely desire to enter into debate into the substantive matter of this draft. If the purpose of the draft is to be 'Informational' then the reader would have a reasonable expectation for the information to be correct, especially if it is referencing matters beyond its immediate scope. And the section 5.1 is simply factually wrong. Huub's comments on SONET/SDH give an accurate critique. If the authors did want to make meaningful reference to where two separate standards emerged, then the primary rates (T1 and E1), their associated voice coding (mu-law and A-law), and PDH multiplexing hierarchies might be a more meaningful place to start. With a great deal of hard work and good will on all sides, SONET/SDH achieved an single effective standard bridging these two largely incompatible worlds. Andy From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of malcolm.be...@zte.com.cn Sent: 29 September 2011 16:10 To: huubatw...@gmail.com Cc: ietf-boun...@ietf.org; 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 All, From my personal knowledge, the comments from Huub are accurate. (I was an active participant at the 1988 ITU meeting in Seoul where the SDH frame format was agreed). The IETF should not publish a consensus approved draft that contains inaccurate information about a standard that was developed outside the IETF. The gross inaccuracy in the characterization of SONET/SDH leads me to question the validity of the document. Regards, Malcolm Huub van Helvoort huubatw...@gmail.commailto:huubatw...@gmail.com Sent by: ietf-boun...@ietf.orgmailto:ietf-boun...@ietf.org 29/09/2011 02:00 AM Please respond to huubatw...@gmail.commailto:huubatw...@gmail.com To ietf@ietf.orgmailto:ietf@ietf.org cc 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 All, Why section 5.1 is an author's impression: Statement: SONET and SDH were defined as competing standards Fact: SONET was developed first by ANSI based on the 24 channel PDH hierarchy existing in North America and Japan. The basic rate based on DS3. Some time later ETSI developed SDH based on the 30 channnel PDH deployed in Europe. The basic rate based on E4 (3x DS3). To be able to deploy SONET and SDH worldwide the regional SDO experts came together in ITU-T to define a frame structure and a frame-rate that would allow interconnection of SONET and SDH. A compromise was agreed and approved in an ITU-T meeting in Seoul in 1988. Statement: Significant confusion resulted from this situation. Fact: The result of the compromise is documented in ITU-T recommendation G.707 which includes the frame definition and frame-rates, and documents how SONET and SDH can interconnect. Statement: Equipment manufacturers needed to select the market segment they intended to address. The cost of chipsets for a limited market increased. Fact: Most equipment vendors did/do sell their equipment in both regions. I was involved in chip designs for SONET/SDH in several companies, they all support SONET and SDH in a single chip, and the selection is a matter of provisioning, the addition cost to support both was minimal (single chip: higher volume = lower cost) Statement: Service providers needed to consider the merits of the two standards and their long-term role in the industry when examining their investment options. Fact: Because the regions or applicability of SONET and SDH are well known SPs do not have to make this consideration. Statement: Only a limited number of equipment manufactures were available for selection. Question: What do you consider a limited number? Statement: As SONET was considered to be the variant, interworking had to be performed before the SDH-based segment was reached. Fact: SONET is *NOT* a variant it is equivalent to SDH. The reason for placing the interconnection functionality on the SONET side was that in a previous agreement on interconnection the functionality was placed on the European side. Conclusion: There is a single frame structure used by both SONET and SDH. This is documented in ITU-T recommendation G.707 (ANSI and
RE: [BEHAVE] ... Dual Stack Hosts Using Bump-in-the-Host (BIH))
-Original Message- From: Rémi Després [mailto:remi.desp...@free.fr] Sent: Thursday, September 29, 2011 5:14 AM To: Softwires-wg Cc: Dan Wing; Teemu Savolainen; Satoru Matsushima; IETF discussion list; Behave WG Subject: Re: [BEHAVE] ... Dual Stack Hosts Using Bump-in-the-Host (BIH)) Hi all, Le 27 sept. 2011 à 21:10, Dan Wing a écrit : -Original Message- From: teemu.savolai...@nokia.com [mailto:teemu.savolai...@nokia.com] ... I mean does existing applications work better if double translation is done in deterministic manner? Yes, it allows the CPE to implement an ALG -- if an application needs an ALG (e.g., active-mode FTP). +1 As Softwire is concerned, it is worth noting here that, with encapsulation rather than double translation, NO ALG is ever needed. (Neither in ISP Border Relay nodes, nor in CPEs, nor in BIH hosts). Do a message flow for active mode FTP with 4rd. I did one, and it needs an ALG in the 4rd NAPT44 function. -d It is sometimes argued that double translation could be as simple than encapsulation. AFAIK, this discussion clearly indicates the contrary. (No ALGs eliminates any variants about where to put them.) RD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
Hello Dan, Can you run an FTP server on the BIH host, and have it do active mode transfers and passive mode transfers? Could you elaborate the scenario? You assume BIH host taking FTP sever. I'm not sure whether following scenarios are correct There are two possibilities Option 1: +---+ |BIH(FTP sever) |--NAT64---FTP Client +---+ Option 2: +---+ |BIH(FTP sever) |--FTP Client +---+ In the case of Option 1, it can't work since NAT64 couldn't support IPv4 initiated session In the case of Option 2, it could work if BIH do ALG BTW, if BIH takes the role of FTP client, I guess it works in both active and passive mode when NAT64 do ALG If there is something wrong, please correct me Many thanks Gang ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] ... Dual Stack Hosts Using Bump-in-the-Host (BIH))
-Original Message- From: Rémi Després [mailto:remi.desp...@free.fr] Sent: Thursday, September 29, 2011 3:13 AM To: Dan Wing Cc: 'Softwires-wg'; 'Behave WG'; 'IETF discussion list'; 'Teemu Savolainen' Subject: Re: [BEHAVE] ... Dual Stack Hosts Using Bump-in-the-Host (BIH)) Le 29 sept. 2011 à 23:50, Dan Wing a écrit : -Original Message- From: Rémi Després [mailto:remi.desp...@free.fr] Sent: Thursday, September 29, 2011 5:14 AM To: Softwires-wg Cc: Dan Wing; Teemu Savolainen; Satoru Matsushima; IETF discussion list; Behave WG Subject: Re: [BEHAVE] ... Dual Stack Hosts Using Bump-in-the-Host (BIH)) Hi all, Le 27 sept. 2011 à 21:10, Dan Wing a écrit : -Original Message- From: teemu.savolai...@nokia.com [mailto:teemu.savolai...@nokia.com] ... I mean does existing applications work better if double translation is done in deterministic manner? Yes, it allows the CPE to implement an ALG -- if an application needs an ALG (e.g., active-mode FTP). +1 As Softwire is concerned, it is worth noting here that, with encapsulation rather than double translation, NO ALG is ever needed. (Neither in ISP Border Relay nodes, nor in CPEs, nor in BIH hosts). Do a message flow for active mode FTP with 4rd. Two cases (which I din't differentiate, sorry for that). a) The hosts handles 4rd b) The host is behind a NAT44 ( In case b), an ALG is needed as usual, as the CPE-NAT44 does its usual job for that. Case a) was assumed to apply to this discussion, considering a host that is directly the 4rd CE. I did one, and it needs an ALG in the 4rd NAPT44 function. In case a), the host can assign to an FTP application a pair of ports of its assigned range. Thus no translation is needed (e2e transparency). OK? If BIH worked that way, BIH would fail when the host has multiple interfaces running, and those interfaces have different port ranges. -d RD -d It is sometimes argued that double translation could be as simple than encapsulation. AFAIK, this discussion clearly indicates the contrary. (No ALGs eliminates any variants about where to put them.) RD ___ 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: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
-Original Message- From: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] On Behalf Of GangChen Sent: Thursday, September 29, 2011 9:09 AM To: Dan Wing Cc: Hui Deng; beh...@ietf.org; ietf@ietf.org; softwi...@ietf.org; Cameron Byrne Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard Hello Dan, Can you run an FTP server on the BIH host, and have it do active mode transfers and passive mode transfers? Could you elaborate the scenario? The FTP server, using BIH, is an IPv4-only FTP server. It needs to listen on port 21 (the FTP control port), although if a URI is used to access the FTP server, an alternate control port can work alright (ftp://ftp.example.com:12345). For a passive-mode transfer, the FTP server only needs to know the PASV command (because that is all that's necessary for an IPv4 FTP server; IPv4 FTP servers don't need to support EPSV and many on the Internet do not support EPSV). Also for a passive-mode transfer, the FTP client needs to initiate the TCP connections to a port on the FTP server. For an active-mode transfer, the FTP server connects back to the client, using the IPv4 address indicated in the FTP control channel. You assume BIH host taking FTP sever. I'm not sure whether following scenarios are correct There are two possibilities Option 1: +---+ |BIH(FTP sever) |--NAT64---FTP Client +---+ Option 2: +---+ |BIH(FTP sever) |--FTP Client +---+ In the case of Option 1, it can't work since NAT64 couldn't support IPv4 initiated session I agree it would fail with a passive-mode transfer. But it should work with an active-mode transfer. In the case of Option 2, it could work if BIH do ALG Yep. BTW, if BIH takes the role of FTP client, I guess it works in both active and passive mode when NAT64 do ALG If there is something wrong, please correct me -d Many thanks Gang ___ Behave mailing list beh...@ietf.org https://www.ietf.org/mailman/listinfo/behave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Softwires] [BEHAVE] ... Dual Stack Hosts Using Bump-in-the-Host (BIH))
If a host has several interfaces, each interface must have its own private IPv4 address (case b) at this interface), or its own IPv4 address, possibly with a restricted port set (case a)). The host must handle ports according to what applies to its chosen interface. Agreed. But it's not the host, rather it is the application running on the host that needs to have that awareness. Said another way, it cannot mindlessly bind to port 0, like applications do today -- but has to bind to a free port on a specific interface. This isn't AFAIK specific of 4rd scenarios. It is a problem common to all of the port-restricted scenarios if we move the port restriction into the host (A+P, 4rd, dIVI). Either the application is aware of the port restriction (which is how you avoid an ALG in the host) and require the application to change, or the application is unaware of the port restriction (which means an ALG is necessary, for some applications, in the host) but the application doesn't have to change. So -- which way is the architecture going to go? I have not seen this written down anywhere. -d ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] [Softwires] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
On Thu, Sep 29, 2011 at 9:46 AM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Hi Cameron, If the application itself delivers an IPv4 literal via protocols like MSN or Skype, there is a path and socket made available, that is what this NAT46 code does. Is there a dependency on the existence of IPv4 literal so as to use the v4-interface provided by NAT46 code? IOW, does every IP-only app work now on n900? Cheers, Rajiv No, not all apps will work due to ALG dependencies associated with NAT in general. If the app does not work via NAT, it still will not work. What this code provides is the ability for IPv4-only apps on IPv6-only networks to work using their normal NAT traversal techniques + IPv4 literals .. this includes, Skype, MSN, and the ability to type http://x.x.x.x into your browser. There is no panacea, except making the apps and services IPv6 native on IPv6 native networks, everything else is a hack and time to market is important ipv4 exhausted. Cameron -Original Message- From: Cameron Byrne [mailto:cb.li...@gmail.com] Sent: Wednesday, September 28, 2011 3:14 PM To: Rajiv Asati (rajiva) Cc: Mark Townsley; Hui Deng; Softwires-wg list; Behave WG; IETF Discussion; Dan Wing (dwing) Subject: Re: [BEHAVE] [Softwires] Last Call: draft-ietf-behave-v4v6-bih- 06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard On Wed, Sep 28, 2011 at 11:20 AM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Hi Cameron, Very interesting ( clever indeed). How does this clever code ensure that all but a few (pesky apps) continue to use IPv6 interface instead of the NAT46 interface? Rajiv, DNS64 is used. So anything that can take a will use a and the native IPv6 path, with or without NAT64 -- as needed. If the application itself delivers an IPv4 literal via protocols like MSN or Skype, there is a path and socket made available, that is what this NAT46 code does. As i mentioned before, i don't like this. But, i respect that it works and it solves a real problem for users of these ipv4-only apps. I personally find it easy to live with only IP version agnostic apps that work well in an IPv6-only NAT64/DNS64 network. I have been eating this dog food for over 18 months. I am happy to let the market and eco-system punish apps for not supporting IPv6, and for the market to reward apps that do support IPv6. I believe draft-ietf-behave-v4v6-bih-06 has too narrow of a scope to be useful since it explicitly does NOT support IPv4-only apps talking to IPv4 servers over an IPv6-only network Cameron Cheers, Rajiv -Original Message- From: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] On Behalf Of Cameron Byrne Sent: Wednesday, September 28, 2011 2:12 PM To: Mark Townsley Cc: Hui Deng; Softwires-wg list; Behave WG; IETF Discussion; Dan Wing (dwing) Subject: Re: [BEHAVE] [Softwires] Last Call: draft-ietf-behave-v4v6-bih- 06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard On Wed, Sep 28, 2011 at 9:26 AM, Mark Townsley m...@townsley.net wrote: +1 ... since the alternative is that apps that require ipv4 sockets and pass ipv4 literals are stranded on ipv6 only networks. Running code on the n900 shows that nat464 provides real user and network benefit Frankly, I preferred it when you were running IPv6-only without BIH on your trial, providing pressure to get rid of all those stranded literals and pushing apps to open ipv6 sockets :-/ - Mark We're still doing that, and IPv6-only is still my philosophical preference and that is how we are launching the IPv6 + NAT64/DNS64 service into the production mobile network (real soon now). No change in that path. But some power users wanted their IPv4-only applications like Skype to work so they coded a NAT46 work-around for the N900. It is clever, it works. Their process of feeling the pain of a very few pesky IPv4-only apps and working around it is all documented here: http://talk.maemo.org/showthread.php?t=60320 Running NAT46 code here: http://code.google.com/p/n900ipv6/wiki/Nat64D In the end (as well as IPv6-only near term in mobile), IP version agnostic apps will prove to be more reliable and therefore will get more market share. Cameron ___ Behave mailing list beh...@ietf.org https://www.ietf.org/mailman/listinfo/behave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] [Softwires] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
Hi Cameron, Very interesting ( clever indeed). How does this clever code ensure that all but a few (pesky apps) continue to use IPv6 interface instead of the NAT46 interface? Cheers, Rajiv -Original Message- From: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] On Behalf Of Cameron Byrne Sent: Wednesday, September 28, 2011 2:12 PM To: Mark Townsley Cc: Hui Deng; Softwires-wg list; Behave WG; IETF Discussion; Dan Wing (dwing) Subject: Re: [BEHAVE] [Softwires] Last Call: draft-ietf-behave-v4v6-bih- 06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard On Wed, Sep 28, 2011 at 9:26 AM, Mark Townsley m...@townsley.net wrote: +1 ... since the alternative is that apps that require ipv4 sockets and pass ipv4 literals are stranded on ipv6 only networks. Running code on the n900 shows that nat464 provides real user and network benefit Frankly, I preferred it when you were running IPv6-only without BIH on your trial, providing pressure to get rid of all those stranded literals and pushing apps to open ipv6 sockets :-/ - Mark We're still doing that, and IPv6-only is still my philosophical preference and that is how we are launching the IPv6 + NAT64/DNS64 service into the production mobile network (real soon now). No change in that path. But some power users wanted their IPv4-only applications like Skype to work so they coded a NAT46 work-around for the N900. It is clever, it works. Their process of feeling the pain of a very few pesky IPv4-only apps and working around it is all documented here: http://talk.maemo.org/showthread.php?t=60320 Running NAT46 code here: http://code.google.com/p/n900ipv6/wiki/Nat64D In the end (as well as IPv6-only near term in mobile), IP version agnostic apps will prove to be more reliable and therefore will get more market share. Cameron ___ Behave mailing list beh...@ietf.org https://www.ietf.org/mailman/listinfo/behave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Softwires] [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
On Sep 28, 2011, at 8:12 PM, Cameron Byrne wrote: On Wed, Sep 28, 2011 at 9:26 AM, Mark Townsley m...@townsley.net wrote: +1 ... since the alternative is that apps that require ipv4 sockets and pass ipv4 literals are stranded on ipv6 only networks. Running code on the n900 shows that nat464 provides real user and network benefit Frankly, I preferred it when you were running IPv6-only without BIH on your trial, providing pressure to get rid of all those stranded literals and pushing apps to open ipv6 sockets :-/ - Mark We're still doing that, and IPv6-only is still my philosophical preference and that is how we are launching the IPv6 + NAT64/DNS64 service into the production mobile network (real soon now). No change in that path. But some power users wanted their IPv4-only applications like Skype to work so they coded a NAT46 work-around for the N900. It is clever, it works. Ah, so it's not a model developed and (necessarily) supported by you. Thanks for the clarification. Yes, it makes sense that this would end up happening as the hosts evolve to what the network provides. - Mark Their process of feeling the pain of a very few pesky IPv4-only apps and working around it is all documented here: http://talk.maemo.org/showthread.php?t=60320 Running NAT46 code here: http://code.google.com/p/n900ipv6/wiki/Nat64D In the end (as well as IPv6-only near term in mobile), IP version agnostic apps will prove to be more reliable and therefore will get more market share. Cameron ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
Le 28 sept. 2011 à 23:16, Cameron Byrne a écrit : ... It can't determine the public IP address and port of a mapping on the NAT64 (CGN), and it can't create a mapping on the NAT64 (CGN) -- because the CGN is going to make a dynamic mapping when it sees a UDP, TCP, or ICMP packet from the subscriber. I don't see it matters +1 ... since the alternative is that apps that require ipv4 sockets and pass ipv4 literals are stranded on ipv6 only networks. Running code on the n900 shows that nat464 provides real user and network benefit So far so good as result of an experiment, is per se a positive result, but it doesn't prove that there won't be problems in the future. Running-code validation tests cannot be a reason to stop analyzing where problems might be likely to appear. Regards, RD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-drinks-usecases-requirements-06
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-drinks-usecases-requirements-06 Reviewer: Roni Even Review Date: 2011-9-29 IETF LC End Date: 2011-10-3 IESG Telechat date: Summary: This draft is ready for publication as an informational RFC. Major issues: Minor issues: Nits/editorial comments: ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] [Softwires] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
Hi Cameron, If the application itself delivers an IPv4 literal via protocols like MSN or Skype, there is a path and socket made available, that is what this NAT46 code does. Is there a dependency on the existence of IPv4 literal so as to use the v4-interface provided by NAT46 code? IOW, does every IP-only app work now on n900? Cheers, Rajiv -Original Message- From: Cameron Byrne [mailto:cb.li...@gmail.com] Sent: Wednesday, September 28, 2011 3:14 PM To: Rajiv Asati (rajiva) Cc: Mark Townsley; Hui Deng; Softwires-wg list; Behave WG; IETF Discussion; Dan Wing (dwing) Subject: Re: [BEHAVE] [Softwires] Last Call: draft-ietf-behave-v4v6-bih- 06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard On Wed, Sep 28, 2011 at 11:20 AM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Hi Cameron, Very interesting ( clever indeed). How does this clever code ensure that all but a few (pesky apps) continue to use IPv6 interface instead of the NAT46 interface? Rajiv, DNS64 is used. So anything that can take a will use a and the native IPv6 path, with or without NAT64 -- as needed. If the application itself delivers an IPv4 literal via protocols like MSN or Skype, there is a path and socket made available, that is what this NAT46 code does. As i mentioned before, i don't like this. But, i respect that it works and it solves a real problem for users of these ipv4-only apps. I personally find it easy to live with only IP version agnostic apps that work well in an IPv6-only NAT64/DNS64 network. I have been eating this dog food for over 18 months. I am happy to let the market and eco-system punish apps for not supporting IPv6, and for the market to reward apps that do support IPv6. I believe draft-ietf-behave-v4v6-bih-06 has too narrow of a scope to be useful since it explicitly does NOT support IPv4-only apps talking to IPv4 servers over an IPv6-only network Cameron Cheers, Rajiv -Original Message- From: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] On Behalf Of Cameron Byrne Sent: Wednesday, September 28, 2011 2:12 PM To: Mark Townsley Cc: Hui Deng; Softwires-wg list; Behave WG; IETF Discussion; Dan Wing (dwing) Subject: Re: [BEHAVE] [Softwires] Last Call: draft-ietf-behave-v4v6-bih- 06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard On Wed, Sep 28, 2011 at 9:26 AM, Mark Townsley m...@townsley.net wrote: +1 ... since the alternative is that apps that require ipv4 sockets and pass ipv4 literals are stranded on ipv6 only networks. Running code on the n900 shows that nat464 provides real user and network benefit Frankly, I preferred it when you were running IPv6-only without BIH on your trial, providing pressure to get rid of all those stranded literals and pushing apps to open ipv6 sockets :-/ - Mark We're still doing that, and IPv6-only is still my philosophical preference and that is how we are launching the IPv6 + NAT64/DNS64 service into the production mobile network (real soon now). No change in that path. But some power users wanted their IPv4-only applications like Skype to work so they coded a NAT46 work-around for the N900. It is clever, it works. Their process of feeling the pain of a very few pesky IPv4-only apps and working around it is all documented here: http://talk.maemo.org/showthread.php?t=60320 Running NAT46 code here: http://code.google.com/p/n900ipv6/wiki/Nat64D In the end (as well as IPv6-only near term in mobile), IP version agnostic apps will prove to be more reliable and therefore will get more market share. Cameron ___ Behave mailing list beh...@ietf.org https://www.ietf.org/mailman/listinfo/behave ___ 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
I'm having a hard time understanding just what this document is trying to do I understand from the title that it is supposed to be telling the reader why a single OAM solution is a good idea for MPLS-TP if that is the case I'm not all that sure what the purpose of sections 4 and 5 are for - they seem to be exploring land outside the reservation - how about just addressing the topic in the title? Scott ___ 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
Scott, On 2011-09-30 05:30, Scott O Bradner wrote: I'm having a hard time understanding just what this document is trying to do I understand from the title that it is supposed to be telling the reader why a single OAM solution is a good idea for MPLS-TP if that is the case I'm not all that sure what the purpose of sections 4 and 5 are for - they seem to be exploring land outside the reservation - how about just addressing the topic in the title? That goes a bit further than my own suggestion of moving them to an Appendix, but they are indeed off the main track of the argument. You're probably right; it would be more succinct and equally powerful without them. I think we all know that competing standards are a bad thing, without having to get the historical details of SDH vs SONET right. Whatever good work was done to fix the SDH/SONET case, the fact is that users were seriously inconvenienced, exactly as they were earlier by the difference between E1 and T1. [Anecdote about the first T1 link carrying IP across the Atlantic deleted.] Brian ___ 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
On Sep 29, 2011, at 3:52 PM, Brian E Carpenter wrote: Scott, On 2011-09-30 05:30, Scott O Bradner wrote: I'm having a hard time understanding just what this document is trying to do I understand from the title that it is supposed to be telling the reader why a single OAM solution is a good idea for MPLS-TP if that is the case I'm not all that sure what the purpose of sections 4 and 5 are for - they seem to be exploring land outside the reservation - how about just addressing the topic in the title? That goes a bit further than my own suggestion of moving them to an Appendix, but they are indeed off the main track of the argument. You're probably right; it would be more succinct and equally powerful without them. I personally liked your idea of moving to an appendix. That keeps them in black and white and in a place that can be referenced. --Tom I think we all know that competing standards are a bad thing, without having to get the historical details of SDH vs SONET right. Whatever good work was done to fix the SDH/SONET case, the fact is that users were seriously inconvenienced, exactly as they were earlier by the difference between E1 and T1. [Anecdote about the first T1 link carrying IP across the Atlantic deleted.] 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
Weekly posting summary for ietf@ietf.org
Total of 142 messages in the last 7 days. script run at: Fri Sep 30 00:53:02 EDT 2011 Messages | Bytes| Who +--++--+ 6.34% |9 | 7.42% | 108321 | cb.li...@gmail.com 7.04% | 10 | 5.92% |86425 | dw...@cisco.com 6.34% |9 | 6.50% |94984 | mo...@network-heretics.com 4.93% |7 | 6.23% |90963 | wesley.geo...@twcable.com 2.82% |4 | 4.97% |72658 | denghu...@gmail.com 2.82% |4 | 4.35% |63582 | teemu.savolai...@nokia.com 0.70% |1 | 5.89% |86092 | bill...@huawei.com 3.52% |5 | 2.61% |38089 | brian.e.carpen...@gmail.com 3.52% |5 | 2.61% |38073 | bob.hin...@gmail.com 1.41% |2 | 4.50% |65720 | even.r...@huawei.com 3.52% |5 | 2.31% |33742 | john-i...@jck.com 3.52% |5 | 2.28% |33238 | s...@resistor.net 2.82% |4 | 2.57% |37554 | y...@checkpoint.com 2.82% |4 | 2.50% |36493 | bschl...@cisco.com 2.11% |3 | 2.55% |37272 | malcolm.be...@zte.com.cn 2.11% |3 | 2.12% |30952 | raj...@cisco.com 0.70% |1 | 3.21% |46902 | eve.va...@alcatel-lucent.com 2.11% |3 | 1.68% |24544 | joe...@bogus.com 2.11% |3 | 1.23% |18021 | tnad...@lucidvision.com 2.11% |3 | 1.23% |17941 | iljit...@muada.com 2.11% |3 | 1.19% |17443 | alexey.melni...@isode.com 1.41% |2 | 1.67% |24393 | huit...@microsoft.com 1.41% |2 | 1.52% |22132 | o...@delong.com 1.41% |2 | 1.06% |15451 | daedu...@btconnect.com 0.70% |1 | 1.69% |24616 | andy.bd.r...@bt.com 1.41% |2 | 0.94% |13742 | huubatw...@gmail.com 1.41% |2 | 0.94% |13728 | rog...@gmail.com 1.41% |2 | 0.93% |13511 | chesh...@apple.com 1.41% |2 | 0.84% |12268 | mo...@necom830.hpcl.titech.ac.jp 1.41% |2 | 0.83% |12178 | hmdmhdfmhdjmzdtjmzdtzktdkzt...@gmail.com 1.41% |2 | 0.82% |11904 | m...@townsley.net 1.41% |2 | 0.81% |11790 | do...@dougbarton.us 1.41% |2 | 0.69% |10128 | paul.hoff...@vpnc.org 0.70% |1 | 1.10% |16003 | th...@sfc.wide.ad.jp 0.70% |1 | 0.88% |12886 | les...@thinkingcat.com 0.70% |1 | 0.77% |11236 | em...@jitsi.org 0.70% |1 | 0.72% |10579 | jma...@gmail.com 0.70% |1 | 0.69% |10026 | o...@nlnetlabs.nl 0.70% |1 | 0.64% | 9420 | nar...@us.ibm.com 0.70% |1 | 0.60% | 8700 | marla.azin...@ftr.com 0.70% |1 | 0.55% | 8067 | to...@isi.edu 0.70% |1 | 0.51% | 7464 | david.bl...@emc.com 0.70% |1 | 0.50% | 7324 | despres.r...@free.fr 0.70% |1 | 0.49% | 7102 | clint.chap...@gmail.com 0.70% |1 | 0.48% | 7030 | rbon...@juniper.net 0.70% |1 | 0.47% | 6802 | andr...@plixer.com 0.70% |1 | 0.43% | 6297 | m...@sabahattin-gucukoglu.com 0.70% |1 | 0.43% | 6271 | m...@sap.com 0.70% |1 | 0.43% | 6216 | hous...@vigilsec.com 0.70% |1 | 0.40% | 5770 | phdg...@gmail.com 0.70% |1 | 0.39% | 5758 | st...@shinkuro.com 0.70% |1 | 0.39% | 5730 | hen...@levkowetz.com 0.70% |1 | 0.38% | 5516 | do...@mail-abuse.org 0.70% |1 | 0.38% | 5510 | jonat...@vidyo.com 0.70% |1 | 0.37% | 5477 | jo...@iecc.com 0.70% |1 | 0.36% | 5286 | n...@guppylake.com 0.70% |1 | 0.36% | 5228 | jari.ar...@piuha.net 0.70% |1 | 0.35% | 5112 | barryle...@computer.org 0.70% |1 | 0.34% | 4898 | s...@sobco.com +--++--+ 100.00% | 142 |100.00% | 1460558 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
Best is no ALG. Worse is one ALG. Even worse is two ALGs. -d OK, I have see that there is two solutions for just one ALG. -Hui ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
inline please, +1 ... since the alternative is that apps that require ipv4 sockets and pass ipv4 literals are stranded on ipv6 only networks. Running code on the n900 shows that nat464 provides real user and network benefit Can you run an FTP server on the BIH host, and have it do active mode transfers and passive mode transfers? I admit that isn't terribly important (nobody much loves FTP any more), but if the BIH host doesn't know its public mapping and can't create one, we lose that class of applications that listen on a port. Losing that class of applications may, or may not, be important. Many of those applications do STUN or STUN-/ICE-like things for their own NAT traversal (e.g., Skype). But some don't and work properly without a hole punched (e.g., BitTorrent). PCP can make all of this work, if it's integrated into BIH and the NAT64. -d You are jumping into another discussion how to reach from outside, There has other way to do it ,not just BIH+NAT64. Hui ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-cuss-sip-uui-reqs-06.txt (Problem Statement and Requirements for Transporting User to User Call Control Information in SIP) to Informational RFC
The IESG has received a request from the Call Control UUI Service for SIP WG (cuss) to consider the following document: - 'Problem Statement and Requirements for Transporting User to User Call Control Information in SIP' draft-ietf-cuss-sip-uui-reqs-06.txt as an Informational RFC 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 i...@ietf.org mailing lists by 2011-10-13. 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 This document introduces the transport of call control related User to User Information (UUI) using the Session Initiation Protocol (SIP), and develops several requirements for a new SIP mechanism. Some SIP sessions are established by or related to a non-SIP application. This application may have information that needs to be transported between the SIP User Agents during session establishment. In addition to interworking with the ISDN UUI Service, this extension will also be used for native SIP endpoints requiring application UUI. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-reqs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-reqs/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'MPLS On-demand Connectivity Verification and Route Tracing' to Proposed Standard (draft-ietf-mpls-tp-on-demand-cv-07.txt)
The IESG has approved the following document: - 'MPLS On-demand Connectivity Verification and Route Tracing' (draft-ietf-mpls-tp-on-demand-cv-07.txt) as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ Technical Summary 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. Working Group Summary This document is a MPLS working group document, and part of the joint IETF and ITU.T MPLS-TP project. It has been reviewed in both organizations and there is a solid support for the document. There is a good consensus around this draft, it has passed the call to verify that LC comments were correctly addressed with only minor comments. Document Quality The document is well reviewed in the MPLS working group and ITU-T SG15. Multiple vendors have indicated their intention to implement. Personnel Loa Andersson (l...@li.nu) is the Document Shepherd Adrian Farrel (adr...@olddog.co.uk) is the Responsible AD ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
New Non-WG Mailing List: dcon -- Distributed Conferencing BOF discussion list
A new IETF non-working group email list has been created. List address: d...@ietf.org Archive: http://www.ietf.org/mail-archive/web/dcon/ To subscribe: https://www.ietf.org/mailman/listinfo/dcon Purpose: This list is for discussions relating to the potential setup of a new IETF working group devoted to Distributed Conferencing. For additional information, please contact the list administrators. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
New Non-WG Mailing List: nvo3 -- L2 Network Virtualization Over l3 overlay discussion list (nvo3)
A new IETF non-working group email list has been created. List address: n...@ietf.org Archive: http://www.ietf.org/mail-archive/web/nvo3/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/nvo3 Purpose: This list is to discuss potential IETF work related to providing L2 network virtualization service over an L3 overlay network. For additional information, please contact the list administrators. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
