[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comments on draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
Hi Lou, Rahul, et al,
As mentioned in the CCAMP WG, we are in the process of publishing a
modified version of the ID based on earlier comments from Dimitri, et
al. As I saw Lou and Rahul at the microphone for questions, which we
were not able to address due to time constraints, we would like to
request for your comments at the list.
Thanks
Regards... Zafar
>-----Original Message-----
>From: owner-ccamp@ops.ietf.org
>[mailto:owner-ccamp@ops.ietf.org] On Behalf Of zafar ali
>Sent: Friday, February 06, 2004 3:25 PM
>To: Dimitri.Papadimitriou@alcatel.be
>Cc: ccamp@ops.ietf.org
>Subject: RE: comments on
>draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
>
>
>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.
>=====================================================================
>
>