[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, 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 : 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