Subject: [Gen-art] Russ's Discs on draft-ietf-pim-port [Was: Gen-ART Telechat review of draft-ietf-pim-port-09.txt]

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 25 Nov 2011 22:03:56 -0000

Hi,

This thread seems to have dried up. AFAICS there is no change needed to the
document.

Anything further to say before I ask Russ to clear his Discuss?

Thanks,
Adrian

> -----Original Message-----
> From: Stig Venaas [mailto:[email-masked]]
> Sent: 08 November 2011 04:02
> To: Suresh Krishnan
> Cc: [email-masked]; General Area Review Team; Russ
> Housley
> Subject: Re: Gen-ART Telechat review of draft-ietf-pim-port-09.txt
> 
> On 07.11.2011 15:39, Suresh Krishnan wrote:
> > Hi Stig,
> >
> > On 11/03/2011 02:28 PM, Stig Venaas wrote:
> >> Thanks for the review, see below.
> >>
> >> On 11/1/2011 4:18 PM, Suresh Krishnan wrote:
> >>> I have been selected as the General Area Review Team (Gen-ART)
> >>> reviewer for this draft (for background on Gen-ART, please see
> >>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> >>>
> >>> Please wait for direction from your document shepherd
> >>> or AD before posting a new version of the draft.
> >>>
> >>> Document: draft-ietf-pim-port-09.txt
> >>> Reviewer: Suresh Krishnan
> >>> Review Date: 2011/11/01
> >>> IESG Telechat date: 2011/11/03
> >>>
> >>> Summary: This document is almost ready for publication as an
> >>> Experimental RFC but I have a few comments.
> >>>
> >>> Minor
> >>> =====
> >>>
> >>> Section 3.1
> >>>
> >>> * From my reading of the document, it is not clear whether we can have a
> >>> node advertise multiple capability options of the same transport
> >>> protocol (say PIM-over-TCP-Capable) in the same message. e.g. A dual
> >>> stack node might want to advertise its capability to do both IPv4 and
> >>> IPv6. Is this possible? If so, how?
> >>
> >> For PIM we generally (not just PORT) use Hello Options in IPv4 PIM
> >> Hello's for IPv4 capabilities and Hello Options in IPv6 PIM Hello's
> >> for IPv6 capabilities. The two are completely separate.
> >>
> >> If a router supports PORT for both IPv4 and IPv6, it will send one
> >> option in the IPv4 Hello, and another in the IPv6 Hello.
> >>
> >> In section 4 it says:
> >>
> >> The decisions whether to use PORT, which transport, and which
> >> Connection IDs to use are performed independently for IPv4 and
> >> IPv6. Thus, if PORT is used both for IPv4 and IPv6, both IPv4 and
> >> IPv6 PIM Hello messages MUST be sent, both containing PORT Hello
> >> options.
> >>
> >> I think this is pretty clear.
> >
> > That clarifies a bit, but I am still unclear as to how the protocol
> > selection takes place. e.g. Does IPv6+SCTP take precedence over IPv4+TCP.
> 
> As it says, it is done independently for IPv4 and IPv6. So in that case
> you would have IPv6 PIM using SCTP, while IPv4 PIM using TCP.
> 
> You would only have connection sharing if IPv6 PIM and IPv4 PIM end up
> using the same transport and same end-point addresses. This is all in
> the document.
> 
> 
> >>
> >>> Section 4.7
> >>>
> >>> * Section 4 talks about the router with the lower connection ID
> >>> initiating the transport layer connection but this does not really map
> >>> into the rules mentioned in Section 4.7. Specifically, I am not sure
> >>> Rule 3 for Node A in Section 4.7 conveys the same intent as section 4.
> >>
> >> Note that we also allow doing connections on-demand. In that case they
> >> one with the higher address may open a connection. That is the reason
> >> for rule 3.
> >>
> >> See end of section 4.5 where it says:
> >>
> >> Note that for TCP, it is the router with the lower Connection ID that
> >> decides whether to open a connection immediately, or on-demand. The
> >> router with the higher Connection ID SHOULD only initiate a
> >> connection on-demand. That is, if it needs to send a Join/Prune
> >> message and there is no currently established connection.
> >>
> >> Do you still think something is not clear?
> >
> > The text only describes the when it is *acceptable* for a router with a
> > higher connection ID to initiate a connection, not when it should
> > *actually* do so. Specifically section 4.7 should cover this.
> 
> It says "SHOULD only initiate a connection on-demand". This means
> that it is initiated if a join/prune needs to be sent. I think this
> is clear enough, but note that this doesn't have to be very strict. It
> is unfortunate if the one with the higher ID always tries to initiate a
> connection, but there isn't much harm if it does. It wouldn't break
> anything.
> 
> Stig
> 
> > Thanks
> > Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Sat, 26 Nov 2011 19:36:31 -0500

Hi Adrian,

> Anything further to say before I ask Russ to clear his Discuss?

I had a chat about this draft with Stig at the IETF meeting in Taipei.
He clarified how PIM PORT connections can be shared across address
families.

I believe the following text change would resolve my concern with the draft.

OLD:
If two neighbors announce the same transport (TCP or SCTP) and the same
Connection IDs in the IPv4 and IPv6 Hello messages, then only one
connection is established and is shared. Otherwise, two connections
are established and are used separately.

NEW:
If two neighbors announce the same transport (TCP or SCTP) and the same
Connection IDs in the IPv4 and IPv6 Hello messages, then only one
connection is established and is shared. Otherwise, two connections
are established and are used separately.

Please note that the Connection ID AFI in the PORT Hello Option does not
need to match the address family of PIM Hello message that carries it.
e.g. an IPv6 PIM Hello message could contain a PORT Hello Option with a
TCP Connection ID AFI of 1 (IPv4).

Thanks
Suresh

---

From: Stig Venaas <[email-masked]>
Date: Mon, 28 Nov 2011 09:59:13 -0800

> are established and are used separately.

I guess something needs to be added. I think it is said implicitly here
since we are stating "the same ConnectionIDs in the IPv4 and IPv6"...,
also there would not be much use for the AFI in the hello option if it
was always the same as the hello itself. Anyway, I agree it should be
pointed out.

> TCP Connection ID AFI of 1 (IPv4).

While I am OK with this text, wouldn't it be better to add this to 3.1
and 3.2 where we formally define the hello options?

My proposal would be:

End of 3.1:

OLD:
    TCP Connection ID AFI:   The AFI value to describe the address-family
       of the address of the TCP Connection ID field.  When this field is
       0, a mechanism outside the scope of this document is used to
       obtain the addresses used to establish the TCP connection.

NEW:
    TCP Connection ID AFI:   The AFI value to describe the address-family
       of the address of the TCP Connection ID field. Note that this
       value does not need to match the address-family of the PIM Hello
       message that carries it. When this field is 0, a mechanism
       outside the scope of this document is used to obtain the
       addresses used to establish the TCP connection.

End of 3.2:

OLD:
    SCTP Connection ID AFI:   The AFI value to describe the address-
       family of the address of the SCTP Connection ID field.  When this
       field is 0, a mechanism outside the scope of this document is used
       to obtain the addresses used to establish the SCTP connection.

NEW:
    SCTP Connection ID AFI:   The AFI value to describe the address-
       family of the address of the SCTP Connection ID field. Note that
       this value does not need to match the address-family of the PIM
       Hello message that carries it. When this field is 0, a mechanism
       outside the scope of this document is used to obtain the
       addresses used to establish the SCTP connection.

What do you think?

Stig

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 29 Nov 2011 13:18:38 -0500

Hi Stig,

>        addresses used to establish the SCTP connection.

This works great.

Thanks
Suresh

---

From: Stig Venaas <[email-masked]>
Date: Mon, 28 Nov 2011 11:07:04 -0800

>>         addresses used to establish the SCTP connection.

Great, I hope we can then just add a note for the editor, and that the
discuss can be cleared...

Stig