Subject: Re: [pim] wglc for draft-ietf-pim-port-03

From: Stig Venaas <[email-masked]>
Date: Sun, 09 May 2010 19:07:54 -0700

Mike McBride (mmcbride) wrote:
> Today begins a two week wglc for draft-ietf-pim-port-03. Please let your
> yeahs and nays be heard on this list.
> 
> http://www.ietf.org/id/draft-ietf-pim-port-03.txt

The wglc is ending in 2 days and there has been complete silence on the
list. Please post to the list whether you think the document is ready to
be submitted to the IESG. And if you have any issues, please speak up.

Just to repeat, if you have read the document and believe it is ready,
then we also want to hear from you.

Not that as discussed in the wg meeting I will add a sentence or two
saying that SCTP is preferred over TCP if both are announced in the
hello messages by a pair of neighbors.

Stig

> thanks,
> mike
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Mike McBride (mmcbride)
>> Sent: Friday, April 16, 2010 3:02 PM
>> To: [email-masked]
>> Subject: [pim] wglc for draft-ietf-pim-port-03?
>>
>> At the Anaheim meeting there were 5 YES votes and 1 NO vote for moving
>> to wglc for draft-ietf-pim-port-03. Please let us know what the rest
> of
>> you think before a week from today. If we maintain rough consensus, we
>> will initiate a wglc on April 23rd, so speak up.
>>
>> http://www.ietf.org/id/draft-ietf-pim-port-03.txt
>>
>> thanks,
>> mike
>> _______________________________________________
>> pim mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pim
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: Thomas Morin <[email-masked]>
Date: Tue, 11 May 2010 12:09:37 +0200

Hi Stig, Dino, Ice, Maria,

The document is I think generally in a good shape.

However, I think that the statements related to "join suppression",
"prune override" and explicit tracking are well formulated.

In section 2, instead of "there is no join suppression", saying
"explicitly tracking the memberships of all PIM PORT routers is
required". Note that RFC4601 does not explicitly define anything as
"join suppression" (nor any other RFC).

In the following text from  section 4 ...

    Note, since JP messages are sent over a Transport connection, no
    Prune Override or Join Suppression are
    possible for these messages.

...why not say instead :

    Note that, a Join sent over a Transport connection will only be seen
    by the upstream router, and thus will not cause  routers on the link
    that do not use PIM PORT with the upstream router to possibly delay
    the refresh of Join state for the same state.  Similarly, a Prune
    sent over a Transport connection will only be seen by the upstream
    router, and will thus never cause routers on the link on the link
    that do not use PIM PORT with the upstream router, to send a Join to
    override this Prune.

    Note also, that a datagram PIM Join/Prune message for a said (S,G)
    or (*,G) sent by some router on a link will not cause routers on the
    same link that use a Transport connection with the upstream router
    for that state, to suppress the refresh of that state to the
    usptream router (because they don't need to periodically refresh
    this state) or to send a Join to override a Prune (as the upstream
    router will only stop forwarding the traffic when all joined routers
    that use a Transport connection have explicitly sent a Prune for
    this state, as explained in section 6).

In section 6, the text ommit to take into account the case where all
routers on the LAN have set the T bit of the Lan Prune Delay option and
thus are already doing explicit tracking. In that case an upstream
router will treat non-PORT neighbours just like PORT neighbors for
everything related to explicit tracking.  Adding a sentence such as
"except when explicit tracking of routers membership is used which is
the case when all routers have announced Tracking capability in the T
bit of the Lan Prune Delay option" in the right places would I think fix
that.

Here are a few others editorial comments:
* in section 4.3, there remains a "or MDT tunnel", as a left-over of
past versions of the document
* section 2 and 6 uses the terme "routes" to refer to what the rest of
the document  (and RFC4601) calls  "state(s)"
* section 6 says "sends a Prune Override", which is a bit an abusive
shortcut for "sends a Join to override the Prune".
* section 2 and 4 use "RPF to" as a verb, which in an IETF document
would deserve being expanded:
   - section 2: "routes which RPF to a PORT-capable neighbor" -> "states
for which the RPF is a PORT-capable neighbor"
   - section 4: "A downstream router, when an upstream neighboring
