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
Hello Russ, You write: RFC 5317 calls for one, and only one, protocol solution. At least that is how I read JWT Agreement. How the JWT report should be read is written on slide 9 in the PDF: 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 The most relevant text seems to be in Section 9: This text is one of the assumptions, that is why we wrote: *They stated that in their view*: 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. The OAM technology in this text refers to to way the OAM frames can be detected in a data-stream. The text you quote is from the summary section, it summarizes the slides 19 - 22: *MPLS-TP Major Solution Constructs* which address the GAL-GAch solution. We now have the GAL-GAch technology (RFC5586) to detect OAM frames and this technology will be used in PW and LSP, and enables the use of OAM in deeply nested networks. Since the publication of RFC 5317, the MPLS WG consensus continues to be that only one OAM solution should become a standard. All MPLS-TP OAM tools should comply with RFC5586. A service provider can now pick any set or sub-set of the available OAM tools and use them without fear to disrupt the internet. Looking at the current discussions, there is no consensus (yet) on whether we need a comprehensive set of OAM tools, or a very limited set of OAM tools. Best regards, Huub (JWT, Ad-Hoc, MEAD member). ___ 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
Hello Russ, You wrote: although the SONET discussion could be discarded. It is not only the SDH/SONET discussion that should be removed. I have very strong doubts about all the issues mentioned in sections 4 and 5, none of them are factual. 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
All, I still do not support this draft. Section 6 focusses on the interworking between two toolsets In transport networks we *never* have peer-2-peer OAM interworking. If it was required it would have explicitly been mentioned in the MPLS-TP requirements RFC. Why don't you simply read draft-tsb-mpls-tp-ach-ptn or Annex B of G.8110.1 where it is documented how different toolsets can be deployed in a network without any issues. Section 6 is totally irrelevant. 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
Huub, I agree. Regards, Malcolm Huub van Helvoort huubatw...@gmail.com Sent by: ietf-boun...@ietf.org 09/10/2011 07:42 AM Please respond to huubatw...@gmail.com To IETF Discussion 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, I still do not support this draft. Section 6 focusses on the interworking between two toolsets In transport networks we *never* have peer-2-peer OAM interworking. If it was required it would have explicitly been mentioned in the MPLS-TP requirements RFC. Why don't you simply read draft-tsb-mpls-tp-ach-ptn or Annex B of G.8110.1 where it is documented how different toolsets can be deployed in a network without any issues. Section 6 is totally irrelevant. 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
Russ, You may not be fully aware of the context of the statement in RFC 5317: As the co-chair of the JTW and co-editor of the JWT report I must point out the context of the text that you have quoted: First, the text is on slide 113, slide 12 states: 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 Second: The discussion point that drove the text on slide 113 was the consideration that PWs and LSPs may have different OAM. The reality is that the solution standardized uses different encapsulations for the PW (no GAL) and LSP (uses the GAL). Regards, Malcolm Russ Housley hous...@vigilsec.com Sent by: ietf-boun...@ietf.org 08/10/2011 11:02 AM To IETF 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 I support publication of this draft, although the SONET discussion could be discarded. Also, I would like to see a reference to RFC 5921 in the introduction. RFC 5317 calls for one, and only one, protocol solution. At least that is how I read JWT Agreement. The most relevant text seems to be in Section 9: They stated that in their view, 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. Since the publication of RFC 5317, the MPLS WG consensus continues to be that only one OAM solution should become a standard. Russ On Oct 5, 2011, at 11:02 PM, Rui Costa wrote: c) To the question which requirement stated in the RFCs are not satisfied by the singe OAM solution defined in IETF?: For instance, RFC5860 2.2.3: The protocol solution(s) developed to perform this function proactively MUST also apply to [...] point-to-point unidirectional LSPs, and point-to- multipoint LSPs. ___ 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
how to make Apple Mail comply to email standards: or vv?
I've just received an important email from an important person (a former IETF chair even) on an IETF mailing list. The content-type was: Content-Type: text/plain; charset=us-ascii yet the first line of the mail was 491 characters wide. There is an expectation that format=flowed; is now implied. Has the YAM WG taken this into consideration? Will a new standard now make make format=flowed; standard? I'm really really really tired of this. I never expected redmond to do the right thing, but at least everyone with a clue knew that they did the wrong thing, and some versions of that system there was even settings that mostly did the right thing. Meanwhile a colleague of mine in the non-IT space is complaining that he can't read email that I send because his Apple Mail program seems to forceably reformat all text, assuming it is format=flowed; RFC2646 has been around for 11 years now. So my request is simple: 1) can the IETF secretariat please document appropriate settings for commodity mail user agents that comply with RFC2464, and configure our mailing list software to filter anything that does not comply? I'm serious about this. It's embarassing. 2) alternatively, will the YAM (or another WG) please update the standard to say that format=flowed is now the default, and ideally also give me some idea if format=fixed will do anything at all with MUAs out there? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. pgpfFzxNPQ7hv.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: watersprings.org archive of expired Internet Drafts
Fred == Fred Baker f...@cisco.com writes:
Fred To make my own mirror of such on my laptop, I rsync -avz
Fred rsync.tools.ietf.org::tools.id /Users/fred/all-drafts/id
I further sort the IDs by author... and since I forget to unlink them, I
wind up with an archive. I don't think consider_linking_rfc works anymore.
#!/usr/bin/perl
chdir('/corp/ietf');
if(@ARGV == 0) {
system(/corp/ietf/newRFCs.sh);
system(rsync -avz optimus.ietf.org::internet-drafts
ftp.ietf.org/internet-drafts);
system(cd html.charters; wget -r -l 1 -nv -np -nd -nc
http://www.ietf.org/html.charters/;);
} else {
print SKIPPING RSYNC (@ARGV) \n;
}
opendir(DRAFTS,ftp.ietf.org/internet-drafts);
@drafts=readdir(DRAFTS);
closedir(DRAFTS);
sub consider_linking_rfc {
local($dir, $draft) = @_;
open(DRAFT, $draft) || warn can not open $draft: $!\n;
#print Searching $draft\n;
my $line=0;
while(DRAFT) {
#while(DRAFT) {
last if ($line 9);
#print line: $line $_;
chop;
#This Internet-Draft was published as a Proposed Standard, RFC 3664
if(/This Internet\-Draft was published .*RFC (\d+)/) {
$rfc=$1;
print rfc$rfc - $dir/rfc$rfc.txt\n;
link(ftp.ietf.org/rfc/rfc$rfc.txt, $dir/rfc$rfc.txt);
#unlink($draft);
close(DRAFT);
return;
}
$line++;
}
close(DRAFT);
}
foreach $draft (@drafts) {
next if ($draft =~ /^\./);
$draft =~ m,draft-([^-]*)-([^-]*)-(.*),;
if($1 eq ietf) {
$dir = id/$1/$2;
$base= $3;
} else {
$dir = id/$1;
$base =$2-$3;
}
next if (length($base) 1);
next if (-f $dir/$base);
print $draft - $dir/$base\n;
system(mkdir -p $dir) unless (-d $dir);
link(ftp.ietf.org/internet-drafts/$draft,$dir/$base);
consider_linking_rfc($dir, $dir/$base);
}
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: how to make Apple Mail comply to email standards: or vv?
I've just received an important email from an important person (a former IETF chair even) on an IETF mailing list. The content-type was: Content-Type: text/plain; charset=us-ascii yet the first line of the mail was 491 characters wide. ... which is legal according to the relevant standards. There are legitimate uses for fixed format messages with long lines, which is why the 78 character wrap limit is a SHOULD, not a MUST. Of course in the case you present the line should have been wraped. But that's a user agent quality issue, albeit a fairly common one. There is an expectation that format=flowed; is now implied. That particular wrongminded expectation has been with us in one form or another for almost 20 years - it became a real problem shortly after MIME was published, as a matter of fact. There have been many attempts to address it, including the relatively recent definition of the format=flowed label. Has the YAM WG taken this into consideration? Of course it hasn't. Read the charter. YAM has a single purpose: The Yet Another Mail (YAM) WG will revise existing Internet Mail specifications currently at Draft Standard to advance them to Full Standard. Even if there was a consensus to make format=flowed the default (and I've seen no sign of any such thing), YAM couldn't do it. You know, that whole pesky no significant changes when moving from draft to full thing? Will a new standard now make make format=flowed; standard? Seems unlikely. I'm really really really tired of this. I never expected redmond to do the right thing, but at least everyone with a clue knew that they did the wrong thing, and some versions of that system there was even settings that mostly did the right thing. Meanwhile a colleague of mine in the non-IT space is complaining that he can't read email that I send because his Apple Mail program seems to forceably reformat all text, assuming it is format=flowed; RFC2646 has been around for 11 years now. So my request is simple: 1) can the IETF secretariat please document appropriate settings for commodity mail user agents that comply with RFC2464, and configure our mailing list software to filter anything that does not comply? I'm serious about this. It's embarassing. The first part seems reasonable, the second seems like a massive overreaction and IMNSHO has zero chance of being adopted. 2) alternatively, will the YAM (or another WG) please update the standard to say that format=flowed is now the default, and ideally also give me some idea if format=fixed will do anything at all with MUAs out there? Again, making such a major change to the default handling of the most comon type of email seems unlikely to be feasible at this stage. And besides, we've tried standards-making in this space quite a few times (simple text proposal, text/enriched, format=flowed, etc.) and nothing has worked. I see no reason to believe that further standards-making will do anything but further fragment the behavior of user agents. So perhaps it's time to try a different approach. Instead of writing yet another technical specification, write a best practices document that explains the problem and gives specific advice to user agent developers. This sort of thing has been conspicuous by its absence in previous documents. Just a thought. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
Thomas, 1) When we were developing the original draft-weil request for a /8, we estimated that the total aggregate demand for Shared CGN Space is about ~40 million addresses worldwide. A /8 would allow most ISPs to deploy CGNs without address overlap within their networks. As a compromise to the community, we changed our request to a /10 in Beijing. In our talks with a lot of service providers, a /10 is the smallest block that will allow for a regional CGN deployment for many service providers without nested CGNs (e.g. NAT). Also, draft-shirasaki-isp-shared-addr demonstrates a similar need, showing that a /10 was able to satisfy metropolitan areas in Japan. 2) Yes, Shared CGN Space breaks 6to4 (unless you use 6to4-PMT), but so does any non-RFC1918 space including squat space and public GUA in a CGN environment. We've tested it, and included this analysis in the latest 2 versions of the draft (-07 and -08). Based on our testing, 6to4 is the only application we've discovered that breaks specifically due to the address range between the CPE router and CGN (see draft-donley-nat444-impacts for other applications that are affected in a CGN environment). None of the ISPs I've spoken with are planning to use 1918 space behind the CGN, which leaves global unicast space, Shared CGN Space, and squat space. All three cause the same impact to 6to4, and of the three, Shared CGN Space offers the best hope of fixing it by agreeing on a common address range. Yes, it will take some time before router vendors include Shared CGN Space in their 6to4 code, but I believe that it's better than the alternatives, for which the only solution is 6to4-pmt. Chris -- Chris Donley CCIE, CISSP, SCiPM Project Director - Network Protocols CableLabs® 858 Coal Creek Circle Louisville, CO 80027 303-661-3480 (v) 303-661-9199 (f) On 9/30/11 5:14 PM, Thomas Narten nar...@us.ibm.com wrote: I read the document again today for the first time in a while and went through the more recent threads on the ietf list. I have 2 main comments. First, where did the /10 figure come from? Why not a /16? Some justification is needed for a particular figure. Second, this will break stuff, and even though the document talks about it some, we are dreaming IMO if we think talking about the problems (and encouraging implementations to fix things) will have any impact. At least not in the next few years. The problem will happen with stuff deployed today, or already in the pipeline for deployment. So, this will cause things to break. I don't feel good about that, even if one accepts the argument that neither approach is painless and we're gonna have breakage anyway. E.g., breaking 6to4 seems like a bad thing to do for IPv6. E.g.,: ingress links. DNS queries for Shared CGN Space addresses MUST NOT be forwarded to the global DNS infrastructure. This is done to avoid having to set up something similar to AS112.net for RFC 1918 private address space that a host has incorrectly sent for a DNS reverse- mapping queries on the public Internet [RFC6304]. This is totally unenforceable. We will be forced to deal with this. Existing software that is massively deployed will do this. Saying MUST NOT here is kind of like some IETF document saying you MUST NOT use NAT. When configured with a Shared CGN Space address (or other address range not described in [RFC5735]), such devices may attempt to initiate 6to4. Since 6to4 includes the WAN IPv4 address embedded in its IPv6 address, should 6to4 traffic traverse a CGN, return traffic could be misdirected and not reach the originating router. Service Providers can mitigate this issue using a technology such as 6to4-PMT [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel]. When the address range is well-defined, as with Shared CGN Space, home router vendors can include Shared CGN Space in their list of special-use addresses (e.g., [RFC5735]) and treat Shared CGN Space similarly to private [RFC1918] space. When the WAN address is not well-defined, as in the case of Globally Unique space, it will be more difficult for home router vendors to mitigate against this issue. This won't happen for a long time (if ever). so counting on this seems like a dream. Finally, what this document/reservation does is shift pain around. I.e., moving pain felt by one party (if nothing is done) to another party (if this is done). Are we unfairly pushing the pain to people (e.g., CPE routers) to help the ISPs? How do we decide or justify who deserves the pain? I'm pretty ambivalent about recommending this document. I don't like it and I don't like the precedent it sets, particularly in pushing pain from one party to another. I do understand what the document is trying to do. I think it will result in some small amount of sharing of space (thus slightly reducing demand for IPv4 addresses), which is arguably a good thing. But the amount of address space we are talking about
答复: 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, I also agree with Huub. As a consensus reached in Beijing meeting, mechanism using the tools defined for MPLS is a default tool set and another using the tools defined in G.8013/Y.1731 is an optional one. B.R. Yuxia malcolm.be...@zte.com.cn 发件人: ietf-boun...@ietf.org 2011-10-09 21:27 收件人 huubatw...@gmail.com 抄送 ietf-boun...@ietf.org, IETF Discussion ietf@ietf.org 主题 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, I agree. Regards, Malcolm Huub van Helvoort huubatw...@gmail.com Sent by: ietf-boun...@ietf.org 09/10/2011 07:42 AM Please respond to huubatw...@gmail.com To IETF Discussion 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, I still do not support this draft. Section 6 focusses on the interworking between two toolsets In transport networks we *never* have peer-2-peer OAM interworking. If it was required it would have explicitly been mentioned in the MPLS-TP requirements RFC. Why don't you simply read draft-tsb-mpls-tp-ach-ptn or Annex B of G.8110.1 where it is documented how different toolsets can be deployed in a network without any issues. Section 6 is totally irrelevant. 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
Hi, I have concern about statement on section 9 in RFC5317 by Russ: 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. Since the publication of RFC 5317, the MPLS WG consensus continues to be that only one OAM solution should become a standard. As I said in my previous email, it means use same architecture (GACH) for LSP and PW OAM not deduce only one OAM solution should become a standard, and this is no consensus in mpls group. for OAM analysis, which is captured in draft-ietf-mpls-tp-oam-analysis, it is still a draft. and in section 2 of RFC 5860 (Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks): The way in which those protocols are operated and the way in which a network operator can control and use the MPLS-TP OAM functions SHOULD be as similar as possible to the mechanisms and techniques used to operate OAM in other transport technologies. this requirement is not satisfied by RFCs published. I fully agree All MPLS-TP OAM tools should comply with RFC5586 and should satisfy with RFC5860, and provider can pick up subset of them. finally, I still don't support publish draft-sprecher-mpls-tp-oam-considerations-01.txt as RFC. B.R. Feng -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Huub van Helvoort Sent: 2011年10月9日 18:58 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 Hello Russ, You write: RFC 5317 calls for one, and only one, protocol solution. At least that is how I read JWT Agreement. How the JWT report should be read is written on slide 9 in the PDF: 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 The most relevant text seems to be in Section 9: This text is one of the assumptions, that is why we wrote: *They stated that in their view*: 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. The OAM technology in this text refers to to way the OAM frames can be detected in a data-stream. The text you quote is from the summary section, it summarizes the slides 19 - 22: *MPLS-TP Major Solution Constructs* which address the GAL-GAch solution. We now have the GAL-GAch technology (RFC5586) to detect OAM frames and this technology will be used in PW and LSP, and enables the use of OAM in deeply nested networks. Since the publication of RFC 5317, the MPLS WG consensus continues to be that only one OAM solution should become a standard. All MPLS-TP OAM tools should comply with RFC5586. A service provider can now pick any set or sub-set of the available OAM tools and use them without fear to disrupt the internet. Looking at the current discussions, there is no consensus (yet) on whether we need a comprehensive set of OAM tools, or a very limited set of OAM tools. Best regards, Huub (JWT, Ad-Hoc, MEAD member). ___ 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
Speaking only as an individual, I also support publication of this document as an informational RFC. I agree with many comments that the SONET discussion in section 5.1 should be deleted, and I would suggest that all of sections 4 and 5 be deleted. I was involved in the controversy that created both IS-IS and OSPF (as well as in the significant cooperation on protocol details that was going on in the background at the same time) and I think that the section on IS-IS and OSPF is mostly correct (even if I would have worded some of it a bit differently). One change I would make to this section is changing more than doubles the cost of link state IGP maintenance and deployment to be doubles the cost of link state IGP maintenance. Also derive from the same root document should be derive from the same root technology. Of course if sections 4 and 5 are deleted then there is no need to make these minor corrections to section 4.1. Regarding Russ's comment ...only one OAM solution should become a standard. I might note that there is considerable precedent in the IETF for publishing one standard, but also publishing informational RFCs that document other solutions that were considered in the IETF effort and that have been deployed. There certainly are many cases of pre-standard or non-standard solutions being deployed (often before IETF standards were finished) and in these cases I have long felt that it is desirable to document what has been deployed. Ross -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Russ Housley Sent: Saturday, October 08, 2011 11:03 AM To: IETF 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 publication of this draft, although the SONET discussion could be discarded. Also, I would like to see a reference to RFC 5921 in the introduction. RFC 5317 calls for one, and only one, protocol solution. At least that is how I read JWT Agreement. The most relevant text seems to be in Section 9: They stated that in their view, 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. Since the publication of RFC 5317, the MPLS WG consensus continues to be that only one OAM solution should become a standard. Russ On Oct 5, 2011, at 11:02 PM, Rui Costa wrote: c) To the question which requirement stated in the RFCs are not satisfied by the singe OAM solution defined in IETF?: For instance, RFC5860 2.2.3: The protocol solution(s) developed to perform this function proactively MUST also apply to [...] point-to-point unidirectional LSPs, and point-to- multipoint LSPs. ___ 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
two small points, 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
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. The OAM technology in this text refers to to way the OAM frames can be detected in a data-stream. During the JWT effort, I did not interpret the term OAM technology to be strictly limited to just the manner in which OAM frames are detected in the data-stream. I interpreted this in a broader sense. Looking at the current discussions, there is no consensus (yet) on whether we need a comprehensive set of OAM tools, or a very limited set of OAM tools. I don't understand this comment. We have requirements documents that have been agreed and published, and that carefully lay out a list of capabilities that need to be available. We need tools that fulfill these requirements. Perhaps I am not sure what distinction you make between comprehensive set of OAM tools versus limited set of OAM tools. Ross ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
