Re: comments on rsvp-te-06

[Zhi-Wei Lin <zwlin@lucent.com>]

Hi Lou, See in-line

Lou Berger wrote:

>> In section 7.2.1, both step 3 are the same description.
> 
> 
> yes, this is intentional!
> 

But then what you're saying is that for ingress-initiated teardown, the 
flow is:
(1) Path
(2) Resv
(3) PathTear

While egress initiated it is:
(1) Resv
(2) PathTear


This means that ingress-initiated takes 3 message passes. In OIF UNI 
1.0, a different message flow is defined for ingress-initiated, that of:
(1) Path
(2) PathErr (with Path_State_Removed flag set)

Is this latter message flow allowed, and if not, why not?


>> Based on the
>> flow of description, I think the first step 3 should read:
>> "Upon receiving the Admin Status Object with the Delete (D) bit set in
>> the Path message, the egress node sends a PathErr message (with
>>      ^^^^              ^^^^^^              ^^^^^^^         ^^^^^
>> Path_State_Removed flag set) upstream to remove the LSP and normal RSVP
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> processing takes place."
> 
> 
> The egress triggers the ingress to do the delete.
> 


See above. Actually, based on the original text, the ingress triggers 
the egress which then triggers the ingress to do the delete...seems like 
extra level of message...I thought that's one reason for defining the 
Path_State_Removed flag for PathErr...


>> In section 9.1, a statement under "recovery time":
>>         A value of 0xffffffff indicates that resynchronization may
>>           occur at a rate selected by the receiver.
>> while in section 9.5.2, the following statement is made:
>>         A Recovery Time value of 0xffffffff indicates that the
>>         Recovery Period is effectively infinite.
>> which is correct? or am I misinterpreting this?
> 
> 
> These statements are mutually consistent.  If you'd like, I can just 
> remove the text, but I think most will find the comment useful.
> 


I see the consistency now. You should keep the text.

Thanks
Zhi