The MPLS WG Archive

[Lou Berger <lberger@labn.net>]

Yakov,
         See below, I think we're almost there.

At 03:26 PM 6/27/2006, Yakov Rekhter wrote:

>Lou,
>
> > > > 2) Extended Tunnel ID
> > > > [again from rahul's mail]
> > > >
> > > >   > 5.
> > > >   >
> > > >   > "Extended Tunnel ID
> > > >   >
> > > >   >  A 32-bit identifier used in the SESSION object that remains
> > > >   >       constant over the life of the P2MP tunnel.  Normally set to
> > > >   >       all zeros. Ingress nodes that wish to narrow the scope of a
> > > >   >       SESSION to the ingress-PID pair may place their IPv4 address
> > > >   >       here as a globally unique identifier [RFC3209]."
> > > >   >
> > > >   > to
> > > >   >
> > > >   > "Extended Tunnel ID
> > > >   >
> > > >   >       A 32-bit identifier used in the SESSION object that remains
> > > >   >       constant over the life of the P2MP tunnel. This identifier
> > > >   >       MUST be set to the ingress LSR's IPv4 address."
> > > >
> > > > So the original text, allowed for global uniqueness and included a
> > > > "well-established procedures for assigning (globally) unique" P2MP IDs.
> > >
> > >Could you please point me to the text that spells out procedures
> > >for assigning P2MP IDs that are globally unique *on their own* (not
> > >in a combination with the Extended Tunnel ID).
> >
> > Ahh, good point, I was referring to the uniqueness of the tuple <P2MP
> > ID, Tunnel ID, Extended Tunnel ID>. I must admit, I made the
> > assumption that this is what you cared about for uniqueness.
>
>That is precisely what I care about.
>
> > Is this
> > not the case?  If not, why is uniqueness of the tuple insufficient?
>
>Uniqueness of the tuple is sufficient.
>
> > > > It seems to me that the -05 text covered the issue you raised.  So
> > > > now we come to the heart of the matter:  Why is a change in the -05
> > > > definition of the IDs needed?
> > > >
> > > > It seems to me that at most the text needs to replace a "may" with a
> > > > "MUST", as in "Ingress nodes that wish to narrow the scope of a
> > > > SESSION to the ingress-PID pair MUST place their..."
> > >
> > >That is necessary, but not sufficient. Here are the changes that
> > >need to be made:
> > >
> > >1. Section 4.1:
> > >
> > >    A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is
> > >    identified by a P2MP SESSION object. This object contains the
> > >    identifier of the P2MP Session which includes the P2MP ID, a tunnel
> > >    ID and an extended tunnel ID.
> > >
> > >    The fields of a P2MP SESSION object are identical to those of the
> > >    SESSION object defined in [RFC3209] except that the Tunnel Endpoint
> > >    Address field is replaced by the P2MP Identifier (P2MP ID) field.
> > >
> > >    The P2MP ID provides an identifier for the set of destinations of the
> > >    P2MP TE Tunnel.
> > >
> > >The last sentence above has to be deleted.
> >
> > why, what's incorrect about it?
>
>To begin with, the last sentence states that the P2MP ID, *by itself*
>"provides an identifier for the set of destinations of a given P2MP
>TE Tunnel". However, since a given P2MP ID, *by itself*, may not
>be unique, how could it unambiguously identify the set of destinations
>of such tunnel ?

You are 100% correct, how about fixing it by saying:
"The P2MP ID together with Tunnel ID, Extended Tunnel ID provide an 
identifier for the set of destinations of the P2MP TE Tunnel."

> > >2. Section 19.1.1 replace:
> > >
> > >  P2MP ID
> > >
> > >       A 32-bit identifier used in the SESSION object that remains
> > >       constant over the life of the P2MP tunnel. It encodes the
> > >       P2MP ID and identifies the set of destinations of the P2MP
> > >       Tunnel."
> > >
> > >with the following:
> > >
> > >  P2MP ID
> > >
> > >       A 32-bit identifier used in the SESSION object that remains
> > >       constant over the life of the P2MP tunnel. It encodes the
> > >       P2MP Identifier that is unique within the scope of the Ingress LSR
> > >       whose IP address is carried in the Extended Tunnel ID.
> >
> > Why not, just "Identifier that is unique within the scope of the
> > Ingress LSR."?
>
>That would be fine with me.

great.

>
> > >3. Section 19.1.1 replace
> > >
> > >   Extended Tunnel ID
> > >
> > >        A 32-bit identifier used in the SESSION object that remains
> > >        constant over the life of the P2MP tunnel.  Normally set to
> > >        all zeros. Ingress nodes that wish to narrow the scope of a
> > >        SESSION to the ingress-PID pair may place their IPv4 address
> > >        here as a globally unique identifier [RFC3209]."
> > >
> > >with the following:
> > >
> > >   Extended Tunnel ID
> > >
> > >        A 32-bit identifier used in the SESSION object that remains
> > >        constant over the life of the P2MP tunnel.  Ingress nodes
> > >        that use the locally scoped  P2MP ID MUST place their IPv4
> > >        address here; a combination of this address and P2MP ID
> > >        provides a globally unique identifier for the P2MP tunnel.
> >
> > How about:
> >
> >          A 32-bit identifier used in the SESSION object that remains
> >          constant over the life of the P2MP tunnel.  Ingress nodes
> >          that wish to a globally unique identifier for the P2MP tunnel
> >          MUST place their tunnel sender address here.
>
>The above will be ok if we'll add the following to spell out
>what constitutes this (globally unique) identifier.
>
>       A combination of this address and P2MP ID
>       provides a globally unique identifier for the P2MP tunnel.

Agreed!

Much thanks,
Lou

PS I assume there is no need to change the definition of Tunnel ID, correct?

>Yakov.


_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls