Subject: mboned: Embedded-RP and treatment of FFF0::/12

From: Pekka Savola <[email-masked]>
Date: Tue, 19 Oct 2004 18:06:53 +0300 (EEST)

Hi,

The Embedded-RP spec just entered AUTH48, implying it will be an RFC
"really soon".  However, at the same time, I've had questions from the
implementors how they should treat FFF0::/12 (the main embedded-RP
range being FF70::/12).

The document specifies 'R'-bit, and basically states (or intends to
say) that behaviour when the highest-most bit is not zero (causing FFF
instead of FF7) is unspecified.

I have interpreted this to mean that the implementations should
perform Embedded-RP semantics just for addresses in FF70::/12, i.e.,
only when the first bit is zero.

As I see it, the pros/cons for this interpretation are:
 + allows the possibility to use FFF0 for something else than embedded 
RP in the future if necessary [remember, we're short on flags!]
 + if FFF0 is used for some other form of embedded-RP (like bidir) 
which is protocol-wise incompatible with the current PIM-SM approach, 
there is no confusion with old implementations which treat FFF as 
pim-sm.
 - however, if the highest order bit is used for something orthogonal 
to embedded-RP, the implementations on the field need to be updated

I think the consensus has been that implementations should not treat 
fff0::/12 as embedded-RP (for now), i.e., my interpretation.

But it seems that the document may warrant a little bit of 
clarification before publishing as RFC.

If you have opinions/thoughts about this, I suggest you voice them
ASAP!

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Nidhi Bhaskar <[email-masked]>
Date: Tue, 19 Oct 2004 10:54:52 -0700 (PDT)

Pekka,

> instead of FF7) is unspecified.

I interpreted that to mean that the range is embedded-RP but what you
do with the extracted RP is unspecified. I.e. do you use it for PIM-SM
or Bidir or ...

> only when the first bit is zero.

In general, I've always viewed the flags to not change in meaning if
some higher order bit is set. I think this has been the approach with
the flags defined so far, e.g. Temporary/Permanent, Unicast prefix
based vs. not etc. So what you propose for Embedded RP is inconsistent
with the other flags and must be stated more clearly in the
text. Also, it would be good to know why the existing approach was
taken for the flags.

> RP in the future if necessary [remember, we're short on flags!]

Right. However, we won't have an embedded RP range for other PIM
modes. If we are going this route, perhaps we should define SM
operation for a subrange of ff7::/12 ?

> there is no confusion with old implementations which treat FFF as

Whatever we do with FFF::/12 today is incomaptible with a newer form
of embedded RP.

> to embedded-RP, the implementations on the field need to be updated

Are you talking about existing implementations that treat fff::/12 as
embedded RP ?

> clarification before publishing as RFC.

Yes please.

Thanks,
Nidhi.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 19 Oct 2004 20:35:02 +0200

> do with the extracted RP is unspecified. I.e. do you use it for PIM-SM

When you say unspecified, it's not clear what is unspecified. With the
old/normal way of using the bits in mind, this can be interpreted as
saying that there is always embedded-RP when R-bit is set, but how it
works is unspecified when the highest bit is non-zero.

> > only when the first bit is zero.

I know, but I think it can easily be interpreted differently.

> text. Also, it would be good to know why the existing approach was

I like the new approach, but since it's a new approach it should be
made very clear.

Basically you don't really want to specify the behaviour when the
R-bit is set (by itself). You want the document only to specify the
behaviour when the flags are 7 (0111).

I think it can be made clear just by changing or adding one sentence.

Stig

---

From: Pekka Savola <[email-masked]>
Date: Tue, 19 Oct 2004 21:36:09 +0300 (EEST)

Hi,

Thanks for the follow-up.  More inline,

> do with the extracted RP is unspecified. I.e. do you use it for PIM-SM

That's certainly a relatively understandable interpretation.. although
I'm still not sure how it relates here -- because you don't know the
semantics of the embedded-RP mechanism which would/could use the
fff0::/12 range, and you don't support it yet, I don't quite
understand why you'd want to react to it yet (see below for more
detail)?
 
> text. Also, it would be good to know why the existing approach was

I agree that that's the typically flags, are, well, flags.

> operation for a subrange of ff7::/12 ?

That's correct.  But defining SM subrange later, out of ff7:: is no 
worse than using both ff7 and fff for SM right now, right?

In other words, in my eyes, the following are both equally bad (or 
good):

 1) having implementations react to fff0::/12 [with pim-sm] as
embedded rp as they would for ff70::/12.

 2) having implementations just use only ff70::/12 for now (treating
fff0::/12 as non-embeddedrp multicast, or whatever they do), and
possibly later define a subrange of ff70::/12 for non- pim-sm
operation.

(In both cases there might be different behaviour in the same range; 
for 1) there are guaranteed to be problems; for 2) there may be 
problems, depending on the range chosen.)

