Subject: Re: comments on draft-ali-ccamp-rsvp-node-id-based-hello-00.txt

From: [email-masked]
Date: Fri, 06 Feb 2004 17:17:20 +0100

hi, some comments on this document that would imho
beneficiate from the community

>>   Another scenario which introduces the need for node-id based Hellos
>>   is when nodes support unnumbered TE links. Specifically, 
>>when all TE
>>   links between neighbor nodes are unnumbered, it is implied that the
>>   nodes will use node-id based Hellos for detecting node 
>>failures. This
>>   draft also clarifies the use of node-id based Hellos when all or a
>>   sub-set of TE links are unnumbered.
>>
>>DP: the key point is "is the router id used to identify the te 
>>link the same as the one used for the hello's ?"
>  
> Yes, the same router-id/ node-id is used. 

ok, that's what i wanted to know and i would propose to
include the above sentence in this i-d

>>   When link level failure detection is performed by some means other
>>   than RSVP Hellos (e.g., [BFD]), the use of node-id based Hellos is
>>   also optimal for detection of nodal failures.
>>
>>DP: pin point that this is a particular case, it's not a nodal 
>>failure but a RSVP-TE signaling adjacency failure, RSVP-TE 
>>signaling controller failure, 
> 
> Agreed! this is more precise statement. 

ok, thanks

>>note that if this session is 
>>maintained and is used as the IP channel for all messages then 
>>it MAY also be used as "nodal failure"
>>
>>   An implementation may initiate a node-id based Hello 
>>session when it
>>   starts sharing RSVP states with the neighbor or at an earlier time.
>>
>>DP: i don't understand what you mean here
>>
> What we meant here is that an application may not run RSVP Hello session
> all the time. It may initiate one when it has an application (e.g., when
> for GR when it start sharing states with the neighbor. 

this is an interesting statement to be considered in the
scope of this document

>>   Similarly, an implementation may use the IGP topology to determine
>>   the remote node-id which matches an interface address(es) used in
>>   RSVP signaling. These aspects are considered to be a local
>>   implementation decision.
>>
>>DP: how is this possible since you're using the router_id 
>>being the router_address advertized as top level te link 1 in ospf_te
>>
>  
> In Inter-area and inter-AS case, this information is assumed to come via
> configuration. Is this what you meant here? 

the above sentence introduces an issue once the interface
is in failure state, i would provide more details here wrt
to real expectations behind the above paragraph either it
is implementation specific w/o impact on neighbors or it
has and then would suggest some details on the last part.

>>   When a node receives a Hello packet where the destination 
>>IP address
>>   is its local node-id as advertised in the IGP-TE topology, the node
>>   MUST use its node-id in replying to the Hello message. In other
>>   words, nodes must ensure that the node-ids used in RSVP Hello
>>   messages are those derived/contained in the IGP-TE topology.
>>   Furthermore, a node can only run one node-id based RSVP 
>>Hello session
>>   with its neighbor.
>>
>>DP: well here in fact you have a real issue because, a may 
>>have several node_id's on a node, so what you want to say is 
>>"one per node_id pair"
> 
> Yes, in the cases when router is participating multiple topologies (OSPF
> & ISIS). But AFAIK router can only advertsie ONLY one address in a given
> IGP instance. 
> 
> We need to make statement clear for multiple IGP instances case. Is this
> is what you meant? 

exactly

>>   If all interfaces between a pair of nodes are unnumbered, 
>>the optimal
>>   way to use RSVP to detect nodal failure is to run node-id based
>>   Hellos. Similarly, when link level failure detection is 
>>performed by
>>   some means other than RSVP Hellos, use of node-id based Hellos is
>>   also optimal in detecting nodal failures. Therefore, if all
>>   interfaces between a pair of nodes are unnumbered or when 
>>link level
>>   failure detection is performed by some means other than 
>>RSVP Hellos,
>>   a node MUST run node-id based Hellos for node failure detection.
>>
>>DP: this is not true, i can run LMP, but a MUST for the 
>>signaling adj. maintenance
>>
>  
> Yes, we can clarify it in the next version. 

thanks,
-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

---

From: "zafar ali" <[email-masked]>
Date: Fri, 6 Feb 2004 15:25:19 -0500

Hi Dimitri, 

Thanks for your comments and feedback. I have in-lined some new
comments. 

As I mentioned in my earlier email that we will take care of these
comments in the next version of the document. 

Thanks again for your feedback. 

Regards... Zafar

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>[email-masked]
>Sent: Friday, February 06, 2004 11:17 AM
>To: zafar ali
>Cc: [email-masked]
>Subject: Re: comments on 
>draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
>
>

Thanks, 

>include the above sentence in this i-d

Agreed, we will. 

>> What we meant here is that an application may not run RSVP Hello 
>> session all the time. It may initiate one when it has an application 
>> (e.g., when for GR when it start sharing states with the neighbor.
>

No, these details are implementation specific. The related para was
included in the ID as a reference (to avoid confusion on how node-id's
can be obtained.). Nonetheless, as you would agree that this is
implementation specific detail, and hence is outside the scope of the
ID.  

>> In Inter-area and inter-AS case, this information is assumed to come 
>> via configuration. Is this what you meant here?
>

This is also an implementation specific detail.  

>> Yes, in the cases when router is participating multiple topologies 
>> (OSPF & ISIS). But AFAIK router can only advertsie ONLY one 
>address in 
>> a given IGP instance.
>> 
>> We need to make statement clear for multiple IGP instances case. Is 
>> this is what you meant?
>
>exactly

This is a good point. New text will be updated based on your comment. 

>> Yes, we can clarify it in the next version.

=====================================================================
Zafar Ali, Ph. D. 				  100 South Main St.
#200,
Technical Leader, 				  Ann Arbor, MI 48104,
USA.
Cisco Systems.					  (734) 276-2459.
=====================================================================