The MPLS WG Archive

[Lou Berger <lberger@labn.net>]

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?

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.

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

Lou

At 10:43 AM 6/27/2006, Yakov Rekhter wrote:

>Lou,
>
>[since the answer to the question you posed below may benefit
>other folks, I added mpls and ccamp mailing list to the cc:]

a bit unusual to redirect private mail, but whatever...

> > Rahul,
> >          Okay, so I'm just a bit slow.  Can you explain why the
> > semantics of P2MP-TE needs to be different than P2P-TE?
> >
> > Yakov,
> >
> > Perhaps you should answer this?
> >
> > Lou
>
>To answer your question observe that in P2P-TE the Session object
>carries IPv4 tunnel end point address, while in P2MP-TE the Session
>object carried P2MP-ID.
>
>Here are some of the reason(s) semantics of IPv4 tunnel end point
>address needs to be different than P2MP-ID:
>
>1. IPv4 tunnel end point address is a unicast address. P2MP-ID
>is not.
>
>2. IPv4 tunnel end point address is suitable for hierarchical routing
>(e.g., CIDR). P2MP-ID is not.
>
>3. There are well-established procedures for assigining (globally)
>unique unicast IP addresses. There are no such procedures for
>assigining (globally) unique P2MP IDs.
>
>Yakov.


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