The MPLS WG Archive

[Lou Berger <lberger@labn.net>]

Yakov,
         See below.

At 12:28 PM 6/27/2006, Yakov Rekhter wrote:

>Lou,
>
> > Yakov,
> >          Thank you for the concise response to a question that has
> > been outstanding for some time.  Now there are two specific aspects
> > to the proposed response (Rahul's) to the issues you raise below:
> >
> > 1) Tunnel ID
> > [From rahul's mail]
> >   > 4.
> >   > 19.1.1
> >   >
> >   > "Tunnel ID
> >   >
> >   >       A 16-bit identifier used in the SESSION object that remains
> >   >       constant over the life of the P2MP tunnel."
> >   >
> >   > to
> >   >
> >   > "Tunnel ID
> >   >
> >   >       A 16-bit identifier used in the SESSION object that remains
> >   >       constant over the life of the P2MP tunnel. It SHOULD be set to 0
> >   >       by the ingress LSR and be ignored on receipt."
> >   >
> >
> > I don't see how this change, setting the ID to zero, relates to the
> > issue you raise.  Can  justify why this change is required?
>
>This is orthogonal to the issue of P2MP ID uniqueness scope.

okay, that's not how it's been presented.  What *is* the reason for 
this change?

>
> > 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.  Is this 
not the case?  If not, why is uniqueness of the tuple insufficient?

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

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

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


>
>4. Make similar changes in 19.1.2

yes.

Lou


>Yakov.


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