Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing)

From: "Bound, Jim" <[email-masked]>
Date: Sat, 3 May 2003 23:47:40 -0400

> Bound, Jim wrote:
> > The entire working group did decide this is not going to be
> > resolved and we cannot agree hence they should be deprecated 
> > for now and that is the consensus.  Your view is invalid here 
> > not the Chairs. /jim
> 
> I have a hard time believing that you of all people would 
> have agreed that 'somewhere to the left ...' and 'have to 
> hand wave ...' were adequate definitions of the question. 
> Exactly what is the plan to replace non-provider controlled 
> address space, since the working group has never been able to 
> agree on any other approach? Forcing all sites into 
> provider-only space will guarantee that they deploy nat to 
> isolate themselves from the whims of the provider.

On the contrary.  Until we can define their use, their limitations, I
advise all customers for IPv6 to use Global Addresses for all
communications and that Link-Local are for systems link node
infrastructure only really.  Get in the habit of using Global Addresses
again.  The illusions propogated by the IPv4 NAT bandaid should be
destroyed and I intend to keep doing that and that was caused by IPv4
private address space because IPv6 was not deployed fast enough.  That
being said I also discuss clearly and in depth the future potential of
IPv6 multi-scoped address potential architecturally, from implementing a
stack I can tell them exactly the complexities the developers face and
then the use of that benefit on a node and within a routing system.

The "yes" vote for me was very clear from the Chairs question.  My yes
vote was for the following.  I believe we cannot resolve the issue of
site-local addresses today (in part because we do not have our minds
around the entire implementation of scoping) and because of that for NOW
(not forever) the IETF standards process should deprecate their use.  

Bottom line is users should not use them.

I don't agree with you that customers will do as you say.  The reason is
that most vendors now are well equipped and well educated on the
absurdity of using private address space without rules and in particular
that their limitation be known.  NAT was evil and that is clear to all
now who advise and becoming more clear to users.  That will cause them
much hesitation for private address use.

Our consensus here will put the nail in the coffin for site-locals TODAY
not forever.

You have lost this battle and should give it up and go work with those
who believe we need this and bring us a proposal that will make it safe
for them to be deployed on the Internet.  If the WG buys into the
proposal and we can move forward with many wanting to work on it again
then we revisit it again.  But for now they are dead and filerbusting is
not going to change anything in the IETF is my strong hope here.  All
the arguments have been heard and we have nothing that is nailed down or
agreed to.

Respectfully,
/jim

