[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 Kireeti, Adrian, et al
This is a follow-up on Kireeti's comment on the above mentioned draft
during the last CCAMP WG meeting. I looked through the
http://www.ietf.org/rfc/rfc2026.txt, which states about BCP sub-series:
(BCP sub-series) "is a vehicle by which the IETF community can define
and ratify the community's best current thinking on a statement of
principle or on what is believed to be the best way to perform some
operations or IETF process function." RFC2026, Section5, page 16.
We think that draft-ali-ccamp-rsvp-node-id-based-hello-00.txt fits this
definition quite well. It does NOT define any protocol extensions and
only formalizes use of node-id based RSVP Hello sessions. In the revised
version we would like to position the draft as a BCP.
Comments will be appreciated.
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.
>=====================================================================
>
>