[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
Zafar at al,
After having seen the discussion during CCAMP and having re-read
the draft, I support this action for the draft.
The draft provides a rather useful clarification, which would be good
to record.
-Vishal
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of zafar ali
> Sent: Thursday, March 11, 2004 11:14 PM
> To: 'Kireeti Kompella'
> Cc: ccamp@ops.ietf.org; 'Adrian Farrel';
> Dimitri.Papadimitriou@alcatel.be; 'Reshad Rahman'; 'Danny Prairie'
> Subject: 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.
> >=====================================================================
> >
> >
>