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

["zafar ali" <zali@cisco.com>]

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: owner-ccamp@ops.ietf.org 
>[mailto:owner-ccamp@ops.ietf.org] On Behalf Of 
>Dimitri.Papadimitriou@alcatel.be
>Sent: Friday, February 06, 2004 11:17 AM
>To: zafar ali
>Cc: ccamp@ops.ietf.org
>Subject: Re: comments on 
>draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
>
>
>hi, some comments on this document that would imho
>beneficiate from the community
>

Thanks, 

>>>   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
>

Agreed, we will. 

>>>   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

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.  

>
>>>   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.
>

This is also an implementation specific detail.  

>>>   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

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

>
>>>   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 : dimitri.papadimitriou@alcatel.be
>E-mail : dpapadimitriou@psg.com
>Webpage: http://psg.com/~dpapadimitriou/
>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>Phone  : +32 3 240-8491
>
>

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