Re: draft-ietf-ccamp-gmpls-overlay-01

[Steffen Brockmann <brockmas@se.bel.alcatel.be>]

George,

> >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.

Certainly not.
I was just wondering about the sentence 'In the latter case the connection will
only be made over this interface.'
That reads like:
If the SENDER_TEMPLATE includes the address of one of ingress edge node's
numbered TE links, the ingress core node MUST refuse the connection on any other
interface.

Where does such strict semantics of the SENDER_TEMPLATE come from?
Unless my recollection deceives me (which is certainly possible), the conclusion
in the early days of RFC3471/73 was that it was the IF_ID RSVP_HOP object's job
to identify the TE/data links, rather than the SENDER_TEMPLATE's job.

> >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.

...would certainly help, thanks.

> >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.

I can see your point.
However assuming that most SONET (or lower layer) TE links will be unnumbered,
won't it be better to have a solution that works with unnumbered TE links as
well, e.g. mandating core nodes to at least forward the one RRO subobject they
received from ingress edge nodes?

- Steffen
begin:vcard 
n:Brockmann;Steffen
tel;work:+32-3-240-8615
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:brockmas@se.bel.alcatel.be
org;quoted-printable:<table WIDTH=3D"100%" ><tr><td><center><a href=3D"http://www.alcatel.com";><img SRC=3D"http://www.cid.alcatel.com/graphics/logo_tag.gif"; HSPACE=3D3 BORDER=3D0></a></center></td><td><center><font size=3D+1>System<br>&nbsp=3BArchitecture</font></center></td></tr></table>
fn:Steffen Brockmann
end:vcard