Subject: Re: [Isis-wg] draft-ietf-isis-restart-01.txt

From: Naiming Shen <[email-masked]>
Date: Tue, 18 Jun 2002 15:40:27 -0700

Mike,

 ] I have retained the non-timer resetting behavior of the RR IIH because I 
 ] think it is useful in some cases but have noted that if you want the 
 ] resetting behavior you can easily get this by sending a normal IIH once you 
 ] have acquired the necessary circuit IDs etc. So the way it would work is 
 ] that you would re-start and get back the remaining time on each adjacency. 
 ] If this is plenty of time you just carry on as normal. If you feel you need 
 ] more time (and you are configured to allow that), then you send an IIH with 
 ] the required holding time.

I still have problem of this. yes, you may be able to send out "normal"
IIHs with large holdtime, but that's an extra step. i don't see much
reasoning this step is needed; Also more importantly, you may not be
able to send this  "normal" IIH over a LAN unless you are sure you got
all the neighbors without missing one. this is too much dependancy
without benefit.

I can understand you don't want to change the current tlv format, since
it's out there for a while and there may be some implementations running
which can cause incompatibility. I would say let's just keep this format.
the helper still send back whatever it thinks the holdtime is for this
adjacency. We at least need to say that, if the implementation choose
to ignore the holdtime in the re-start IIH, it SHOULD offer a config
knob so this can be disabled when needed. This way ISPs can make sure
its consistant within the network. We have already seen some
implementation does NOT ignore this holdtime at least for the first
re-start IIH.

 ] 
 ] 	Similarly, I have retained the retries, but said that you may
 ] configurea  retry count of zero.

This does not matter too much comparing to the above. this is basically
a local implementation issue. Probably should mentioning the p2p vs
LAN problems here.

thanks.
- Naiming
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg

---

From: mike shand <[email-masked]>
Date: Fri, 21 Jun 2002 09:46:54 +0100

>implementation does NOT ignore this holdtime at least for the first

This seems reasonable. So we return the actual holding time with the RA and 
use the minimum of those as the time we have left to get re-synched. That 
way it doesn't matter whether a neighbor resets the adjacency holding time 
or not. AS long as it tells us the result we are cool.

         Mike

---

From: Naiming Shen <[email-masked]>
Date: Mon, 24 Jun 2002 13:04:13 -0700

] At 15:40 18/06/2002 -0700, Naiming Shen wrote:
 ] 
 ] >Mike,
 ] >
 ] >  ] I have retained the non-timer resetting behavior of the RR IIH because 
I
 ] >  ] think it is useful in some cases but have noted that if you want the
 ] >  ] resetting behavior you can easily get this by sending a normal IIH 
 ] > once you
 ] >  ] have acquired the necessary circuit IDs etc. So the way it would work i
s
 ] >  ] that you would re-start and get back the remaining time on each 
 ] > adjacency.
 ] >  ] If this is plenty of time you just carry on as normal. If you feel you 
 ] > need
 ] >  ] more time (and you are configured to allow that), then you send an IIH 
 ] > with
 ] >  ] the required holding time.
 ] >
 ] >I still have problem of this. yes, you may be able to send out "normal"
 ] >IIHs with large holdtime, but that's an extra step. i don't see much
 ] >reasoning this step is needed; Also more importantly, you may not be
 ] >able to send this  "normal" IIH over a LAN unless you are sure you got
 ] >all the neighbors without missing one. this is too much dependancy
 ] >without benefit.
 ] >
 ] >I can understand you don't want to change the current tlv format, since
 ] >it's out there for a while and there may be some implementations running
 ] >which can cause incompatibility. I would say let's just keep this format.
 ] >the helper still send back whatever it thinks the holdtime is for this
 ] >adjacency. We at least need to say that, if the implementation choose
 ] >to ignore the holdtime in the re-start IIH, it SHOULD offer a config
 ] >knob so this can be disabled when needed. This way ISPs can make sure
 ] >its consistant within the network. We have already seen some
 ] >implementation does NOT ignore this holdtime at least for the first
 ] >re-start IIH.
 ] 
 ] This seems reasonable. So we return the actual holding time with the RA and 
 ] use the minimum of those as the time we have left to get re-synched. That 
 ] way it doesn't matter whether a neighbor resets the adjacency holding time 
 ] or not. AS long as it tells us the result we are cool.

exactly. thanks.

 ] 
 ]          Mike
 ] 
 ] 
 ] >  ]
 ] >  ]      Similarly, I have retained the retries, but said that you may
 ] >  ] configurea  retry count of zero.
 ] >
 ] >This does not matter too much comparing to the above. this is basically
 ] >a local implementation issue. Probably should mentioning the p2p vs
 ] >LAN problems here.
 ] >
 ] >thanks.
 ] >- Naiming
 ] 

- Naiming