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

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



Lou,

[clipped...]

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

Given that P2MP ID is unique within the scope of the root, why a
tuple <Extended Tunnel ID, P2MP ID> is not sufficient to identify
the set of destinations of a P2MP tunnel ? After all, you agreed
further down that such a tuple identifies a P2MP 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!

Good, so we are in agreement that a combination of root node address
and P2MP ID forms a (globally unique) identifier for the P2MP tunnel.

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

Correct.

Yakov.