The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2006-Jun> msg00156



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

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

  • From: Lou Berger <lberger@labn.net>
  • Date: Tue, 27 Jun 2006 16:51:32 -0400
  • Cc: p2mp@labn.net, mpls@ietf.org, ccamp@ops.ietf.org
  • X-AntiAbuse: This header was added to track abuse,please include it with any abuse report
  • X-AntiAbuse: Primary Hostname - esc71.midphase.com
  • X-AntiAbuse: Original Domain - ietf.org
  • X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
  • X-AntiAbuse: Sender Address Domain - labn.net

Yakov,

At 04:37 PM 6/27/2006, Yakov Rekhter wrote:

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

Because this would preclude the use of tunnel ID to further partition 
the session space (as is done today for P2P-TE.)  The tuple I 
mentioned included all three.


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

Much thanks,
Lou


>Yakov.


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