headers
Joe Abley | 1 Jul 18:45

Re: draft-ietf-multi6-multihoming-requirements-03


On Wednesday, June 26, 2002, at 04:00 , Joe Abley wrote:

> On Wednesday, June 26, 2002, at 03:29 , Tony Hain wrote:
>
>> While I believe this document still assumes too much in terms of
>> affecting policy outside the domain of direct administrative control, I
>> have to agree it is time to ship it. There is one comment about the 
>> IESG
>> in 3.2.7 that simply doesn't belong in any I-D, so I wouldn't be
>> surprised when the IESG asks to have it changed or removed. If the 
>> words
>> 'within the IESG' were removed, the sentence would stand and makes much
>> more sense than worrying about IETF process in a mechanism requirements
>> doc.
>
> I have made that change in my working copy.

Does anybody have any other proposed changes to this document, or should 
I roll a -04 with that change only, ready for wg last call?

Joe
Permalink | Reply | 17 comments |
headers
Iljitsch van Beijnum | 1 Jul 20:04
Favicon

Re: draft-ietf-multi6-multihoming-requirements-03

On Mon, 1 Jul 2002, Joe Abley wrote:

> >> If the words
> >> 'within the IESG' were removed, the sentence would stand and makes much
> >> more sense than worrying about IETF process in a mechanism requirements
> >> doc.

> Does anybody have any other proposed changes to this document, or should
> I roll a -04 with that change only, ready for wg last call?

There seems to be a discrepancy between the requirements listed in the
draft and the fact that everyone assumes there won't be a solution that
can meet all of them. I'm afraid this opens up the possibility of problems
down the road when people can easily dismiss otherwise promising
multihoming solutions by pointing out it doesn't meet one or more
requirements.

Some text indicating which requirements are absolutely essential and which
are also important, but can be dropped if there aren't any multihoming
solutions that satisfy them would be good, I think.

On the other hand: I certainly don't want to slow down the whole process.

Iljitsch van Beijnum
Permalink | Reply | 11 comments |
headers
Masataka Ohta | 1 Jul 19:54
Picon

Re: draft-ietf-multi6-multihoming-requirements-03

Joe Abley;

> Does anybody have any other proposed changes to this document, or should 
> I roll a -04 with that change only, ready for wg last call?

Can't we simply admit the fact that none of us have any operational
experience to be able to discuss multi6 requirement document
to be used later to evaluate proposals and move on without it?

						Masataka Ohta
Permalink | Reply | 4 comments |
headers
Joe Abley | 1 Jul 20:06

Re: draft-ietf-multi6-multihoming-requirements-03


On Monday, July 1, 2002, at 01:54 , Masataka Ohta wrote:

> Joe Abley;
>
>> Does anybody have any other proposed changes to this document, or 
>> should
>> I roll a -04 with that change only, ready for wg last call?
>
> Can't we simply admit the fact that none of us have any operational
> experience to be able to discuss multi6 requirement document
> to be used later to evaluate proposals and move on without it?

Are you suggesting there are no network operators here?
Permalink | Reply | 3 comments |
headers
Joe Abley | 1 Jul 20:05

Re: draft-ietf-multi6-multihoming-requirements-03


On Monday, July 1, 2002, at 02:04 , Iljitsch van Beijnum wrote:

> Some text indicating which requirements are absolutely essential and 
> which
> are also important, but can be dropped if there aren't any multihoming
> solutions that satisfy them would be good, I think.

Do you have such text to incorporate?

> On the other hand: I certainly don't want to slow down the whole 
> process.

Joe
Permalink | Reply | 10 comments |
headers
Masataka Ohta | 1 Jul 20:08
Picon

Re: draft-ietf-multi6-multihoming-requirements-03

Joe Abley;

> >> Does anybody have any other proposed changes to this document, or 
> >> should
> >> I roll a -04 with that change only, ready for wg last call?
> >
> > Can't we simply admit the fact that none of us have any operational
> > experience to be able to discuss multi6 requirement document
> > to be used later to evaluate proposals and move on without it?
> 
> Are you suggesting there are no network operators here?

No, I am not, as I am involved in operation of mobile IPv6 network
with more than 150 routers.

					Masataka Ohta
Permalink | Reply | 1 comment |
headers
Joe Abley | 1 Jul 20:25

Re: draft-ietf-multi6-multihoming-requirements-03


On Monday, July 1, 2002, at 02:08 , Masataka Ohta wrote:

> Joe Abley;
>
>>>> Does anybody have any other proposed changes to this document, or
>>>> should
>>>> I roll a -04 with that change only, ready for wg last call?
>>>
>>> Can't we simply admit the fact that none of us have any operational
>>> experience to be able to discuss multi6 requirement document
>>> to be used later to evaluate proposals and move on without it?
>>
>> Are you suggesting there are no network operators here?
>
> No, I am not, as I am involved in operation of mobile IPv6 network
> with more than 150 routers.

Ah, I understand the point you were making, then. Sorry for my confusion.

Joe
Permalink | Reply | 0 comments |
headers
Eric Gauthier | 1 Jul 20:33
Gravatar

Re: draft-ietf-multi6-multihoming-requirements-03

> >> Does anybody have any other proposed changes to this document, or 
> >> should
> >> I roll a -04 with that change only, ready for wg last call?
> >
> > Can't we simply admit the fact that none of us have any operational
> > experience to be able to discuss multi6 requirement document
> > to be used later to evaluate proposals and move on without it?
> 
> Are you suggesting there are no network operators here?

Ok, I've been lurking for a while, but here are my $0.02.  I'm a 
network architect at a large university.  We're testing IPv6 on our
campus and intend to multihome with our pTLA.  We currently multihome 
with our IPv4 address space and had issues that we've solved regarding 
multihoming, especially in cases of Internet 1 versus Internet 2 traffic.  
So, just in case anyone is worried, there are people lurking here that 
do ops and not just people who are curious about the theoretical workings 
of IPv6.  

Secondly, IMHO, we've laid out what we think are requirements and there
doesn't appear to be anything in there that's unreasonable to hope for 
and expect.  Its now up to the brainiac's in round two to come up with a 
solution.  Just because I can't think of one doesn't mean that someone 
else won't.  But, if it turns out that someone does a proof that our 
requirements are mutually exclusive or no one is able to come up with a 
solution, we'll then have the experience of those who tried to work it 
out to determine what, specifically, is the largest subset of our draft 
that can be implemented or where we went wrong.  Until we get that 
concrete feedback, we're only guessing at what can and cannot be done.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean Doran | 1 Jul 20:54

Re: draft-ietf-multi6-multihoming-requirements-03


| Can't we simply admit the fact that none of us have any operational
| experience to be able to discuss multi6 requirement document
| to be used later to evaluate proposals and move on without it?

I would hope that whatever forum evaluates any proposals from
any body dealing with the IPv6 site multihoming problem, that
"working code" is weighted at least as heavily as "rough consensus".

If you think you have working code that might not survive 
scrutiny based on the emerging rough consensus over the
requirements drafts, *now* is the time to suggest changes.

	Sean.
Permalink | Reply | 2 comments |
headers
Sean Doran | 1 Jul 21:00

Re: draft-ietf-multi6-multihoming-requirements-03


| We're testing IPv6 on our campus and intend to multihome with our pTLA.  

I (personally speaking) love text that describes actual operational
experience when it comes to describing things in the context of the
Ops area.  I am sure that if you wrote something up and posted it
here, the audience would be appreciative, even if it's unclear whether
this could be a venue for a formal publishing of some of your
experiences as a multi-homed site.

	Sean.
Permalink | Reply | 0 comments |

Gmane