Subject: [lisp] last call for draft-ietf-lisp-multicast-05

From: Terry Manderson <[email-masked]>
Date: Sun, 1 May 2011 17:08:26 -0700

All,

The authors of draft-ietf-lisp-multicast-05 have requested a work group last
call.

Here starts the last call for this document, Joel and I will end the last
call on Monday the 16th May, 2011.

Please review the draft and provide any last comments.

Cheers
Terry

---

From: Alia Atlas <[email-masked]>
Date: Mon, 16 May 2011 18:17:14 -0400

Here are my review comments:

What I most want to see in this draft is a clear description of what
needs to implemented and how.  It gives a good survey of the
architectural possibilities and even makes suggestions at the end -
but not quite sufficient to be clear in the details of what needs to
be implemented for interoperability and what is for future
experimentation.

a) Could you add a definition for uPITR?  It is first used on p.9 in
the mPETR definition and only on p. 22 is it described as
  "(where in unicast it acts as a "Proxy ITR", or an uPITR)"

b) Sec 4, second paragraph: "At this point in time, we don't see a
requirement for different locator-sets, priority, and weight policies
for multicast than we have for unicast."  but there is an M Priority
and M Weight in the [LISP] draft.  Clarification as to why would be
useful... (I know it is to get the RLOCs of the ITRs which shouldn't
be used for unicast traffic.)

I don't see a mechanism other than the M Priority to obtain the RLOCs
associated with an ITR - since only ETR RLOCs would normally be
included.

What would be good to add to the draft is the changes to be made to
information such as the Map-Reply messages.  E.g.
   Set the M Priority for all ETR RLOCs to be 255
   Add the ITR RLOCs and set the Priority to 255 & the M Priority to
   something else.

c) What happens if the S-EID and S-RLOC collide?  In particular, at
the ETR and ITR, it seems useful to specify that the xTR has knowledge
of whether the packet was LISP-encapsulated & forwards it either to
receivers that expect it un-LISP-encapsulated (ETR) or to receivers
that expect it LISP-encapsulated (ITR).

d) p. 15 end of MSDP:
   "And the choice can be made unilaterally because the ITR at the
   site will determine which namespace the destination peer address is
   out of by looking in the mapping database service."

Is there an assumption in LISP that an EID and an RLOC MUST NOT have
the same value??  I've seen this potentially implied, but not
proscriptively stated.

e) p. 22 first paragraph:
  "So the ETR knows to simply propagate the PIM Join/Prune message to
  a external-facing interface without converting the (S-EID,G) because
  it is an (S,G) where S is routable and reachable via core routing
  tables."

 In [INTWRK], it is clear that an EID may be globally routable.  This
 creates a conflict here, where there is an assumption that if an IP
 address is globally routable, then it is not in the EID/RLOC mapping
 database.

 Couldn't a more specific check be done along the lines of:
   if the S-EID is reachable via core routing and
       i) it is not in the mapping database or
       ii) it is in the mapping database, but there are no RLOCs with
           an M Priority other than 255?

f) Text in 9.1.1, 9.1.2 doesn't match the headings well.  For
instance, in 9.1.1, there is discussion of how a LISP source site that
sends to non-LISP or uLISP receiver sites also can send to LISP
receiver sites.

In 9.1.2, maybe renaming it to non-mLISP Receiver Sites would be
clearer?

g) In 9.1.4, Mpriority and Mweight are finally mentioned - but as far
as I can tell, they are needed earlier and for the pure mLISP to mLISP
case.  Please pull the discussion of this earlier.

Also, this case is discussed in 9.1.1 last paragraph on p. 21 - but
claimed that it is sufficient to look in the mapping database.  Could
you please combine these and bring more consistency to the draft?

h) In 9.1.5, is it possible to make a recommendation (e.g. an ITR
SHOULD be able to send two packets based on what its oif-lists are?
Isn't this already the case because the mLISP ITR could have
internal-facing entries in the (S-EID,G) that need to be replicated
without encapsulation and external-facing entries in the (S-RLOC, G)
that need encapsulation?

I understand that this isn't ideal because multiple copies of data are
going into the core - but the trees are different there too.

What I'm looking for is some normative text about what MUST/SHOULD be
supported - even for experimental interoperability.

The second option seems like it comes naturally - if a Join comes for
the (S-RLOC, G), then it is sent the encapsulated packet.

g) p. 21 Sec 9.1.1 end of second paragraph:
  "It is important to note that the routable address for the host cannot
   be the same as an RLOC for the site.  Because we want the ITRs to
   process a received PIM Join/Prune message from an external-facing
   interface to be propagated inside of the site so the site-part of the
   distribution tree is built."
Is this supposed to be one sentence??

h) typo: p. 9 mPETR definition, last sentence:  "co-loacted" -> co-located

i) typo: p. 23 4th line from bottom: "oins to" -> joins to

j) typo: p.27 first sentence: "MUST not" -> MUST NOT

k) typo: Sec 11 last sentence: "addition to slow" -> "addition due to slow"

l) [LISP] needs to be Normative - it has the packet formats!

Looking forward to your responses,
Alia

On Sun, May 1, 2011 at 8:08 PM, Terry Manderson
<[email-masked]> wrote:
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>