> 
> Tony
> 
> > 
> > > -----Original Message-----
> > > From: Tony Hain [mailto:[email-masked]]
> > > Sent: Monday, April 28, 2003 9:44 PM
> > > To: 'Thomas Narten'; 'Erik Nordmark'
> > > Cc: [email-masked]; 'Bob Hinden'; 'Margaret Wasserman'
> > > Subject: RE: Your Appeal Regarding Site-Local Deprecation
> > > (Was: Consensus on Site-Local Addressing)
> > > 
> > > 
> > > Thomas & Erik,
> > > 
> > > I trust that you will take a more objective view of this, because 
> > > any outsider who needs to watch that video will be rolling in the 
> > > isles with laughter at the absurdity of the process abuse in this 
> > > case. At least 5 long-time IETF participants (including yourself) 
> > > felt the need to state what they meant by 'deprecate SL'. 
> One has to 
> > > assume they bothered to assert their interpretation because the 
> > > YES/NO question was unclear to them, or that their need 
> to explain 
> > > which question they were answering is an implicit statement that
> > > the original question was unclear. Even though the question 
> > > never changed, none of the (amazingly vague) clarifying 
> > > remarks in SF were sent to the list version of the consensus call.
> > > 
> > > If a legal professional were to watch the proceedings here, they 
> > > would comment that the WG gave the chairs the freedom to 
> interpret 
> > > the meaning of the question any way they choose. In fact we have 
> > > examples of that already on the mail list and in this response.
> > > 3/30 chair email claimed
> > > > As part of deprecating site-local addressing, we
> > > > agreed in the meeting that, in addition to  deprecating 
> site-local 
> > > > addressing in the addressing architecture and removing it from 
> > > > other  places (scoped addressing architecture, address 
> selection 
> > > > rules, etc.), a document would be  written that would do two 
> > > > things:
> > > >
> > > >         - Explain why site-local addressing was deprecated
> > > >         - Outline alternative means to address some of the
> > > >                 problems that could have been solved by
> > > >                 site-local addressing.
> > > 
> > > That question was never asked of the room, and those 
> statements were 
> > > not made by the chairs in SF. How could there be an agreement?
> > > 
> > > > The decision to deprecate site-local addressing,
> > > > rather than simply removing it, was made to avoid
> > > > harm to IPv6.
> > > 
> > > There was nothing more to this than vague conversations between 
> > > Margaret & Keith, and Margaret & Thomas. There was no decision by 
> > > the WG, just a chair proclamation that one had occurred. We can't 
> > > allow the WG process to degenerate to the point that a chair can 
> > > call an ambiguous YES/NO question, then make up anything 
> they choose 
> > > to have it mean later. In particular, when the chair explicitly 
> > > states '... if we eliminate it we will also have multiple choices 
> > > about what exactly that means ...', and '... may have to 
> hand wave 
> > > ...' there is not a clear indication about what question is being 
> > > asked.
> > > 
> > > I put specific rebuttal comments to the chair's rejection 
> in a list 
> > > response to the chairs. In summary I believe the chairs have 
> > > declared a consensus when there really wasn't one due to the 
> > > ambiguity of the question. Specifically the YES votes for 
> removing 
> > > addresses with local scope from the architecture or 
> consideration by 
> > > applications are void, as that is not something the IETF gets to 
> > > decide. Had the chairs asked Keith's original question 
> about finding 
> > > an alternate way forward through replacement 
> technologies, we would 
> > > not be going through this process.
> > > 
> > > As for a path forward, I would expect you to invalidate the 
> > > consensus, then have the WG stop the pronouncements that 
> SL is dead, 
> > > and work on finding appropriate replacements. This effort 
> must begin 
> > > with identification of the requirements for addresses of local 
> > > scope, and under local network manager control. With 
> requirements in 
> > > hand, the scoped address architecture document needs to 
> specifically 
> > > deal with handling mixed scope addresses, both between and for
> > > simultaneous use on a singe node. That document in particular 
> > > is hopelessly gutted and meaningless without such a 
> > > discussion. IF we get to the point were all requirements are 
> > > met by alternatives, the current SL definition should 
> > > appropriately be moved to historic. If not, it will likely 
> > > end up in the corner case use that Keith was trying to 
> > > achieve. Either way, the entire WG must decide exactly what 
> > > happens. We must not allow the 'ambiguous YES/NO question - 
> > > chairs subsequently decide what it means', process to set a 
> > precedent.
> > > 
> > > Tony
> > > 
> > > 
> > > 
> > > 
> > > Margaret Wasserman wrote:
> > > > Hi Tony,
> > > > 
> > > > We have considered your appeal regarding the IPv6 WG 
> consensus to 
> > > > deprecate site-locals.  Based on our analysis, we believe 
> > that your 
> > > > appeal makes the following points:
> > > > 
> > > >    (1) You believe that deprecating IPv6 site-local unicast
> > > >        addressing is an incorrect technical choice that places
> > > >        the work output of the IPv6 WG in jeopardy.
> > > > 
> > > >    (2) You believe that the question asked by the chairs
> > > >        was insufficiently clear to be understood properly
> > > >        by the WG.
> > > > 
> > > >    (3) You do not believe that there is rough consensus to
> > > >        deprecate IPv6 site-local addressing, because people
> > > >        provided different reasons for why they believe that
> > > >        IPv6 site-local addressing should be deprecated.  In
> > > >        particular, some people want to deprecate the particular
> > > >        model of site-local addressing defined in the scoped
> > > >        addressing architecture (ambiguous, scoped addresses),
> > > >        while others do not believe that we need a local
> > > >        addressing mechanism at all.
> > > > 
> > > >    (4) You believe that it is invalid for the IPv6 WG to
> > > >        deprecate site-local addressing without publishing an
> > > >        IPv6 WG document that analyzes the operational 
> requirements
> > > >        for local addressing.  Without this analysis 
> document, you
> > > >        believe that the IPv6 WG has made an uninformed choice.
> > > > 
> > > > We will now respond to each of your points.
> > > > 
> > > > --
> > > > 
> > > > Point (1):
> > > > 
> > > > The chairs do not believe that deprecating IPv6 site-local 
> > > > addressing is an incorrect technical decision that will 
> place the 
> > > > work output of the IPv6 WG in jeopardy.
> > > > 
> > > > The consensus was to "deprecate" the usage of site-local 
> > addressing 
> > > > instead of simply removing it. This was done purposely to avoid 
> > > > interference with any current implementations or 
> deployments that 
> > > > might use site-local addressing.  In addition to the 
> time it will 
> > > > take to formally deprecate site-local addressing by 
> publishing an 
> > > > RFC, the WG understands that it will take some time after the 
> > > > publication of an RFC for implementations to change.  The 
> > decision 
> > > > to deprecate site-local addressing, rather than simply removing
> > > > it, was made to avoid harm to IPv6.
> > > > 
> > > > In fact, we believe that the previous disagreement over 
> > the usage of 
> > > > IPv6 site-local addressing was damaging to the WG, and 
> > that our lack 
> > > > of consensus was delaying our work, particularly on the 
> > IPv6 scoped 
> > > > addressing architecture.  The consensus to deprecate site-local 
> > > > addressing will allow us to move forward and complete our work.
> > > > 
> > > > ---
> > > > Point (2):
> > > > 
> > > > The question was:
> > > > 
> > > >      "Should we deprecate IPv6 site-local unicast
> > > >      addressing?"  Possible answers were YES or NO.
> > > > 
> > > > The chairs believe that this question was sufficiently 
> clear to be
> > > > understood by the WG.  This is supported by the following
> > > > points:
> > > > 
> > > >      - Over 200 people responded to the question.
> > > > 
> > > >      - Many of the responses on the list (both YES and NO
> > > >        responses) included reasons or comments that
> > > >        followed from the question in a way that indicated
> > > >        that the responders understood the question.
> > > > 
> > > >      - There were only three requests for clarification of
> > > >        this consensus call on the mailing list, two of which
> > > >        were procedural.  All of these requests were answered
> > > >        promptly by the chairs.
> > > > 
> > > >      - The chairs sent the consensus results to the list
> > > >        over two weeks ago, including a course of action for
> > > >        the deprecation of site-local addressing.  There
> > > >        have been no objections from people who originally
> > > >        expressed YES opinions that the chairs' course of
> > > >        action fails to match their expectations.
> > > > 
> > > > ---
> > > > 
> > > > Point (3):
> > > > 
> > > > The chairs do not believe that consensus on an issue is 
> > invalidated 
> > > > by the fact that people have multiple reasons for coming 
> > to the same 
> > > > conclusion.  We suspect that this happens in most WG consensus 
> > > > calls, and this is not a reason to invalidate the consensus.
> > > > 
> > > > All of the groups that you mentioned in your message 
> agreed that 
> > > > IPv6 site-local unicast addressing should be 
> deprecated. They may 
> > > > disagree on what we should do after deprecating
> > > > site- local addressing, but that does not invalidate the
> > > > consensus on this point.
> > > > 
> > > > ---
> > > > 
> > > > Point (4):
> > > > 
> > > > It is true that the IPv6 WG has not produced a WG document that 
> > > > analyzes the operational requirements for local addressing.  
> > > > However, we do not believe that this is a reason to 
> > invalidate the 
> > > > IPv6 WG consensus to deprecate IPv6 site-local unicast 
> addressing.
> > > > 
> > > > There has been considerable discussion and analysis of 
> > site- local 
> > > > addressing performed over the past year, including extensive 
> > > > discussions during three IETF sessions.  There have also been 
> > > > several drafts published on the subject, including one 
> draft that 
> > > > attempts to analyze the cost/benefit trade-offs of site-local 
> > > > addressing.
> > > > 
> > > > This period of discussion has offered sufficient time for 
> > anyone who 
> > > > has an operational need for any of the currently-defined usage 
> > > > models of site-local addressing to document those 
> > requirements in an 
> > > > Internet-Draft and/or to discuss those requirements on the IPv6 
> > > > mailing list.
> > > > 
> > > > During our discussions, several operational benefits of 
> > site-local 
> > > > addressing have been raised on the IPv6 WG mailing list, 
> > including 
> > > > benefits for disconnected sites,
> > > > intermittently- connected sites, renumbered sites, etc.  We
> > > > have also uncovered several issues and complexities caused by 
> > > > the current model of ambiguous, scoped site-local addressing, 
> > > > and we have determined that this particular model places 
> > > > burdens on other parts of the TCP/IP protocol suite, 
> > > > particularly routing protocols and applications.
> > > > 
> > > > In a recent phone discussion and in your appeal 
> > clarification, you 
> > > > have indicated that the chairs should void responses from 
> > people who 
> > > > do not think that the IPv6 WG should specify any type of local 
> > > > addressing mechanism, because you believe that those 
> > responders are 
> > > > uninformed about the operational conditions that require 
> > the use of
> > > > local addressing.
> > > > 
> > > > While operational necessity is certainly an appropriate 
> > argument to 
> > > > raise in support of your position that the IPv6 WG 
> should specify 
> > > > some mechanism for local addressing, the fact that you 
> > disagree with 
> > > > the reasons that some people offered for why they want to 
> > deprecate 
> > > > the current IPv6 site-local unicast addressing 
> mechanism does not 
> > > > invalidate their contribution to this consensus call.
> > > > 
> > > > It is the opinion of the chairs that the IPv6 WG did have 
> > sufficient 
> > > > information to make an informed decision regarding 
> > whether or not to 
> > > > deprecate IPv6 site-local unicast addressing.
> > > > 
> > > > ---
> > > > 
> > > > So, to summarize, the chairs do not agree with the points 
> > that you 
> > > > have raised in your appeal, and we do not agree to overturn the 
> > > > consensus of the IPv6 WG based on the issues that you 
> have raised.
> > > > 
> > > > Tony, while we disagree with your position on this 
> > particular issue, 
> > > > we do respect your contributions to the IPv6 effort and 
> > we realize 
> > > > that your appeal is motivated by your desire to do the 
> > right thing 
> > > > for IPv6.  We hope that you will accept our response to 
> > your appeal 
> > > > and focus on working to define the local addressing problem and 
> > > > solutions as we outlined in our email to the list. We 
> think it is 
> > > > important for the working group to move forward on this issue.
> > > > 
> > > > Best Regards,
> > > > 
> > > > Bob Hinden & Margaret Wasserman
> > > > IPv6 WG Chairs
> > > > 
> > > > 
> > > > 
> > --------------------------------------------------------------------
> > > > IETF IPng Working Group Mailing List
> > > > IPng Home Page:                      
> > http://playground.sun.com/ipng
> > > > FTP archive:               
> >        ftp://playground.sun.com/pub/ipng
> > > > Direct all administrative requests to 
> > [email-masked]
> > > > 
> > --------------------------------------------------------------------
> > > > 
> > > 
> > > 
> > > 
> --------------------------------------------------------------------
> > > IETF IPng Working Group Mailing List
> > > IPng Home Page:                      
> http://playground.sun.com/ipng
> > > FTP archive:               
>        ftp://playground.sun.com/pub/ipng
> > > Direct all administrative requests to 
> [email-masked]
> > > 
> --------------------------------------------------------------------
> > > 
> > 
> > --------------------------------------------------------------------
> > IETF IPng Working Group Mailing List
> > IPng Home Page:                      http://playground.sun.com/ipng
> > FTP archive:                      ftp://playground.sun.com/pub/ipng
> > Direct all administrative requests to [email-masked]
> > --------------------------------------------------------------------
> > 
> 
> 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 4 May 2003 00:54:17 -0400

