[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID]

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.