Subject: RE: [DNA] Ideas for ethernet section of draft-ietf-dna-link-information

From: Alper Yegin <[email-masked]>
Date: Fri, 27 May 2005 13:52:44 -0700

Greg,

Going back to your 802.3 text....

Reading your text, my understanding is:

- The host MUST learn if the adjacent port is running STP or RSTP.
- The additional delay is 0 if STP/RSTP is not detected. Delay is
learned from the RSTP/STP signaling when present.
- The link up MUST be generated "delay" seconds after
PMA_LINK.indicate(OK).
- The link down MUST be generated immediately after
PMA_LINK.indicate(FAIL).

Is that right?

You text uses "may"s. If you agree, we shall update it with the "MUST"s
as above.

Alper

---

From: JinHyeock Choi <[email-masked]>
Date: Sat, 28 May 2005 09:36:58 +0900

Dear DNA Group

We submitted the following draft as a solution work. 

DNA Solution: Link Identifier based approach
draft-jinchoi-dna-protocol2-00.txt

As Brett mentioned, two approaches were discussed 
in DT, Landmark based & Link Identifier based. 

The draft presents the second one and describes how
to check for link change with the prefix based linkid.   

Routers pick the smallest prefix as the linkid prefix and 
include the linkid prefix in every RA. In short, if a host 
sees the same linkid prefix, it is at the same link and if it 
sees a different linkid prefix, it has moved to a new link.  

This document is available at the URL:

http://www.diffeo.com/drafts/draft-jinchoi-dna-protocol2-00.txt

We are looking forward to your feedback.

Best Regards

JinHyeock Choi

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 29 May 2005 10:30:23 -0700 (PDT)

In IETF last call for the DNAv4 document, a question was raised about the
behavior of routers with respect to ARP Probes (ARP Request with sender
address = 0.0.0.0)

If you have been involved in a router implementation, please answer the
following questions and send the answers to me:

a. After booting and configuring interface addresses, does your
   implementation answer ARP Probes for its address?

b. When a static IPv4 address is assigned on an interface, what does your
   implementation do prior to using the address?

    1. Does nothing, just uses the address.
    2. Sends an ARP Announcement (otherwise known as "Gratuitous ARP")
    3. Broadcasts an ARP Reply
    4. Sends an ARP Probe (ARP Request for the address, with sender
       address = 0.0.0.0)
    5. Behaves as specified in draft-cheshire-ipv4-acd-03.txt
       (multiple ARP probes followed by ARP Announcement)

c. If your implementation behaves as specified in the acd document, how
   does it behave if it receives an ARP probe for its address during the
   period in which it is probing for that same address?

    1. Interprets the probe as indication of an address conflict and stops
       using the address.
    2. Logs the conflict but does not stop using the address.
    3. Ignores the probe.

---

From: Greg Daley <[email-masked]>
Date: Mon, 30 May 2005 10:53:44 +1000

Hi Alper,

> learned from the RSTP/STP signaling when present.

I guess that if the delay is 0 there's still a likelihood
that the event is wrong (it degrades the hint).
Since a lot of ports may default to a proprietary 'port fast'
environment like Cisco's it may be OK in many cases.

Since you don't know which port you're connected to, you can't know
at zero time whether or not the port is up for data forwarding.

If you were to get a subsequent hint:

"forwarding available at time+t (by the way, the last hint was broken)",
then there may actually be a case for retransmission (for DNA),
but damage could have already been done to upper-layer flows which
may need retransmission of data (the same issue exists when DNA
has not yet completed).

I'd guess that this is OK (re-hinting), so long as there's
information in the draft illustrating the issue.

> - The link up MUST be generated "delay" seconds after

I don't think this is possible, unless there's an
immediate signal at zero time (which may constitute a
degraded indication),

> - The link down MUST be generated immediately after

Immediately after fail sounds good.

> You text uses "may"s. If you agree, we shall update it with the "MUST"s

There are some serious issues since there's no beacon for ethernet
before you connect to identify the peer.

I'll cogitate on this for a little while.
Comments welcome.

