Subject: RE: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies

From: NJEDJOU Eric RD-RESA-REN <[email-masked]>
Date: Wed, 27 Oct 2004 18:02:28 +0200

In the same respect,
 the sentence "Today, a link change necessitates an IP configuration change." in the dna goals document introduction let the reader believe that a node would not be having interfaces attached to other links. Because if it is so, then the a configuration that might have been built on the non used link could start being used  without requiring new IP configuration. 

Is it possible to recall the definition of the word link in that dna goal document? Copy-paste from RFC 2461.... 

Eric 
regards

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Pekka Nikander
Envoyé : lundi 25 octobre 2004 08:59
À : Dna
Cc : Erik Nordmark; YGHONG; ???; Greg Daley; JinHyeock Choi; ???
Objet : Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies

>> I think that the case 3.2, 'Single interface with Make before Break'
>> will affect DNA solution design. I agree that we are not familiar 
>> with this case, so it would be of much help, if you elaborate the 
>> below with more detail.
>>
>>                 ... But in CDMA[7], a
>>      mobile station can access two or more different base stations
>>      simultaneously. In this case, a host can make a new link-layer
>>      connection before an old link-layer connection is torn down.
>
> I hope that L2 can actually tell the packets apart.
> If this is possible, then the implementation could present the packets 
> from the different links are arriving on different interfaces to IP.

I agree with Erik and others that the apparently cleanest way is to model the situation with distinct (virtual) interfaces, each corresponding to a wireless connection.

However, I am also wondering how often we need that in practise.
As far as I've understood (which may be completely wrong), in the typical case the CDMA network models the whole base station network as a single link, with a single excess router.  OTOH, I have no idea whether soft handovers between operators is defined or not.
If they are, then we probably need some care there.

Taking a slightly wider angle, we can imagine various anomalies like someone inadvertedly connecting two (wireline) LAN segments together.  That would (temporarily) create a similar situation.
Hence, I'm afraid that we need to make the DNA scheme(s) robust against these kinds of situations.  However, my current opinion (subject to change) is that we should not worry too much about these kinds of situations, and it would be perfectly OK if it takes some more time to system to recover in such a situation.  In other words, if some hosts unnecessarily run DNA and autoconfiguration, that wouldn't be too bad.

Network operators have to live with the limits of technology anyway.  If our DNA effort results in a piece of technology that has a number of well documented limitations, that is OK, as long as the WG agrees on the limitations.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 27 Oct 2004 22:41:28 +0300

Eric,

<chair hat on>

The DNA goals document has been passed to the IESG.  We already
had the WG LC, resolved the comments, and as the comments were
mostly editorial in nature, passed the document to the IESG.

Do you feel that we should pull the document back?  (I am not
saying that I am willing to do that, I just want to understand
how strongly you feel about your comments.)

<chair hat off>

> Actually the DNA scheme would better not be the same depending on  
> wether i am able to attach to more than one link or not. Effectively,  
> if i am attached for instance to two links at the same time, i may not  
> need to go into the DNA process whenever i receive a hint that one of  
> those links (L2 or L3) is no more valid, if i am able to switch my  
> flows onto the other link without noticeable service interruption  
> (after checking that my IP configuration on that other link is valid).
>
> This is why i do not really like the sentence
> "DNA schemes are typically run per interface.  When a host has
>    multiple interfaces, the host separately checks for link changes on
>    each interface."
> As said in the introduction of the dna goals document. I think DNA  
> would better run on an overall basis i.e seeing all of the links  
> (which my Ip layer is capable of for that matter).

We discussed this already, see e.g.
http://webcamserver.eng.monash.edu.au/~warchive/dna/2004-09/ 
msg00019.html
and the messages before and after that.

I don't quite understand how your comment is different from what
Erik and I discussed?  I originally more or less felt like you,
but after some consideration came to the conclusion that the
complications that would result are not worth the effort.

However, for the related reasons we added the word "typically" to
the above sentence, among other things.

On Oct 27, 2004, at 19:02, NJEDJOU Eric RD-RESA-REN wrote:

> In the same respect,
>  the sentence "Today, a link change necessitates an IP configuration  
> change." in the dna goals document introduction let the reader believe  
> that a node would not be having interfaces attached to other links.  
> Because if it is so, then the a configuration that might have been  
> built on the non used link could start being used  without requiring  
> new IP configuration.

I don't understand this comment.  The document says pretty clearly
that you _typically_ do DNA per interface.  Hence, if you link changes,
you _typically_ run DNA on the interface attached to that link, and
not on others.  What am I missing?

> Is it possible to recall the definition of the word link in that dna  
> goal document? Copy-paste from RFC 2461....

I don't understand this comment either.  We are referring to 2461.
What is wrong with that?

--Pekka