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,
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
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
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
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:
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
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
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
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
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
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 -
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[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
/~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
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
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
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
33 matches
Mail list logo
