[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt
> What are exactly the (practical) problems with carrying the root
> node IP address both in the Extended Tunnel ID and in the Tunnel
> Sender Address fields ?
If you wish to use bypass FRR, you will do exactly this. The Extended
Tunnel ID is meant to provide a means of making the Session globally
unique. An intermediate node that wishes to merge back into an existing
tunnel over a bypass tunnel uses it's own IP address in the sender field
and the existant Session Object. If the session object were not unique
then this would be very hit or miss!
Personally I would like to see the text with ^^^^ removed from the
draft. It was carried over from 3209 which was written prior to the FRR
> A 32-bit identifier used in the SESSION that remains constant
> over the life of the tunnel. Normally set to all zeros.
If we ever get around to pushing 3209 to Draft Standard I'll take it out
of there as well.
George Swallow Cisco Systems (978) 936-1398
1414 Massachusetts Avenue
Boxborough, MA 01719