Below we have no real clue for IPv6 SLs :--)
/jim

> From: Bound, Jim 
> Sent: Sunday, May 04, 2003 12:51 AM
> To: 'Michel Py'
> Cc: [email-masked]
> Michel,
> > Bottom line is that nobody tells me what to do on my network
> > and certainly not the IETF.
> 
> I completely agree.  The IETF is in the business of defining 
> standards that may or may not be used in the real world.  For 
> the effort of defining the standard for SLs we are at an 
> impasse and for many years, thus we have decided to deprecate 
> them for now until a proposal/plan exists.  That is a prudent 
> and logical action.
> 
> Users can do whatever they want and vendors too. 100% agree.  
> That is not the issue or has anything to do with this 
> decision in the IETF, as standards body.
> 
> If I did not like the decision and believed it was important 
> for users I would tell them to ignore the IETF.  I have done 
> that in a few very rare cases and will do it again if 
> necessary.  If you believe that you should do the same and 
> that's fine.
> 
> But we have made a decision and we should stand by it and 
> move on here.  That is more imporant than SLs to this IETF at 
> this time.  We cannot continue to debate what has clear 
> consensus and this one does.  It is going to kill the IETF 
> and a major large problem with this standards body that has 
> to be fixed and this discussion is prime example of the problem.
> 
> > 
> > 
> > > I don't agree with you that customers will do as you say.
> > 
> > Maybe you should listen more to customers, because the have,
> > they are and they will.
> 
> I do daily and about IPv6.  They want to never deal with NAT 
> again.  They also want real security which private address 
> space does not give them unless they have no links to the 
> outside Internet anywhere within their network.
> 
> I advise any user I speak with not to use them, except at 
> their own risk.  They will not just blindly use SLs I simply 
> do not agree.  They are well aware of our indecisive 
> conclusions and their use within this effort in the IETF if 
> not directly then indirectly.
> 
> Until we define their use and scope within an IPv6 network 
> there is no logical use for them by any user.  Other than a 
> false belief in securing their network.  Once that belief is 
> shown to be false (and it has by many now) the reasons for 
> private addresses become illogical and only emotional.  And 
> emotion is not a good plan for a business decision. Any user 
> that sees that will not decide in favor of emotion.
> 
> We should be talking about scoping of network link partitions 
> not SLs and once we have that understood address scoping 
> besides LLs and Globals will be clearer.  Why not have 
> Org-Locals, or Dept-Locals. Etc?   The reason is we do not 
> technically understand their use or limitations within the 
> IPv6 architecture, there has been no running code at one bake 
> off to verify they do not break network connectivity for 
> multisited nodes or cause security faults as just two 
> examples. With Globals and LLs we have a clue.  We have no 
> real clue for IPv6 only a few theories and cannot get 
> consensus on that so we deprecate them for now.
> 
> Private addresses in IPv4 are NOT the same as Private 
> Addresses in IPv6.  In IPv6 it creates an address and network 
> partition scoping abstraction we simply have not completed 
> our thought processes on and why I believe it prudent 
> technically to deprecate them for now. 
> 
> Can you point me to a public test bed (not private vendor) 
> that has made extensive use of SLs with IPv6 and verified 
> their use as we have for Globals and LLs in any IPv6 test bed 
> in Asia, Europe, or North America?
> 
> Or if you know of stuff going on out of our intra-planetary 
> system that is fair too :--)
> 
> /jim
> 
> 
> > 
> > Michel.
> > 
> > 
> > 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 7 May 2003 08:24:53 -0400