Greg

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 29 May 2005 23:14:52 -0700 (PDT)

> before you connect to identify the peer.

Not necessarily.  There may be beacons from 802.1AB.

---

From: Syam Madanapalli <[email-masked]>
Date: Mon, 30 May 2005 17:47:03 +0530

Hi JinHyeock,

Here few comments and questions on your draft.

1. The draft does not talk about the scenario where there exists a mix of
    modified and unmodified routers.

2. Section 3.1.

        ........
         A router, when it boots or is configured to act as a router (Sec
         6.2.2 in RFC 2461 [1]), first sends an RS and waits for RAs to
         gather prefixes.

       ........

         Once that process is complete, the router will send RAs and
         respond to RSs, but not before that.

   These two statements are conflicting. Is the RS from routers is
   different from Hosts?

   According to one of your statements the routers do not respond to
   RSs unless the process of LinkID establishment is completed. So how
   Does initial RS/RA exchange happen between routers? Or am I missing
   some thing here.

3.  Section 3.2
        ........
         In case the new prefix smaller than the current linkid prefix is
        advertised in LPIO, the router doesn't change the linkid prefix.

   Are you saying if a router receives a new smaller prefix in LPIO, then
   the router will not change the linkid? In other words routers change 
linkid
   if and only of they receive a new smaller prefix in PIO.

   If this is true, then I think there will be some inconsistency in linkids
   being advertised by different routers on the link for some time and slows
   down the linked establishment process.

   Also, is there any reason for not to count LPIOs?

4. What if the life time of all the prefixes that are available falls
   below 3 hours? May be a rare case, but I am wondering if it is worth
   mentioning about this scenario.

5. The host receives RA with different linkid prefix than the host
   is having, the host need to check for the complete prefix list against
   the host linkidprefix list. This is similar to CPL except that the host 
is
   not trying to learn about complete prefix list and now the host does this
   comparison only when it sees a different linkid.

6. I am wondering what could be the disadvantage if we keep the
   Linkid prefix even if we see the new prefix that is smaller.
   I think it is better to keep the same linkid as far as possible.
   If the current Linkid prefix life time does not allow us to keep
   it as linkid prefix, then we can switch to next available smaller
   prefix.
   In this approach the new router that comes up, does not apply the
   algorithm to select a new linked, if it sees a linked (PIO/LPIO with
   'I' flag set). The new router simply takes the received linked as
   the linked for the link.

   I think this way we avoid lot of processing and we will have smaller
   linkidprefix list on the host side.

7. Section 3.4.3

        ........

        For example, assume a router R advertise the linkid prefix P1 and 
the
        second smallest prefix is P2.

       When the valid lifetime of P1 is 7 days, R wants to remove P1 from 
the link.
        If R immediately advertises an RA with 1) P1 with zero lifetime and
       2) P2 with I-bit set, hosts may treat this as a link change, because
        they would discard P1 entirely when seeing it with zero lifetime.

   In this example, is the prefix P2 is also being advertised when P1
   is the linkid prefix? If yes, then a host receives a P1 with zero life 
time,
   it can easily find out that it is still on the same link but the prefix 
P1
   is not valid any more.

   I can see one problem: If Host receives another RA from another router
   with P1 as the linkid, then host think that it has moved, as the host
   discarded the P1 completely because of the earlier RA.

8. And also I am wondering, why we cannot use the longest valid prefix time 
as
   the selector for the linkid prefix. I think this is better because, this 
way
   linkid will be valid for more time.

Thank you,
Syam

---

From: JinHyeock Choi <[email-masked]>
Date: Tue, 31 May 2005 09:21:02 +0900

Dear Syam

Thanks for your kind and detailed feedback. Kindly find my in-line 
comments. 

>     modified and unmodified routers.

This is a very good point. 

Though that case is not explicitly mentioned, I had that in mind 
while design the protocol. That's why hosts make no decision 
when receiving an RA having no linkid prefix. It will work even 
in such an environment. 

>    Does initial RS/RA exchange happen between routers? Or am I missing

