> We would like to work with the following simple example, where
node A is not
> the ingress, but C is the egress. We've done some
interop testing, and
> found that in some cases EROs which we considered
valid did not work, while
> others produced unexpected results.
>
> Nodes: A--------B--------C
>
Interfaces: A1 B1 B2 C1
>
D/S Labels L1
L2
>
> Which of the following EROs, received in a Path message by
Node A, would
> produce the LSP pictured?
>
> (a)
{A1,L1};{B2,L2}
This is acceptable because (we assume) the Session identifies C as the
destination. It might, however, be construed as unhelpful to prematurely
terminate the ERO.
We can treat it exactly as case (b)
> (b) {A1,L1};{B2,L2};{C1}
> (c) {B1,L1};{C1,L2}
Note that this is illegal according to RFC3209 4.3.4.1 1)
If the node is not part of the abstract node
described
by the first subobject, it has
received the message in error and
SHOULD
return a "Bad initial subobject" error.
The ERO received by A MUST contain a first subobject that identifies A in
some manner.
This is policed by A.
> (d) {A1,L1};{B1,L1};{B2,L2};{C1,L2}
With the exception that it would be good for the ERO to begin with an
incoming interface on A or some other _expression_ of A (for example {A}), this
qualifies as the belts and braces (aka suspenders) approach. Note, however, that
it is not necessary to duplicate the labels because they will be processed on
the upstream node (creating a Label Set object).
Thus {A};{A1,L1};{B1};{B2,L2};{C1} might be nice.
> Further, if some of these configurations are not allowed, where is
that
> typically policed?
>
> Regarding option (c), it
appears that some vendors expect this construction,
> but we're not clear
how it can be accurately interpreted. If it is valid,
> how can node
A know whether B1 is the incoming or outgoing interface on node
> B (and
therefore whether is has to process label L1)? If it is not valid,
>
can this be policed?
In order the discuss this, we must assume that the ERO looked
like {A};{B1,L1};{C1,L2}
A's job is to route to the abstract node identified by the next
subobject.
Thus, it must route to B1. One may assume that in a normal topology it will
not try to do this through B2.
Further, A is not supposed to look beyond the first non-local sub-object.
Therefore, the DS label will not be processed until the ERO reaches B. This is
not the end of the world because it is a DS label and is in the purview of node
B.
It is, however, perhaps easier to consider the case where upstream labels
are used as well. This makes life a little clearer, because the US label MUST be
processed by the US node. So the ERO {A};{B1,L1,L1'};etc. would not cut the
mustard.
In fact, RFC3473 is quite clear in the intention that label subobjects (for
DS labels) should be mapped to Label Set objects. This means that they must be
processed by the US node. This in turn means that they must be present in a
subobject immediately following an outgoing interfcase subobject.
So, option (c) will not (perhaps!) achieve the required results. This is
not a matter for policing, since the ERO is valid in its way.
> Also, is an explicit hop to the egress always required (omitted in
option
> (a)). Does it make sense to include a label on that hop,
and if so what
> processing should the egress node do? In option (d)
it could arguably just
> ignore the label, but that probably is not the
case in (c).
As above:
1. It is helpful to include the destination in the ERO.
2. The label subobject is not supposed to be processed by the DS
node.
Please note that if any work is done to clarify all of this it MUST follow
the "conservative on what you send, liberal on what you receive" principle. We
cannot have a set of rules developed that will break existing implementations.
Rather we should seek rules that cause future implementations to converge while
stating how existing implementations will understand each other.
Adrian