router has expired, will simply RPF to a new neighbor ..." -> "A
downstream router, when an upstream neighboring router has expired, will
simply update the RPF for corresponding states to a new neighbor ..."
* I feel that the shortening of "Join-Prune" into "JP" does not help
readability a lot, and would suggest expanding it everywhere into
Join-Prune ; I feel even strongly for shortening "Join-Prune messages"
into "JPs"... ;-)

Thank you,

-Thomas

---

From: Stig Venaas <[email-masked]>
Date: Tue, 11 May 2010 10:41:53 -0700

> The document is I think generally in a good shape.

Thanks Thomas, good comments below.

I will wait and see if I get more input before the wglc ends today.

Please folks, give good or bad feedback today!

Thanks Thomas for doing just that.

As soon as the wglc ends I'll update the draft based on the comments
below. And possibly other comments if you good people can review it.

Stig

> ------------------------------------------------------------------------
>

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Wed, 12 May 2010 09:32:04 +0200

Hi Stig,

A couple of comments on this doc:

- Introduction mentions "This specification enables greater scalability in multicast deployment since the processing required for protocol state maintenance can be reduced". Can authors explain how leaving PIM state maintenance unmodified (see Intro) but adding TCP state reduces protocol state ?

- Introduction mentions "This document will specify how periodic JP message transmission can
be eliminated by using TCP [RFC0761] or SCTP [RFC4960] as the reliable transport mechanism for JP messages." where is the periodic message elimination described in this document (beside the two sentences in the middle of Section 2). 

Note also that the document states "The explicit non-goals of this specification are: Changes to the PIM protocol machinery as defined in [RFC4601]." 

- Section 4: why switching to PORT mode occurs upon Hello reception ? and not upon TCP connection establishment ?

- Section 5: introduces the Type 0 "instance ID" field what the size of this field ? What happens in case of Instance mismatch ? To what "instance" refers to ?

- Section 6: there is no description of explicit tracking on non point-to-point interfaces. Can authors describe tracking for the other types of interfaces ?

- Is there any use of TCP-based, keep-alive mechanism to determine if PIM neighbors are reachable ?

Editorials:

- The term "Reliable JP" is confusing so goes sentences like "Reliable JP messages are sent using a TCP/SCTP connection" afaik it is the communication mode that enables reliability. This term is only used in the introduction and thus be removed to uniquely refer to PORT-mode (transport) vs Datagram-mode (native).

- Ref: why do you refer to RFC 761 and not RFC 793 "[RFC793]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. the latter replaces the former.

- PIM-SSM is mentioned in Section 8 not in the introduction.

- The use of acronyms JP, JPs, etc. decreases readability. Recommended to use "Join-Prune", "Join-Prune messages", etc.

Thanks,
-dimitri.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stig Venaas
> Sent: Monday, May 10, 2010 4:08 AM
> To: Mike McBride (mmcbride)
> Cc: [email-masked]
> Subject: Re: [pim] wglc for draft-ietf-pim-port-03
>

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 12 May 2010 07:39:41 -0700

Dimitri,

> - Introduction mentions "This specification enables greater scalability
> in multicast deployment since the processing required for protocol
> state maintenance can be reduced". Can authors explain how leaving
> PIM state maintenance unmodified (see Intro) but adding TCP state
> reduces protocol state ?

In fact, since PORT requires explicit tracking, it clearly adds
state overhead for routers connected to multi-access interfaces.

So, in reality for routers connected to multi-access interfaces
PORT provides a tradeoff between less control traffic
overhead at the cost of more control plane state overhead.

With this in mind I would suggest to replace

   This specification enables greater scalability in multicast
   deployment since the processing required for protocol state
   maintenance can be reduced.  

with the following:

  This specification enables greater scalability in terms
  of control traffic overhead. However, for routers connected
  to multi-access links that comes at the price of increased
  control plane state overhead.

Yakov.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 12 May 2010 13:15:46 -0700

> state overhead for routers connected to multi-access interfaces.

Note that it talks about "processing" and "state maintenance". It's
not saying that there is less state, only that you need to do less
processing to maintain the state. Which of course is because there
are no periodic messages.

> overhead at the cost of more control plane state overhead.

Right, it requires additional state, but I will still argue
that maintaining the state costs less.

>   control plane state overhead.

So I think this is mostly covered, but I'm happy to point out
that there is additional state required for multi-access links.

Thanks for all the feedback. I will start working on an updated
version and propose some changes based on your comments.

Stig