My writing may not be clear. When a router is booted, after sending 
3 RSs, i.e. waiting 12 secs, the router starts advertising its RAs, even if 
no RA arrives. 

>    if and only of they receive a new smaller prefix in PIO.

Yes. 
 
>    being advertised by different routers on the link for some time 

Yes. 

>    and slows

Even it slows down the linkid convergence, it will not affect 
DNA performance. 
 
>    Also, is there any reason for not to count LPIOs?

We thought it's more reliable to rely only on PIO information. 

>    mentioning about this scenario.

Then this will not work and hosts need to fall back on CPL. But I 
guess we can safely sweep this under the carpet. :-)  
 
>    comparison only when it sees a different linkid.

Yes. Christian's comment on CPL showed me how similar linkid scheme is 
to CPL. 

There is one more difference as below. 

In CPL, a host compares 
the set of prefixes in the receiving RA with 
its Completer Prefix List.  

In linkid, a host compares
the set of prefixes in the receiving RA with 
its LinkidPrefixList. 
 
>    linkidprefix list on the host side.

In DT, we had a discussion w.r.t. the linkid convergence. We decided 
that it would be much reliable if routers select their linkid prefix by 
themselves without consulting what other routers advertise as a linkid 
prefix. 
 
We were afraid of ping-pong effect. Router 1 advertise a linkid prefix 1
and Router 2 a linkid prefix 2, then they keep changing their prefixes. 

The above is a kind of "Phantom Menace" (:-)) without showing the 
definite problem. 

But a menace anyway and we try to avoid not only tangible problems 
but also even the possibility of a problem. 

So in the proposed scheme, routers would not take into consideration
the linkid prefix in the RA it receives from the other routers. 
 
>    it can easily find out that it is still on the same link but the prefix 

In the linkid scheme, to check for link change hosts use only the 
prefixes in LinkidPrefixList. 
 
>    discarded the P1 completely because of the earlier RA.
 
Right. 

>    linkid will be valid for more time.
 
In fact, we can use any algorithm which will give a definite prefix from 
the set of prefixes on the link.

The problem with 'the longest valid prefix time' is that there may be
multiple prefixes having the same valid prefix time. Then we need 
an additional decision scheme.  

Thanks in advance for your kind consideration. 

Best Regards

JinHyeock

---

From: Subba Reddy <[email-masked]>
Date: Tue, 31 May 2005 09:55:59 +0530

Hi JinHyeock Choi,

Please find my comments in-line.

> when receiving an RA having no linkid prefix. It will work even

I think it is useful to look into the RA sent by the unmodified router,
to see if it is advertising the linkid prefix (obviously no I bit is
available)
so that host can make a decision that it is still on the same link.

> 3 RSs, i.e. waiting 12 secs, the router starts advertising its RAs, even
if

Take a case where more than one router boots up, if the routers are not
replying
for RSs (not sending RAs) during initial 12 seconds, then they will
configure different
linkids and it may take some more time to converge.

If the link is coming up, routers chosing the linkid based on the prefixes
it is advertising
is same as waiting for 12 seconds other than the delay in the later case
(because routers
will not come to know each others prefixes)

> an additional decision scheme.

Even though one more decision is required, if we select linkid
based on life time, then linkids may not change frequently
because of life time expiry.

Thanks & Regards,
Subba Reddy

---

From: JinHyeock Choi <[email-masked]>
Date: Tue, 31 May 2005 20:03:39 +0900

Dear Subba Reddy

Thanks for your kind feedback. 

> so that host can make a decision that it is still on the same link.

This will work for the most of cases but may cause problem 
w.r.t. flash renumbering and early reassignment, which is 

> will not come to know each others prefixes)

Eventually the linkid will converge and I expect there will be no 
flapping. I put this as an open issue 006.  

> because of life time expiry.

Usually I guess that the most prefixes are configured the default 
valid lifetime, 30 days. Prefixes are not changed so often. So I 
expect it will work fine even if we don't choose the longest lifetime 
prefix. 

Best Regards

JinHyeock