The approach I've in mind leaves it yet unspecified whether "R-bit"  
with high-order bit 1 would be used for another mode (e.g.,
bidir-pim), or something else completely.  The good thing is that we
don't need to decide before we figure out how it'd work out!  The bad
thing is that if we'll end up using the high-order bit as an
orthogonal flag after all, the implementations would have to be
modified to also look for fff0::/12.

So, I think there are two issues:

 a) should the R-bit be clearly dedicated to embedded-RP, also when 
the highest order bit is 1, and

 b) whether pim-sm embedded-RP implementations should react to just 
ff70::/12 or also to fff0::/12 (for the lack of any other mode to use 
it)

My arguments here are:

 a) maybe we shouldn't need to decide this firmly yet, because we 
don't know the nature of these modifications, i.e., whether this 
difference is needed and what would the best bit number to put it in.

 b) having the pim-sm embedded-rp implementations react to anything
other than ff70::/12 would seem to be ill-advised, because it would
prevent us the option for (reliably) specifying fff0::/12 for
non-embeddedrp or something else (like bidir).

So, this is certainly a tradeoff here, protocol simplicity versus
conservation and preserving the option for future extendibility.

> Whatever we do with FFF::/12 today is incomaptible with a newer form

Right, and thus I'd like to prevent FFF::/12 being 'contaminated' with 
unspecified behaviour.

If implementations reacted to FFF::/12 now, sometime in the future
when we wanted to use it something we'd have two kinds of
implementations (plus the third kind which don't support embedded-rp
and just treat it as unicast-prefix based multicast ;-): those which
would treat it as embedded-rp for pim-sm, and those who would treat it
differently.  This inconsistency bothers me, and no matter what we do,
I'd like to try to avoid it.

Do you think that's a worthy goal?

> Are you talking about existing implementations that treat fff::/12 as

Existing implementations that treat fff::/12 yes, and more importantly
all those implementations of embedded-rp for pim-sm which would follow
until embedded-rp for other protocols/operational modes is specified.

> > clarification before publishing as RFC.

Right; we just need to figure out what it needs to say then ;-).

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Oct 2004 18:29:29 +0300 (EEST)

Hi,

Based on this, and off-list discussion, I think there is agreement 
that leaving FFF0::/12 alone for now is the best way to go.

> I think it can be made clear just by changing or adding one sentence.

I propose the following edits; please speak up soon if you think 
something else (or more) would be more appropriate.

In section 3, please replace:

OLD:
   R = 1 indicates a multicast address that embeds the address on the
   RP.  Then P MUST be set to 1, and consequently T MUST be set to 1, as
   specified in [RFC3306].  In effect, this implies the prefix
   FF70::/12.  In this case, the last 4 bits of the previously reserved
   field are interpreted as embedding the RP interface ID, as specified
   in this memo.

   The behavior is unspecified if P or T is not set to 1, as then the
   prefix would not be FF70::/12.  Likewise, the encoding and the
   protocol mode used when the two high-order bits in "flgs" are set to
   11 ("FFF0::/12") is intentionally unspecified until such time that
   the highest-order bit is defined.

NEW:
   When the highest-order bit is 0, R = 1 indicates a multicast 
   address that embeds the address on the
   RP.  Then P MUST be set to 1, and consequently T MUST be set to 1, as
   specified in [RFC3306].  In effect, this implies the prefix
   FF70::/12.  In this case, the last 4 bits of the previously reserved
   field are interpreted as embedding the RP interface ID, as specified
   in this memo.

   The behavior is unspecified if P or T is not set to 1, as then the
   prefix would not be FF70::/12.  Likewise, the encoding and the
   protocol mode used when the two high-order bits in "flgs" are set to
   11 ("FFF0::/12") is intentionally unspecified until such time that
   the highest-order bit is defined.  Without further 
   IETF specification, implementations MUST NOT treat the FFF0::/12
   range as Embedded-RP.

In section 4, please replace:

OLD:
   o  It MUST be a multicast address and have R, P, and T flag bits set
      to 1 -- that is, be part of the prefix FF70::/12 (note that
      FFF0::/12 is yet unspecified),

NEW:
   o It MUST be a multicast address with "flgs" set to 0111,
     that is, to be of the prefix FF70::/12,

Does this look good enough?  Do you think 'MUST NOT' is too strong and
'SHOULD NOT' would be sufficient?

---

From: Nidhi Bhaskar <[email-masked]>
Date: Thu, 21 Oct 2004 18:45:31 -0700 (PDT)

New text looks good. I vote for SHOULD vs MUST below.

Nidhi.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 23 Oct 2004 07:52:02 +0300 (EEST)

FYI,

I ended up using 'SHOULD NOT' because Nidhi and Stig had a slight 
preference for that.

Thanks!