[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-ietf-ccamp-gmpls-overlay-01
Steffen -
I have a doubt on draft-ietf-ccamp-gmpls-overlay-01:
In section 2, the draft states:
'When forming a SENDER_TEMPLATE the ingress edge-node includes either
its Node-ID or the address of one of its numbered TE links. In the
latter case the connection will only be made over this interface.'
That suggests to use the SENDER_TEMPLATE to restrict the choice of data
channel.
One certainly can't disallow use of the interface address as it is
permitted in RSVP.
That however is exactly what according to RFC3471 the TLVs of the IF_ID
RSVP_HOP objects are meant for.
Instead of the SENDER_TEMPLATE object, shouldn't TLV type 1 be used?
You are correct in that the HOP object narrows what is in the sender
template. Further if the Sender template has been used to specify an
interface, then the hop object must specify a facility within that
interface (note that the interface could be bundled.) I can add text to
this effect if you think that would make the
draft clearer.
There is also a philosophical question that comes with it:
The SENDER_TEMPLATE is meant to have end-to-end significance, whereas
the selection of the data channel is of local significance.
Yes. The point of using the interface in the sender template is precisely to
communicate to the far end the interface for this LSP. Thus if the far end
wants to setup a diverse path, it knows to use a different interface.
There is another inaccuracy in section 3.3, I believe:
'In order to support explicit label control and full identification of
the egress link an ingress edge-node may include an ERO that consists
of only the last hop. This is signaled by setting the first subobject of
the ERO to the node-ID of the egress core-node with the L-bit set.'
It is just an editorial detail, but the first subobject of the ERO sent
by the ingress edge node must point to the ingress core node. Else the
ERO check at the ingress core node will fail, according to RFC3209,
section 4.3.4.1:
Fixed.
'1) The node receiving the RSVP message MUST first evaluate the first
subobject. 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. If there is no first subobject,
the message is also in error and the system SHOULD return a "Bad
EXPLICIT_ROUTE object" error.'
...George