I would suggest this is a valid use of Link-Local addresses on the
backplane.  Why would that not work and I would use when we have scoping
figured out in this case.  Esp for CompactPCI?

/jim

> From: Bhaskar S [mailto:[email-masked]] 
> Sent: Monday, May 05, 2003 1:36 PM
> To: [email-masked]
> Cc: Bound, Jim; Michel Py
> Subject: Re: Your Appeal Regarding Site-Local Deprecation 
> Hi,
> I have seen some network boxes which use ethernet as the 
> backplane. Say for example using J4/P4 of CompactPCI. In this 
> case one would like to have a private address space for the 
> backplane. So that any outsider would not be able to see the 
> internals of the boxes.
> 
> I am wondering how we would setup IP address for the 
> backplane interfaces of these boxes in the current scenario? 
> 
> Any suggestions?
> 
> "Bound, Jim" wrote:
> > 
> > Michel,
> > 
> > > Bottom line is that nobody tells me what to do on my network and 
> > > certainly not the IETF.
> > 
> > I completely agree.  The IETF is in the business of 
> defining standards 
> > that may or may not be used in the real world.  For the effort of 
> > defining the standard for SLs we are at an impasse and for 
> many years, 
> > thus we have decided to deprecate them for now until a 
> proposal/plan 
> > exists.  That is a prudent and logical action.
> > 
> > Users can do whatever they want and vendors too. 100% 
> agree.  That is 
> > not the issue or has anything to do with this decision in 
> the IETF, as 
> > standards body.
> > 
> > If I did not like the decision and believed it was 
> important for users 
> > I would tell them to ignore the IETF.  I have done that in 
> a few very 
> > rare cases and will do it again if necessary.  If you 
> believe that you 
> > should do the same and that's fine.
> > 
> > But we have made a decision and we should stand by it and move on 
> > here. That is more imporant than SLs to this IETF at this time.  We 
> > cannot continue to debate what has clear consensus and this 
> one does.  
> > It is going to kill the IETF and a major large problem with this 
> > standards body that has to be fixed and this discussion is prime 
> > example of the problem.
> > 
> > >
> > >
> > > Maybe you should listen more to customers, because the have, they 
> > > are and they will.
> > 
> > I do daily and about IPv6.  They want to never deal with NAT again. 
> > They also want real security which private address space 
> does not give 
> > them unless they have no links to the outside Internet 
> anywhere within 
> > their network.
> > 
> > I advise any user I speak with not to use them, except at their own 
> > risk.  They will not just blindly use SLs I simply do not 
> agree.  They 
> > are well aware of our indecisive conclusions and their use 
> within this 
> > effort in the IETF if not directly then indirectly.
> > 
> there is no 
> > logical use for them by any user.  Other than a false belief in 
> > securing their network.  Once that belief is shown to be 
> false (and it 
> > has by many now) the reasons for private addresses become illogical 
> > and only emotional.  And emotion is not a good plan for a business 
> > decision. Any user that sees that will not decide in favor 
> of emotion.
> > 
> > We should be talking about scoping of network link 
> partitions not SLs 
> > and once we have that understood address scoping besides 
> LLs and Globals
> > will be clearer.  Why not have Org-Locals, or Dept-Locals. 
> Etc?   The
> > reason is we do not technically understand their use or limitations 
> > within the IPv6 architecture, there has been no running code at one 
> > bake off to verify they do not break network connectivity for 
> examples. With 
> > Globals and LLs we have a clue.  We have no real clue for 
> IPv6 only a 
> > few theories and cannot get consensus on that so we 
> deprecate them for 
> > now.
> > 
> > Private addresses in IPv4 are NOT the same as Private Addresses in 
> > IPv6. In IPv6 it creates an address and network partition scoping 
> > abstraction we simply have not completed our thought 
> processes on and 
> > why I believe it prudent technically to deprecate them for now.
> > 
> > Can you point me to a public test bed (not private vendor) that has 
> > made extensive use of SLs with IPv6 and verified their use 
> as we have 
> > for Globals and LLs in any IPv6 test bed in Asia, Europe, or North 
> > America?
> > 
> > Or if you know of stuff going on out of our intra-planetary system 
> > that is fair too :--)
> > 
> > /jim
> > 
> > >
> > > Michel.
> > >
> > >
> > >
> > 
> Bhaskar S.
> 978-858-2896 (o)

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 7 May 2003 08:27:26 -0400

