Re: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14
David, > Yakov, > > > How about if I'll add the following at the end of 5.5: > > > > Aggregation procedures would require two labels stack. > > This does not introduce any new implications on MTU, > > as even VPLS multicast supported by ingress > > replication requires two labels stack. > > Sure, minor suggestion - "two labels stack" -> "two MPLS labels > in the label stack" (twice). Ok. > > > I'd suggest an initial sentence: > > > > > > Replication of traffic within a multicast tree, and flooding > > > of traffic (see section 14) could be employed as traffic > > amplifiers in denial of service attacks. > > > > I'll add this. > > Ok, but see below for a combined text suggestion that includes ... > > > > Followed by a sentence or sentences that list a few important applicable > > > countermeasures (your choice), explaining why each is applicable and > > > indicating where each is described (this document, RFC 4761 or RFC 4762). > > > > I would greatly appreciated if you would help me with "a sentence > > or sentences" to cover this. I don't think RFC4761 or RFC4762 > > describe any of such countermeasures. > > The security considerations section already contains this sentence: > >As mentioned in [RFC4761], there are two aspects to achieving data >privacy and protect against denial-of-service attacks in a VPLS: >securing the control plane and protecting the forwarding path. > > The rest of that paragraph covers data privacy and black-holing. Perhaps > just extend the last sentence, e.g.,: > > OLD >In addition, compromise of the control plane could result in black- >holing VPLS multicast data. > NEW >In addition, compromise of the control plane could result in black- >holing VPLS multicast data and could provide opportunities for >unauthorized VPLS multicast usage (e.g., exploiting traffic >replication within a multicast tree to amplify a denial of >service attack based on sending large amounts of traffic). That is fine. Thanks for the text ! Yakov.
Re: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14
David,
> Yakov,
>
> First of all, thank you for overlooking the "off-by-one" error on
> the year :-) -
>
> > > Review Date: September 23, 2012
> > > IETF LC End Date: September 23, 2012
>
> Of course, 2013 was intended, twice ;-).
:-)
> On the two items (both are editorial, IMHO):
>
> > > (1) The techniques in this draft appear to add an MPLS label to the
> > > stack in order to identify the MPLS multicast tree. Does that added
> > > label raise any MTU concerns in practice?
> >
> > No more than any other use of label stacking (and there are plenty
> > of other uses of label stacking).
>
> I concur, which is why I noted this item as editorial - I don't think
> it's an actual issue.
>
> > Furthermore, rfc3032 ("MPLS Label
> > Stack Encoding") does cover the MTU issue.
>
> A sentence to that effect (lots of uses of label stacking, MTU effects
> are both well understood and not a problem in practice) with a
> reference to RFC 3032 should suffice.
How about if I'll add the following at the end of 5.5:
Aggregation procedures would require two labels stack.
This does not introduce any new implications on MTU,
as even VPLS multicast supported by ingress
replication requires two labels stack.
> > > (2) Two techniques used by this draft - replication of traffic within
> > > a multicast tree, and flooding of traffic (section 14) - could be
> > > employed as traffic amplifiers in denial of service attacks. A short
> > > discussion of this possibility and the applicability of countermeasures
> > > described in this draft, RFC 4761 and/or RFC 4762 would be good to
> > > add to the security considerations section.
> >
> > The Security Consideration section already talks about 4761 and 4762:
> >
> >Security considerations discussed in [RFC4761] and [RFC4762] apply to
> >this document.
> >
> > Suggestion on any additional text would be greatly appreciated.
>
> I'd suggest an initial sentence:
>
> Replication of traffic within a multicast tree, and flooding
> of traffic (see section 14) could be employed as traffic
> amplifiers in denial of service attacks.
I'll add this.
> Followed by a sentence or sentences that list a few important applicable
> countermeasures (your choice), explaining why each is applicable and
> indicating where each is described (this document, RFC 4761 or RFC 4762).
I would greately appreciated if you would help me with "a sentence
or sentences" to cover this. I don't think RFC4761 or RFC4762
describe any of such countermeasures.
Yakov.
>
> > -Original Message-
> > From: Yakov Rekhter [mailto:ya...@juniper.net]
> > Sent: Tuesday, September 24, 2013 10:27 AM
> > To: Black, David
> > Cc: tsv-...@ietf.org; raggarw...@yahoo.com; y.kam...@ntt.com;
> > luf...@cisco.com; ya...@juniper.net; ietf@ietf.org; l2...@ietf.org;
> > stbry...@cisco.com; ya...@juniper.net
> > Subject: Re: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-1
4
> >
> > David,
> >
> > > I've reviewed this document as part of the transport area directorate's
> > > ongoing effort to review key IETF documents. These comments were written
> > > primarily for the transport area directors, but are copied to the
> > > document's authors for their information and to allow them to address
> > > any issues raised. When done at the time of IETF Last Call, the authors
> > > should consider this review together with any other last-call comments
> > > they receive. Please always CC ???tsv-...@ietf.org if you reply to or
> > > forward this review.
> >
> > Thanks for your review.
> >
> > > Document: draft-ietf-l2vpn-vpls-mcast-14
> > > Reviewer: David L. Black
> > > Review Date: September 23, 2012
> > > IETF LC End Date: September 23, 2012
> > >
> > > Summary: This draft is basically ready for publication, but has nits that
> > > should be fixed before publication.
> > >
> > > This draft describes multicast optimizations for VPLS via use of MPLS
> > > multicast distribution trees within the service provider (SP) network.
> > >
> > > In general, the techniques in this draft are an improvement, as they
> > > should typically result in reduction of SP network traffic required
> > > to carry the same level of multicast traffic originating from the VPLS
> > > edges. I have reviewed primarily for transport-related topics; while
> > > I don't have the
Re: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14
David,
> I've reviewed this document as part of the transport area directorate's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the
> document's authors for their information and to allow them to address
> any issues raised. When done at the time of IETF Last Call, the authors
> should consider this review together with any other last-call comments
> they receive. Please always CC ???tsv-...@ietf.org if you reply to or
> forward this review.
Thanks for your review.
> Document: draft-ietf-l2vpn-vpls-mcast-14
> Reviewer: David L. Black
> Review Date: September 23, 2012
> IETF LC End Date: September 23, 2012
>
> Summary: This draft is basically ready for publication, but has nits that
> should be fixed before publication.
>
> This draft describes multicast optimizations for VPLS via use of MPLS
> multicast distribution trees within the service provider (SP) network.
>
> In general, the techniques in this draft are an improvement, as they
> should typically result in reduction of SP network traffic required
> to carry the same level of multicast traffic originating from the VPLS
> edges. I have reviewed primarily for transport-related topics; while
> I don't have the expertise to review for MPLS and VPLS concerns, I'm
> confident in the expertise of this author team in those technologies.
>
> I found a couple of items that are effectively editorial:
>
> (1) The techniques in this draft appear to add an MPLS label to the
> stack in order to identify the MPLS multicast tree. Does that added
> label raise any MTU concerns in practice?
No more than any other use of label stacking (and there are plenty
of other uses of label stacking). Furthermore, rfc3032 ("MPLS Label
Stack Encoding") does cover the MTU issue.
>
> (2) Two techniques used by this draft - replication of traffic within
> a multicast tree, and flooding of traffic (section 14) - could be
> employed as traffic amplifiers in denial of service attacks. A short
> discussion of this possibility and the applicability of countermeasures
> described in this draft, RFC 4761 and/or RFC 4762 would be good to
> add to the security considerations section.
The Security Consideration section already talks about 4761 and 4762:
Security considerations discussed in [RFC4761] and [RFC4762] apply to
this document.
Suggestion on any additional text would be greatly appreciated.
Yakov.
>
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA?? 01748
> +1 (508) 293-7953 FAX: +1 (508) 293-7786
> david.bl...@emc.com?? Mobile: +1 (978) 394-7754
>
>
>
Re: Last Call: draft-ietf-l3vpn-2547bis-mcast-bgp (BGP Encodings andProcedures for Multicast in MPLS/BGP IP VPNs) to Proposed Standard
Jie, > Hi, > > Here are some comments on this draft. (hope this is not too late:) see in-line... > 1. 4-octets ASN support > > The IANA Consideration section says the Source AS extended community is > 2-octet AS specific. Consider that 4-octet ASN is supported in other > sections of this draft, a 4-octet AS specific equivalent should also be > defined. Agreed. > 2. Section 8: PE distinguish Labels Attribute > > +-+ > | PE Address| > +-+ > | Label (3 octets)| > +-+ > ... > +-+ > | PE Address| > +-+ > | Label (3 octets)| > +-+ > > If my understanding is correct, this attribute can contain multiple PE > address-Label pairs. thus more than 1 PE address can exist in this > attribute. So the statement below may be inaccurate: > > "The attribute is also considered to be malformed if the PE Address field is > expected to be an IPv4 address, and the length of the attribute minus 4 is > not a multiple of 3, or the PE Address field is expected to be an IPv6 > address, and the length of the attribute minus 16 is not a multiple of 3." Thanks for catching this. The correct text should be as follows: "The attribute is also considered to be malformed if the PE Address field is expected to be an IPv4 address, and the length of the attribute is not a multiple of 7, or the PE Address field is expected to be an IPv6 address, and the length of the attribute is not a multiple of 19." > 3. In section 11.1.3, it says: > > "Inter-AS I-PMSI A-D routes are not used to support non-segmented inter-AS > tunnels...The Source AS field in the C-multicast route is set to value of > the Originating Router's IP Address field of the found Intra-AS I-PMSI A-D > route." > > Does this mean that for non-segmented inter-AS tunnel, the Source AS filed > of C-multicast route will be filled with an IP address? Yes. > It may not consistent with statement in the first paragraph of this section: > > "From the selected UMH route the local PE extracts (a) the autonomous system > number of the upstream PE (as carried in the Source AS extended community of > the route), and (b) the C-multicast Import RT of the VRF on the upstream PE > (the value of this C-multicast Import RT is the value of the VRF Route > Import Extended Community carried by the route). The Source AS field in the > C-multicast route is set to that autonomous system." The text you are quoting above applies when one uses segmented inter-AS tunnels. > Besides, if the Originating Router's IP Address is an IPv6 address, it > cannot be filled into the Source AS field of C-multicast route (4-octet). > > 4. Considerations about Route advertising Efficiency > > In this draft, A-D route may carry a PMSI tunnel attribute. MCAST-VPN NLRIs > with different PMSI tunnel attributes have to be advertised using different > BGP update messages. > > Different multicast flows using different P-tunnels will be advertised using > individual update messages. This can be acceptable. > > However, if multiple multicast flows are aggregated into the same P-tunnel, > due to the different upstream/downstream labels in their PMSI tunnel > attributes, they still cannot be combined into one update message. Maybe > there is some space to improve the efficiency? For example, the label field > in PMSI tunnel attribute could be moved into the NLRIs of A-D route. When multiple multicast flows are aggregated into the same P-tunnel, and each of these flows uses different upstream-assigned label, then it is likely that these flows belong to different MVPNs. As such, the routes that advertise these flows and their P-tunnel have different RTs, and thus should not be combined into a single BGP Update message. Yakov. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-l3vpn-2547bis-mcast-bgp-07
Spencer,
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-l3vpn-2547bis-mcast-bgp-07
> Reviewer: Spencer Dawkins
> Review Date: 2009-09-17 (oops!)
> IETF LC End Date: 2009-09-08
> IESG Telechat date: (not known)
>
> Summary: This draft is almost ready for publication as a Proposed Standard.
> I have some comments, mostly 2119 language plus some sentences that didn't
> parse and seemed important.
Many thanks for your review and comments.
Response to your comments in-line...
>
> Abstract
>
>This document describes the BGP encodings and procedures for
>exchanging the information elements required by Multicast in MPLS/BGP
>IP VPNs, as specified in [MVPN].
>
> Spencer (nit): I'd expect the RFC Editor to remove a reference in the
> Abstract section.
>
> 2. Introduction
>
>This document describes the BGP encodings and procedures for
>exchanging the information elements required by Multicast in MPLS/BGP
>IP VPNs, as specified in [MVPN]. This document assumes a thorough
>familiarity with procedures, concepts and terms described in [MVPN].
>
>This document defines a new NLRI, MCAST-VPN NLRI. The MCAST-VPN NLRI
>
> Spencer (nit): I'd expect the RFC Editor to ask that abbreviations be
> expanded on first use.
>
>is used for MVPN auto-discovery, advertising MVPN to I-PMSI tunnel
>binding, advertising (C-S, C-G) to S-PMSI tunnel binding, VPN
>customer multicast routing information exchange among PEs, choosing a
>single forwarder PE, and for procedures in support of co-locating a
>C-RP on a PE.
>
> 5. PMSI Tunnel attribute
>
>When a router that receives a BGP Update that contains the PMSI
>Tunnel attribute with its Partial bit set determines that the
>attribute is malformed, the router SHOULD treat this Update as though
>all the routes contained in this Update had been withdrawn.
>
> Spencer (minor): why SHOULD in this case, and not MUST? (Note that similar
> text occurs throughout this section)
This is to be consistent with draft-ietf-idr-optional-transitive-00.txt:
Instead, when such an attribute is determined to be
malformed, the UPDATE message containing that attribute SHOULD be
treated as though all contained routes had been withdrawn just as if
they had been listed in the WITHDRAWN ROUTES field of the UPDATE
message, thus causing them to be removed from the Adj-RIB-In
according to the procedures of [RFC4271].
>An implementation MUST provide debugging facilities to permit issues
>caused by malformed PMSI Tunnel attribute to be diagnosed. At a
>minimum, such facilities SHOULD include logging an error when such an
>attribute is detected.
>
> Spencer (minor): If debugging facilities are a MUST, shouldn't the minimum
> debugging facility be a MUST? :-) Or are there well-understood reasons
> ("MUST do X unless") that could be provided? (Note that similar text occurs
> elsewhere in the draft)
We'll change it to "MUST include logging".
Btw, we will apply the same fix to the similar text in Section 8.
>The PMSI Tunnel attribute is used in conjunction with Intra-AS I-PMSI
>A-D routes, Inter-AS I-PMSI A-D routes, S-PMSI A-D routes, and Leaf
>A-D routes.
>
>
> 7. VRF Route Import Extended Community
>
>If a PE uses Route Target Constrain [RT-CONSTRAIN], the PE SHOULD
>advertise all such C-multicast Import RTs using Route Target
>Constrains (note that doing this requires just a single Route Target
>Constraint advertisement by the PE). This allows each C-multicast
>route to reach only the relevant PE. To constrain distribution of the
>Route Target Constrain routes to the AS of the advertising PE these
>routes SHOULD carry the NO_EXPORT Community ([RFC1997]).
>
> Spencer (minor): I'm not sure I understand why these are SHOULDs and not
> MUSTs. (Note that similar text occurs elsewhere in the draft) I note that
> you give reasons why the similar text in Section 8 is not a MUST, using this
> explanation:
The "SHOULD" is because use of Route Target Constrain in this case
is an optimization (as indicated in the second sentence in the above
paragraph).
> "Note that if non-segmented inter-AS P-tunnels are being used, then
>the Intra-AS I-PMSI routes need to be distributed to other ASes and
>MUST NOT carry the NO_EXPORT community."
>
> 8. PE Distinguisher Labels Attribute
>
>The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD
>be set to the same IP address as the one carried in the Originating
>Router's IP Address field.
>
> Spencer (minor): I'm not sure why this is a SHOULD and not a MUST, but if it
> is a SHOULD, I'd expect to see some guidance about what
Re: When to DISCUSS?
Scott, > On Mon, Jul 11, 2005 03:42:14PM +0200, Brian E Carpenter allegedly wrote: > > Phill, > > > > Just picking out the nub of your message: > > > > >There is however one area that should be made very explicit as a non > > >issue for DISCUSS, failure to employ a specific technology platform. > > > > > >I have been concerned on a number of occasions where it has appeared > > >that in order to get a specification approved by the IESG it would be > > >necessary to adopt a particular technology being promoted by IESG > > >members. > > > > I think the last phrase is unfair - if the IETF is putting a lot of effort > > into technology Foo, then it's a legitimate question to ask "Why aren't > > you re-using Foo?" But we do have as a non-criterion: > > > >o Disagreement with informed WG decisions that do not exhibit > > problems outlined in Section 3.1. In other words, disagreement in > > preferences among technically sound approaches. > > > > As I read this, it would be legitimate for an AD to ask > > > > Did the WG consider Foo, and if so, have good reasons for > > rejecting it in favour of Bar? > > > > and illegitimate to say > > > > I like Foo more than Bar, so I'm blocking this. > > > > If we agree on this, some wordsmithing may be needed. > > > > Brian > > There are occasions when limiting the number of deployed solutions is > very good for the future of the Internet, and in those cases, pushing > for Foo even when Bar is just as good is quite legitimate. Limiting the number of deployed solutions should be done based on the operational experience/market forces, and not by ADs/IESG pushing for a particular solution. Yakov. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option
Ned, > > To state that somewhat differently, since we cannot effectively > > prohibit the deployment of an extension or option of which the > > IETF disapproves, the best things we can do for the Internet are > > make it as easy as possible to identify the use of the extension > > so it can be effectively quarantined and to make information > > about why we consider it a bad idea readily available. > > Ironically, both of those goals are most strongly aided by > > registering the extension and assigning an appropriate > > identifier, rather than rejecting registration requests and > > hoping the idea goes away. > > Very nicely put, John. I completely agree. And to the extent we have "running > code" in this area, I believe it supports this view. What was the reason(s) the request was made for an assignment that required IESG Approval, rather than either Specification Required or First Come First Serve ? Yakov. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I'm not going to listen to this any more.
Brian, > I have the good fortune to not be subscribed to the > namedroppers list, so I have no familiarity with past > traffic on that list. I think it behooves us all to let > bygones be bygones - I don't see much point in debating > alleged misdeeds of former ADs. ADs in their deeds, or misdeeds represent not just themselves, but IESG as a whole. As such, deeds/misdeeds of ADs should be viewed as deeds/misdeeds of IESG, and not just of individual ADs. Therefore, I think it behooves IESG to resolve *in a public forum* complains about alleged misdeeds by ADs, irrespective of whether these ADs are former or not. Yakov. > > Brian > > Dean Anderson wrote: > > Mr. Alvestrand's comments certainly demonstrates the animousity of the > > former chair and they demonstrate his motive for not enforcing the IETF > > and ISOC Code of Conduct against those making personal attacks against > > Dean Anderson, Av8 Internet, and perhaps others, such as Dan Bernstein, > > who were abused but the abuse was never properly redressed, nor were the > > abusers chastisted or punished in any way. Abuse of Mr. Bernstein by > > Randy Bush was on the Namedroppers (DNSEXT) list, and included publishing > > his subscription address enabling forged unsubscriptions, and altering or > > delaying his messages and other inappropriate "special treatment" for > > which Mr. Bush was never chastised or punished, nor made to apologize. > > > > Mr. Alvestrands recent comments shows again the substance to this > > complaint: > > http://www1.ietf.org/mail-archive/web/ietf/current/msg30614.html > > > > Therefore, I would like to renew the earlier Code of Conduct complaints > > made against Mr. Vixie and others, with the additional provision noting > > the personal hostility of the former chair, Mr. Alvestrand, and his > > failure to act appropriately regardless of his personal hostility. > > > > I believe the IETF owes an apology to Dan Bernstein, Dean Anderson, Av8 > > Internet, and possibly others. > > > > Dean Anderson > > Av8 Internet, Inc > > > > On Sun, 26 Jun 2005, Harald Tveit Alvestrand wrote: > > > > > >>Since I'm no longer responsible for anything that Dean Anderson has a > >>legitimate role in, and Dean Anderson has proved that he irritates me, I > >>can stop listening to Dean Anderson. > >> > >>Goodbye, mr. Anderson. > >> > >>--On 25. juni 2005 20:21 -0400 Dean Anderson <[EMAIL PROTECTED]> wrote: > >> > >> > >>>The IETF cannot accept the statements of known, court-proven liars, nor > >>>can it suppress this fact in its deliberations. If the IETF accepts > >>>court-proven and documented liars as reliable sources of fact, then it > >>>will have no more credibility in its statements, as they will be based on > >>>lies, not on truth. > >> > >> > >> > >> > >> > >>___ > >>Ietf mailing list > >>Ietf@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ietf > >> > >> > > > > > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
Keith, > > > - The working group gets to pick at least some of its own chairs. > > > > Sorry, but I do not think the last bullet is correct. > > I was talking about community expectation, which is not always consistent with > what is written in the RFCs just like implementations of networking > protocols are not always consistent with the RFCs. Such situation requires revised RFCs. So, if there is indeed the IETF community expectation that the WG gets to pick at least some of its own chairs, then rfc3710 needs to be revised to reflect this. Which includes *clearly* spelling out the process by which the WG gets to pick at least some of its own chairs. In fact, perhaps some folks from the IESG (e.g., Brian) would comment on this topic... Yakov. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: text suggested by ADs
Jefsey, > On 19:22 05/05/2005, Joe Touch said: > > > The set of people disagreeing with ADs include both technically astute > > > people and egocentric fools. > > > >Ditto for the ADs themselves. > > Has this a real importance? The control is by IETF as a whole, _if_ rough > consensus is the rule. What is expected from ADs is to make sure that what > is proposed meets a rough consensus. This could possibly include commenting > their concerns before the Last Call if they feel it necessary. This may > include their advise. They should however _never_ consider anything else > than consensus. If they have other concerns they should join the WG. That is *not* how things are done today. As I mentioned before "rough consensus" goes only up to a certain point, but after that point the IETF operates solely by a decree from the IESG. Yakov. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: improving WG operation
Keith, [clipped...] > 2. There is a considerable cultural inertia within IETF that largely > dictates how working groups operate, and which is extremely > difficult to change. For instance, community expectations include: > > - If there is a BOF held and sufficient constituency identified for > a working group, the working group must be chartered. > > - The working group gets to pick at least some of its own chairs. Sorry, but I do not think the last bullet is correct. To the contrary, (quoting from rfc3710): The AD, with the advice of the IESG, is also responsible for selecting chairs for the working group which the AD thinks will be up to the task. Nowhere it mentioned that the WG "gets to pick at least some of its own chairs". Yakov. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: text suggested by ADs
Keith, > >> I don't see anything wrong with that. It's the ADs' job to push back > >> on documents with technical flaws. They're supposed to use their > >> judgments as technical experts, not just be conduits of information > >> supplied by others. > > > > I disagree that the ADs are necessarily that much more technically > > astute than the rest of us. > > 1. ADs usually _are_ more technically astute than the average IETF > participant (perhaps not you, but the average participant), because ADs > are selected for their expertise while IETF participants are > self-selecting. (Maybe some are selected by their employers, but I > don't think it's generally the practice of most employers to send their > best technical people to standards committees. My impression is that > many employers - not all by any means - would rather send people who > are expendable, and/or who will represent the company's official > position rather than their own best judgment.) At the same time for each AD there is more than one person in the IETF who is more technically astute than that AD. So, why should the IETF decision process favor opinion of such AD more than the opinion of these other individual who are more astute that the AD ? > 2. ADs also tend to have a broader perspective than the average IETF > participant, because ADs are exposed to everything that IETF does while > most participants' activity is confined to a narrow topic area. That's > not to say that a broad perspective is inherently less valuable than a > narrow perspective - they're both valuable, but for different reasons. Suffice to say that ADs do *not* have the monopoly on the broader perspective. Yakov. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: text suggested by ADs
Keith, > > > It's as likely to boil down to "how do we get this WG to realize that > > > there really is a serious technical problem with what they've created?" > > > > How about requiring to produce working code (and perhaps operational > > experience) ? > > working code is valuable in some cases - especially where it appears that > the protocol is not easily implemented. but working code won't provide > an indication of how well the protocol works in large deployments in the > wild. for that, analysis and/or modeling are the best tools we have. How many of such analysis and/or modeling has been produced by the IESG ? Yakov. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: text suggested by ADs
Keith, > > The case John outlines is the one I am concerned about as well. > > [...] > > And, FWIW, when the AD suggests specific text changes, it's often > > enough the desire of that AD rather than based on feedback from some > > other WG. > > I don't see anything wrong with that. It's the ADs' job to push back > on documents with technical flaws. They're supposed to use their > judgments as technical experts, not just be conduits of information > supplied by others. > > >> I think the ADs should continue to be able to raise such issues, but > >> I also think it might be helpful to have better way of resolving such > >> disputes than either "let the AD win" or "let's sit on this until the > >> IESG holds its nose and passes it". > > > > Sure - and sometimes other ADs get involved, and it boils down to > > "what can you add/change to appease the other AD" rather than "what is > > sensible to add". > > It's as likely to boil down to "how do we get this WG to realize that > there really is a serious technical problem with what they've created?" How about requiring to produce working code (and perhaps operational experience) ? Yakov. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Voting (again)
Dave, > Brian, > > > Er, yes, I think it's known as collective responsibility in some circles. > > When it is used well, yes. > > When it is used to reflect the personal preferences of the AD -- no matter the > history of the working group -- then it is known as something else, and it > happens with some regularity. Perhaps the IETF traditional motto, "rough consensus and working code" should be revised to make it clear that the "rough consensus" goes only up to a certain point, but after that point the IETF operates solely by a decree from the IESG. Yakov. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reminder: Poll about restructuring options
John, > In this context, my precise objection to what is going on now > rests on a comparison with that style of leadership. Jon's > style involved persuasion, logic, facts, and trying to > understand the point of view of those with whom he disagreed. > Like you, I disagreed with some of his positions and decisions, > and I found him quite stubborn when he thought he was right (not > always a bad trait), but I could almost always end up > understanding his point of view. By contrast, we are now seeing > a different style of position-taking and decision-making, one > that terrifies me. The new style involves assertions of the > "rights" of the people who occupy IESG and IAB seats (because > they are in those seats) instead of explanation and openness > with the community about details and options, and involves > (virtually) shouting "wrong" instead of engaging in discussion > and persuasion. Perhaps the IETF traditional motto, "rough consensus and working code" should be revised to make it clear that the "rough consensus" goes only up to a certain point, but after that point the IETF operates solely by a decree from the IESG. Yakov. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Community Collaboration, versus Central Management
Dave, [clipped...] > A critical danger in central management is an inherent fragility in > decision-making. Real diversity is lost. This becomes even more > serious, as the central management becomes more homogeneous and more > isolated. On the subject of central management, quoting from the IESG Plenary on Wednesday: IESG Plenary/Open Mike Q: Two questions for both IAB and IESG - individual participation and consensus - are these still important? alternative is participation by companies or governments, and voting... - we believe in these values up to point, at which point the IESG makes a decision - Harald semi-agrees that sometimes a decision is needed and the IESG makes one, but does not agree that IESG can impose its will against a working group - but does IESG try to get community consensus when it makes a decision? So it seems that the IETF traditional motto, "rough consensus and working code" should be revised to make it clear that the "rough consensus" goes only up to a certain point, but after that point the IETF operates solely by a decree from the IESG. Yakov.
Re: The requirements cycle
Alex, > Eric, > > Looking at this from the high-level perspective... > > Though I became the responsible AD for PPVPN just recently, I was > exposed to certain aspects of interaction between ADs are PPVPN WG > chairs. There was clearly a communication problem there. I believe > it's been solved and we are in a much better shape now. Trying to > investigate who said what and whose fault that was in the past will > not be pretty, so I suggest we don't go there. I suggest we *do* go there (irrespective of whether it will, or will not be pretty), as doing this could help us to understand the mistakes that have been made. And unless we do understand these mistakes, we are (very) likely to repeat them. Yakov.
RE: WG review: Layer 2 Virtual Private Networks (l2vpn)
Randy, > > "We're doing it" is a statement of fact. However, we've been > > doing it for over two years. Pseudo-wire work has been ongoing > > for over 4 years. MPLS has been ongoing since 1996 or > > thereabouts. > > no disagreement. the question i am hearing is not why is this > being done, but rather why is the ietf working on a an l2 over l2 > protocol. Would you please elaborate on what makes MPLS an L2. For that matter would you also explain what makes MPLS a layer on its own. randy
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
Pekka, [clipped...] > > From your message, I can't tell which of those, or of any number of other > > possible objections, is the basis of your objection. > > > > BTW - all these things were already being worked on in PPVPN. Some were > > even described in the charter. > > Fair question, I probably should have included more text in the first > place :-). > > 1. Virtual Private LAN Service. This is Internet-wise ethernet bridging > over routing protocols such as BGP, IS-IS, etc; further, this has > typically little respect for security implications which are implicit (or > even explicit) in LAN networks. > > So, my main points are: > > - we must not overload routing protocols and such infrastructure (IMHO, > this seems an inevitable path the work would go towards..) > > - we must not create complexity by deploying ethernet bridging all over > the Internet. Our work should be focused on making IP work, not > specifying Ethernet-over-IP (or worse, Ethernet-over-IP as a *service*). The proposed charter talks about VPLS "across an IP and an MPLS-enabled IP network". Such a network does not have to be the Internet. Yakov.
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
Melinda, > > Primarily, folks want to use it as in > > "Ethernet-over-MPLS". That may not necessarily go down > > well with you either, but think of MPLS as a logical FR. > > I think we need to retain a focus on connectionless, > packet-oriented delivery and how to build on that. What makes you think that MPLS does not support "connectionless packet-oriented delivery" ? Yakov.
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
Paul, > At 10:15 AM +0200 6/18/03, Harald Tveit Alvestrand wrote: > >I can think of some possible reasons, not necessarily exclusive > > > >- this is a bad idea/impossible to do well, so we shouldn't do it > >- some other organization is already doing it, so we shouldn't > >- we're too stupid to get it right, so we shouldn't do it > >- the IETF is too large, so we shouldn't be adding more work > > This might be a combination of the latter three, but I think it is > clearer for this WG: > > - the IETF's track record for this work so far is quite poor the attached e-mail that have been posted to the PPVPN mailing list sheds some light on why the IETF's track record for this work so far is quite poor. Yakov. - Date: Sun, 4 May 2003 13:24:58 -0700 Reply-To: PPVPN <[EMAIL PROTECTED]> Sender: PPVPN <[EMAIL PROTECTED]> From: [EMAIL PROTECTED] Subject: Strategy for VPN work in IETF Comments: To: [EMAIL PROTECTED] Comments: cc: [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alex Zinin writes: > Since San Francisco IETF meeting the IESG has been considering the > situation in the SUB-IP area and in the PPVPN Working Group in > particular. > Such close attention to this WG was triggered by numerous concerns > thatthe IESG members received from the WG participants about limited > and slow progress within the WG despite the efforts of the WG chairs > and its members. The IESG also used this opportunity to consider > the IETF area that the PPVPN work would fit best. > After much deliberation, the involved ADs (Bert, Thomas, and I) are > considering the following organizational changes in order to > improve WG focus and productivity and ensure faster progress of the > VPN-related work: > 1. Split of Layer-2 and Layer-3 VPN work in separate Working Groups. > The L2 and L3 VPN work spaces are each big enough to warrant a > separate WG. While concentration of all VPN-related work in a > single forum was the right thing to do to ensure coordination > of efforts when the PPVPN WG was created and L2 VPN work came in, > such concentration is causing scaling problems within the WG at > this moment. > Migration of work into two separate WGs for L2 and L3 VPN > technologies with more specific WG charters will help to focus > discussions, prevent staff and meeting time overloading, and will > aid faster progress of corresponding technologies. Alex, The proposed solution ignores the origins of the problem. The fact that PPVPN has been making any progress at all, despite the bureaucracy imposed on it by the IESG is rather comendable. This is a typically example of a WG which was setup despite many architectural objections that it doesn't fit in the "internet" design. One cannot help but to suspect that there was the hope ammoung the inner circles that it would fail altogether. At least giving the ammount of "framework" nonsense required and the interdiction to discuss solutions before a framework is agreed upon. The work of this working group is particularly harder given that this is todays "fashion" area... work is much harder on such areas (like mpls was a couple of years ago). One would suspect that the IESG efforts to slow the WG steem also from concerns that fashion areas tend to create a fair ammount of nonsense proposals most of which tend to be naturally eliminated by the WGs. Given the environment the performance of the ppvpn WG seems to me to rather positive. It has actually come up with several documents that are useful and deserve publication. One of the reasons given here for this proposed disolution of the WG is that the "L2VPN and L3VPN work spaces are big enought". However both in the list and WG meetings it seems to me that the current l3vpn WG is close to 0. The base document on l3vpn has been rather stable for a while and it is not likely to change. The IESG/inner-circle has chosen for mostly ideological reasons to attempt to marginalize this work so it can hardly expect to be heard now. It seems to me that if there is a problem w/ PPVPN that problem lies within the IESG itself. As such i would like to propose to split the IESG in two WGs: one that concerns itself w/ architecture and one group that concerns itself with the process of documenting interoperable solutions that are not known to be good or bad ideas until used in pratice. This latter group should have the task to assure that the process is fair and that both the pluses and minus of a solution are considered and documented. One of the ideal caractheristics of the latter group would be if they where to realize that by definition an IESG member is much less of an expert in a given domain than the membership of the WG it steers. It is humanly impossible for it to be otherwise. Unless you assume that the membership of WG is 100% incompetent which is never the case. A steerer cannot possibly be an expe
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
Paul, > At 10:15 AM +0200 6/18/03, Harald Tveit Alvestrand wrote: > >I can think of some possible reasons, not necessarily exclusive > > > >- this is a bad idea/impossible to do well, so we shouldn't do it > >- some other organization is already doing it, so we shouldn't > >- we're too stupid to get it right, so we shouldn't do it > >- the IETF is too large, so we shouldn't be adding more work > > This might be a combination of the latter three, but I think it is > clearer for this WG: > > - the IETF's track record for this work so far is quite poor > > We have not shown any ability to create standards in this area with > due speed or predictability. I certainly agree with your on the "track record". But I think we need to be a bit more specific on why the track record is "quite poor". For example, why the IESG didn't approve 2547bis as a Proposed Standard 2 years ago ? Ditto for draft-martini... Perhaps folks from the IESG would care to explain this... Yakov.
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
Paul, > >Alternatively, we can own up that it is OUR problem, i.e., the IETF, and if > >we want a solution, we will create one here. > > If we decide that "the problem" is one in our realm, I fully agree. > But transporting layer 2 stuff over IP is not a problem that affects > the Internet. It is a problem for the service providers marketing > departments. The past three yeas have proven that service providers > can satisfy their customers needs with L3VPNs, with > somewhat-interoperable L2VPNs, with non-interoperable L2VPNs, and > with just plain layer 2 circuits. I certainly agree with you that there are enough examples that clearly show that service providers can satisfy their customers needs with *multi-vendor* *interoperable* implementations based on the *open* specs, where the spec is an Internet Draft, rather than an IETF standard. In other words, an Internet Draft + working code is both necessary *and* sufficient. Yakov.
Re: Last Call: CR-LDP Extensions for ASON to Informational
Bert, [clipped...] > Two points: > - the extensions to LDP were found to be in space that requires > IETF Consensus, and so Scott and I asked for an IETF Last Call > on the document. That is an explicit OPEN process Quoting from the e-mail you sent recently: If not enough people (and 10 is the absolute minumum, but having seen the attendence of TWEG sessions, I'd expect 25 or more) can speak up to state one of: - I read it and I am positive, it is good stuff - I read it and I see no problems or objections - I read it but I cannot determine if it is bad, but I can see that what has been discussed in the WG is indeed in the document - I read it and I have these nits/objections... - I did not read it cause this is not relevant to my xxx job/work/function - I did not read it cause I think this is nonsense Then I get the feeling that we're just allowing a small group of people push their petty-project through the process. That seems NOT good to me. We need serious WG participation in reading and commenting in one of these forums above, before we can declare that we have WG consensus on a document to be presented to IESG for approval as RFC (in whatever form). Since (as you said) the extensions required IETF consensus, and with the above in mind could you please share with the rest of us the information on how many people spoke up about the draft to state one of: - I read it and I am positive, it is good stuff - I read it and I see no problems or objections - I read it but I cannot determine if it is bad, but I can see that what has been discussed in the WG is indeed in the document - I read it and I have these nits/objections... - I did not read it cause this is not relevant to my xxx job/work/function - I did not read it cause I think this is nonsense Yakov.
Re: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
Suresh, > > > My recommendation against using this draft as the basis for > > > building further TE-extensions to inter-area and mixed networks > > > was in the context of OSPF Autonomous System (AS). I also > > > mentioned the draft has scalability limitations in extending this > > > to inter-area and mixed networks - also in the context of OSPF AS. > > > > > > Without going into the details of the "Multi-area MPLS Traffic > > > Enginering" draft - The work cited in this draft as going on to > > > address multi-area TE is in the MPLS signalling context, not in > > > the OSPF. > > > > As I said in my previous e-mail quite a few scenarios described in > > draft-kompella-mpls-multiarea-te-03.txt are supported with the TE > > extensions that are subject to this Last Call. That is precisely > > while quite a few scenarios in the "Multi-area MPLS Traffic Engineering" > > draft do not require any additions to what is already defined > > in the katz-yeung draft. > > > > Yakov. > > Yakov, > > Yes, quite a few scenarios described in kompella-mpls-multiarea-te draft > are supported with single-area TE extensions and do not require any > additions. And, katz-yeung draft proposal will suffice for single-area > TE extensions. Good. So we are in agreement that the katz-yeung draft can support both single area and multi-area TE. > katz-yeung draft does not cover dissemination of inter-area TE info > (which I was refering to as *inter-area OSPF-TE*). Neither does the > draft claim to do so. That is correct too. > Inter-area OSPF-TE is a scenario described in > kompella-mpls-multiarea-te for faster convergence in LSP computation. I am not sure which scenario you are referring to. But anyway, this is outside the scope of the present discussion... > In this context - my recommendation to not use katz-yeung draft as the > basis to extend to inter-area OSPF-TE was because of its scaling > limitation. And my recommendation is exactly the opposite - start multi-area TE with what is already in the katz-yeung draft, gain some operational experience with it, and then improve this, *if necessary*, based on the experience. But anyway, this is outside the scope of the present discussion... > Neither katz-yeung nor kompella-mpls-multiarea-te drafts address mixed > networks. katz-yeung draft has limitations with flooding disruption > and topology isolation in a mixed network - both intra-area and > inter-area. This was another reason why I recommended to not use > katz-yeung draft as the basis to extend to inter-area OSPF-TE. To avoid any confusion I would suggest to add the following to the katz-yeung draft: It is an explicit non-goal of the solution described in this document to address all possible (as well as impossible) requirements. Therefore, the solution described in this document is clearly not a perfect solution, and as such doesn't quality for being a LTSFGTC (Long Term Solution For Generations To Come). Work on the perfect solution (aka LTSFGTC) is in progress, and is expected to be published in RFC10. Yakov.
Re: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
Suresh, > > > > Please look at draft-kompella-mpls-multiarea-te-03.txt, as > > > > at least some of the approaches described in that draft > > > > do *not* assume additive properties of TE metrics (and do not > > > > advertise summary info). > > > > > > > > Yakov. > > > > > > Yakov - You are right. The draft does talk about different > > > mechanisms the MPLS signaling protocols could use to setup > > > LSPs in an AS spanning multiple areas. However, the draft is > > > not about inter-area OSPF TE. > > > > The draft is about multi-area TE, as it describes how to solve > > the problem of supporting TE in a multi-area environment. > > OK. > > > > Clearly, there is interplay between signalling protocols and > > > the extent of TE link state data base (TE-LSDB) a node has. > > > I believe, scenario-3 is where the inter-area OSPF-TE is in > > > place and all nodes in an area have the same information as > > > their ABRs do. This scenario presents the signalling protocols > > > with fast convergence in settign up an LSP, right. > > > > Just to point out that quite a few scenarios described in > > draft-kompella-mpls-multiarea-te-03.txt are supported with the TE > > extensions that are subject to this Last Call. To repeat what > > Kireeti said already "There is work going on to address multi-area > > TE *that builds on this draft*." > > > > Yakov - My comment on the katz-yeung draft concerning multi-area > is that it supports TE in a single OSPF area; and hence to rename > the draft as "TE extensions to an OSPFv2 area". Let's be precise. The katz-yeung draft defines certain TE-related information, and specifies how to distribute this information within a single area. That is it. > My recommendation against using this draft as the basis for > building further TE-extensions to inter-area and mixed networks > was in the context of OSPF Autonomous System (AS). I also > mentioned the draft has scalability limitations in extending this > to inter-area and mixed networks - also in the context of OSPF AS. > > Without going into the details of the "Multi-area MPLS Traffic > Enginering" draft - The work cited in this draft as going on to > address multi-area TE is in the MPLS signalling context, not in > the OSPF. As I said in my previous e-mail quite a few scenarios described in draft-kompella-mpls-multiarea-te-03.txt are supported with the TE extensions that are subject to this Last Call. That is precisely while quite a few scenarios in the "Multi-area MPLS Traffic Engineering" draft do not require any additions to what is already defined in the katz-yeung draft. Yakov.
Re: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
Suresh, > > > As for the comment from John Moy (circa July 2001) about the > > > availability of an inter-area OSPF draft, I do recall responding > > > that the inter-area draft was assuming additive properties to > > > TE metrics to advertise summary info. It is a mistake to assume > > > that all TE metrics can be additive. Below is a pointer to > > > the response I sent. > > > > > > http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=ospf&; > > >T=0&F=&S=&P=5937 > > > > Please look at draft-kompella-mpls-multiarea-te-03.txt, as > > at least some of the approaches described in that draft > > do *not* assume additive properties of TE metrics (and do not > > advertise summary info). > > > > Yakov. > > Yakov - You are right. The draft does talk about different > mechanisms the MPLS signaling protocols could use to setup > LSPs in an AS spanning multiple areas. However, the draft is > not about inter-area OSPF TE. The draft is about multi-area TE, as it describes how to solve the problem of supporting TE in a multi-area environment. > Clearly, there is interplay between signalling protocols and > the extent of TE link state data base (TE-LSDB) a node has. > I believe, scenario-3 is where the inter-area OSPF-TE is in > place and all nodes in an area have the same information as > their ABRs do. This scenario presents the signalling protocols > with fast convergence in settign up an LSP, right. Just to point out that quite a few scenarios described in draft-kompella-mpls-multiarea-te-03.txt are supported with the TE extensions that are subject to this Last Call. To repeat what Kireeti said already "There is work going on to address multi-area TE *that builds on this draft*." Yakov.
Re: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
Suresh, > Rohit, > > My comments were made solely in reference to the > draft-katz-yeung draft; not in comparison to any specific draft, > as you might believe. > > As for the comment from John Moy (circa July 2001) about the > availability of an inter-area OSPF draft, I do recall responding > that the inter-area draft was assuming additive properties to > TE metrics to advertise summary info. It is a mistake to assume > that all TE metrics can be additive. Below is a pointer to > the response I sent. > http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=ospf&T=0&F=&S=&; > P=5937 Please look at draft-kompella-mpls-multiarea-te-03.txt, as at least some of the approaches described in that draft do *not* assume additive properties of TE metrics (and do not advertise summary info). Yakov. > This goes right back to the comment I made below about > using the draft-katz-yeung draft as the basis for inter-area TE. > > regards, > suresh > > -Original Message- > From: Rohit Dube [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, December 17, 2002 11:46 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 > to Proposed Standard > > > > Suresh, > > You have brought up this issue on the ospf mailing list a couple > of times and as such the topic has been addressed on the list. > > Here is pointer to an email from John Moy (circa July 2001) > http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0107&L=OSPF&D=0&I=-3&P > =15162 > and another more recent one from me in response to your email on your > alternate-te proposal > http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0212&L=OSPF&D=0&I=-3&P > =6031 > > Best, > --rohit. > (OSPF WG co-chair) > > ::The draft is a solution to providing TE within an OSPF area. > ::The draft has serious scalability limitations in > ::extending this to inter-area and mixed networks (with TE and > ::non-TE nodes). Please see my comments below. I would not > ::recommend using this draft as the basis for building further > ::TE-extensions to inter-area and mixed networks. > :: > ::The draft apparently evolved over time with no requirements > ::document to guide it. The vendors and implementors behind the > ::draft may have been guided by different set of requirements > ::and motivations, such as having some working code. Unfortunately, > ::this ad-hoc approach has a cost. Any new requirements are having > ::to be met in a reactive mode and having to be provided as fixes > ::on top of this "working" code. This is not right and doesnt bode > ::well for the future of the protocol. > [snip] > >
Re: a personal opinion on what to do about the sub-ip area
Paul, > Er, toning down the rhetoric a bit, it is worthwhile to ask two questions: > - Does keeping the WGs in one area help significantly? > - Does keeping the WGs in the IETF help significantly? I think it would be worthwhile to ask the following three questions: 1. Are we discussing whether to shut down asap the WGs that are presently in the sub-IP area ? 2. Are we discussing whether to move these WGs from one area to another, while making sure that such move would have no impact on the work that is going on in these WGs ? 3. Are we discussing whether it would be possible to shut down the WGs that are presently in the sub-IP area without stating this explicitly by dissolving the sub-IP area and moving these WGs to some other areas ? Yakov.
Re: IETF Sub-IP area: request for input
[clipped...] > Discussions about the options: > > 1/ Move WGs (back) to permanent areas and close the area > > For: > > Each WG within SUB-IP definitely has a strong feature that maps it to a > given permanent area [1]. The property that logically holds them together > in SUB-IP now is the need for coordination wrt the technologies that are > normally considered below the IP layer. While this was indeed necessary > right after SUB-IP creation, DP4 suggests that the goal has been achieved > and the focus is shifting back to coordination with permanent areas (e.g., > DP3, as well as the fact that RTG WGs are already dealing with SUB-IP > related extensions). DP1 suggests that there will be about three active > WGs within a year; at least two of them can be argued to belong in RTG > area (where they originally came from, see DP2), so it wouldn't make a > lot of sense to have two separate areas overlapping so considerably. > PPVPN does not map strongly to any area, however it doesn't map strongly > to SUB-IP either (MPLS is just one possible encapsulation method) > > Against: > > DP5 suggests that the feeling in the room was against closing the area, > though there was also some support for the idea that moving MPLS and > CCAMP to RTG would be a fine idea if the area were to be closed. The > feeling was that the area has been working and that there is no strong > argument that there is a need to change things at this time. > > > > 2/ Establish a long-term area > > For: > > DP5 suggests that the community believes this is a good idea. See also > the "Against" for option 1. In addition the opinion was expressed that > having a specific area with specifically assigned management, > knowledgeable in the field, would be an advantage. In addition, new > SUP-IP work may develop in the future and it would be good to have a > home for it. > > Against: > > See "For" arguments for option 1 above. Also, there was an assumption > when the area was formed that it would be temporary and the size of the > IESG is near max effective size. It is also expected that if the nomcom > needs to find an AD(s) for SUB-IP, the set of required skills would > be extremely similar to those needed for the RTG area, which again > brings up the question of whether it makes sense to have two areas > with so similar expertise scopes. > > > 3/ Status quo > > For: > > DP5 suggests that the way the area operates is fine and does not need > fixing at this time. As DP1 predicts, there may not be many active > SUB-IP working groups within a year and it may be best to wait until > a few of the working groups finish their work and close before deciding > on the long term direction for this work. The IESG would decide which > ADs would be asked to manage the area in March. > > Against: > >A decision has to be made sooner or later, delaying the decision will > not make it any easier to make. > > > The IESG would like to hear from the community on this topic - please > direct your comments to the [EMAIL PROTECTED] list. Option 2 would be fine. Option 3 would be ok too. Yakov.
Re: IPv6: Past mistakes repeated?
Steve, > >> There was a similar discussion here about five years ago where some > >> people proposed market models for address allocation and routing. > >> Unfortunately, it's not in the archives. > > > >I think it was on CIDRD, actually, no? > > > >> If anyone has this discussion archived, could they please point me to > >> it? > > > >Well, one thing I do have is the draft of: "Suggestions for Market-Based > >Allocation of IP Address Blocks", by Paul Resnick (then of AT&T Research, I > >don't know where he is now - Paul, you out there?), which I have at: > > > >http://ana-3.lcs.mit.edu/~jnc/tech/addr_charging.txt > > > >It never turned into an RFC (shame, I thought it was a really well thought > >out draft), and I don't think it's anywhere else permanent. > > See http://www.research.att.com/~smb/papers/piara/index.html, by Paul, > Yakov Rekhter, and myself. This paper was also published in in "Coordination the Internet", MIT Press, 1997 (Rekhter, Y., Resnick, P., Bellovin, S., "Financial Incentives for Route Aggregation and Efficient Address Utilization in the Internet"). Yakov.
Re: IP network address assignments/allocations information?
Noel, > > From: Ed Gerck <[EMAIL PROTECTED]> > > > maybe this is what the market wants -- a multiple-protocol Internet, > > where tools for IPv4/IPv6 interoperation will be needed ... and valued. > > This relates to an approach that seems more fruitful, to me - let's try and > figure out things that sidestep this incredibly divisive, upsetting and > fundamentally unproductive argument, and try and find useful things we can do > to make things work better. > > > Which can, undoubtably, be put in a sound theoretical framework for > > NATs, in network topology. NATs do not have to be a hack. > > Well, the fundamental architectural premise of NAT's *as we know them today* - > that there are no globally unique names at the internetwork level - is one > which is inherently problematic (long architectural rant explaining why > omitted). So I don't think that the classic NAT model is a good idea, > long-term. I would say that the fundamental architectural premise of NATs is that globally unique names at the internetwork layer are not carried in the network layer header. This is not to say that such names don't exist - just that they aren't in the IP header. Yakov.
Re: IP network address assignments/allocations information?
Perry, > Jon Crowcroft <[EMAIL PROTECTED]> writes: > > >>Having said that, I ask you: What do you foresee as a realistic IPv6 > > >>transition plan? Dual stacks? I don't see it happening, to tell you > > >>the truth. (Maybe this 6-in-4 stuff will actually help here.) > > > > well, how about we just start to turn it on in some routers? - it works > > in most host OSs now, dual stack, just fine. > > > > the value of the net is the square of the number of people connected - > > NAT is a square root function. > > NAT has actually created a simple transition plan for us. > > I'd say at this point that 95% of the corporate networks in the > U.S. use private addressing and a NAT or proxy box at the > border. Switching from this to using v6 internally with a v6 to v4 > NAT/proxy at the border for communicating with v4 is trivial -- since > they don't have globally routable addresses now, they won't be hurt by > the switch. > > As more and more people switch to this configuration, they'll start > finding themselves talking to more and more things over the net > natively, and fewer and fewer through the translator. Suddenly, > they'll discover they *do* have globally routable addresses again, > just like we did in the old days before net 10 was turned into the > universal addressing ghetto. This could go as you described *until* these folks would start to move from one provider to another, and therefore will be faced with the need to renumber. At that point NAT could become quite an attractive alternative from cost/benefit point of view again. And now these folks will be back to where they've been with IPv4, but but with the extra cost of IPv4 to IPv6 transition. Yakov. P.S. While one could argue that renumbering with IPv6 could be made simpler than with IPv4, what one really needs to compare is renumbering with IPv6 vs renumbering with NAT.
Re: IP network address assignments/allocations information?
Perry, > Brian E Carpenter <[EMAIL PROTECTED]> writes: > > Well, let's not focus on Bill's data. Frankly, I haven't seen any data > > on this topic from any source that really convinces me that it > > means much. All I know is that we have thousands of sites using > > private address space, which completely falsifies any real data and > > makes it impossible to attach any real meaning to concepts such as > > "running out of addresses". My personal opinion is that we ran out > > of addresses in practical terms around about when RFC 1597 was published. > > I hate to start a flame war, but Brian is absolutely right. I have > clients spending gargantuan amounts of money dealing with layer upon > layer of NATs because of this. Some people believe that "we aren't > running out of address space" but the fact is that we've already run > out. It just isn't available for many essential purposes. Consider an alternative where the client decides to use IPv6. Granted, the client could get enough IPv6 addresses for all purposes, regardless of whether these purposes essential or not. But then in order for that client to communicate with the rest of the folks, the client would likely to use NAT (as the rest of the folks would still use IPv4). So, the cost of using NAT wouldn't go away. But in addition, this alternative would cause the client to swallow the cost of transition from IPv4 to IPv6 in its infrastructure. Yakov.
Re: To address or NAT to address?
Brian, > > Christian, > > > > > Increasing our reliance on the DNS is definitely not a good idea. > > > > Hmmm. This would appear to be the exact opposite of what the IETF has done > > with IPv6. > > > > Rgds, > > -drc > > Well now. There is some truth in that (A6 records are quite complex...) > but NAT has generated some serious and complex dependencies on DNS too, > not to mention various load sharing techniques. With this in mind I hope that the same folks who complained about increased dependencies on DNS by NATs, would be equally vocal in complaining about increased reliance on the DNS by IPv6 (which claimed to be an improvement over NATs). Yakov.
