The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

Julia,

    In general, you should not direct questions that relate to
a specific implementation to this list.  Please see below for
answers to those of your questions that are more general in
nature.

--
Eric Gray

You wrote:

> Hi,
>
> I have several questions for the rsvp te.
>
> 1.  after Ingress sends out the pathtear msg to tear down the connection
> and path state,  the Egress sends out the resv msg out, the ingress should
> send out the resverr msg back with error code #3 "no path information for
> this resv msg".   But I observed that, the Ingress router does not send
> this error msg back, can any one tell me if the ingress route was not
> implemented properly?

A router should reject a Resv message if it has no corresponding Path
state.  If you find this isn't the case, talk to the router's vendor.

>
>
> 2.  rsvp te 09.txt section 4.3.4.1, 'Bad explicit router object'.   Can
> anyone tell me how this error will be sent out?

There are a lot of minor inconsistencies in how error responses are
described through-out the document.  For example, mostly with the
exception of all of section 4.3, the process is described as sending
a specific (either PathErr, or ResvErr) message with a specific code
and value.  For another, capitalization is fairly inconsistent - i.e. -
"Unknown Object Class" may be "unknown object class" in one
case and "Unknown object class" in another; or "Bad Explicit Route
Object" might be "Bad EXPLICIT_ROUTE Object".

You should be able to figure it out.  Section 4.5 lists all of the ERO
and RRO error codes and values.  You can then substitute the error
given in:

'The node sends a PathErr message with an error code of "routing
problem" and an error value of "_________________________".'

Fill in the blank above with the specific explicit routing error stated
in the specification.  Note that it will always be the case that a
PathErr message is used to complain about an ERO.

>
>
> 3.  accordint the draft, if Ingress router sends out the path msg with
> multiple session attributes.only the first session attribute will be
> forwarded.  But I observed that the interLSR will drop the path msg with 2
> session attributes.  Can anyone tell me why?

The wording in the specification is loose enough to allow an implementer
to interpret it this way.  If they do, however, they are not observing a basic
principle of robustness since they are not being liberal in what they accept.
Again, bring this up with the specific vendor.

>
>
> 4.  I observed that the Egress tried to tear down the resv state and sends
> out the resvtear to interLSR, according to the spec, the InterLSR suppose
> to forward the resvtear msg if there is no merge, just ingress -----
> InterLSR ------Egress.  Can anyone tell me why?
>
> 5.  Suppose there is A   ---- B ----C, how can A let B knows that the C is
> the non-rsvp capable, and then when A sends out the path msg, the B will
> send out the path error msg back and inform that there is non-rsvp on the
> way?    C can send out the resv msg with ttl in common header different
> from the ip header ttl, and let B knows that C is non-rsvp, but I observed
> that when A sends out the path msg again after this, B does not send out
> patherr msg with error 'mpls being negotiated, but there is non-rsvp
> capable router stands in the path'.   why?
>
> 6.  Can anyone point me out how the 'bad strict/loose node' error will be
> generated?, suppose I have A--B--C, and A sends out the path msg with ero
> as {b, c}, so if the second subobject is unknown address instead of C, and
> the ero type is strict, then the bad strict node error msg should be send
> out from B, but I did not see this error, instead, B sends out the 'no
> route aviable to the destination", then how the 'bad strict/loose
> node'error will be generated.

See the rest of section 4.3.4.1 - particularly bullets numbered 5a and 5b.

>
>
> Thanks for your pointing.
>
> Julia