When the xxPCI or backplane requires communication off the back plane to
say another back plane over a network  I would argue if on the same link
the LLs work still but if off-link then use globals and secure your
network.

/jim

> Sent: Monday, May 05, 2003 3:01 PM
> Cc: Michael Thomas; Bound, Jim; Michel Py
> Hi Mike,
> Yes I feel you are correct. 
> 
> My understanding is that link-local address are not global 
> addresses (pl correct me if I am wrong). To use it I should 
> not be connected to the internet.
> 
> I'll need to block these addresses from getting into the internet.
> 
> Michael Thomas wrote:
> > 
> > Bhaskar S writes:
> >  > Hi,
> >  >
> backplane. 
> > Say  > for example using J4/P4 of CompactPCI. In this case 
> one would 
> > like to  > have a private address space for the backplane. 
> So that any 
> > outsider  > would not be able to see the internals of the boxes.  >
> >  > I am wondering how we would setup IP address for the backplane
> >  > interfaces of these boxes in the current scenario?
> > 
> > Link locals wouldn't suffice?
> > 
> >             Mike
> 
> -- 
> Best Regards,
> 
> Bhaskar S.
>

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 7 May 2003 08:25:32 -0400

Why not please explain I know this space fairly well on my day job?
/jim

> From: Michael Thomas [mailto:[email-masked]] 
> Sent: Monday, May 05, 2003 2:07 PM
> To: Bhaskar S
> Cc: [email-masked]; Bound, Jim; Michel Py
> backplane. Say  > for example using J4/P4 of CompactPCI. In 
> this case one would like to  > have a private address space 
> for the backplane. So that any outsider  > would not be able 
> to see the internals of the boxes.  > 
> backplane  > interfaces of these boxes in the current scenario? 
>