[pim] IETF 70 pimwg mtg notes

"Mike McBride (mmcbride)" <mmcbride@cisco.com> Sat, 05 January 2008 01:09 UTC

Return-path: <pim-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAxXD-00078p-AE; Fri, 04 Jan 2008 20:09:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAxXC-00078i-6q for pim@ietf.org; Fri, 04 Jan 2008 20:09:10 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAxX9-0001q0-L8 for pim@ietf.org; Fri, 04 Jan 2008 20:09:10 -0500
X-IronPort-AV: E=Sophos;i="4.24,247,1196668800"; d="scan'208";a="9926595"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 04 Jan 2008 17:09:07 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m05197SU032586 for <pim@ietf.org>; Fri, 4 Jan 2008 17:09:07 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m051968n026463 for <pim@ietf.org>; Sat, 5 Jan 2008 01:09:06 GMT
Received: from xmb-sjc-219.amer.cisco.com ([171.70.151.188]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jan 2008 17:09:06 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: [pim] IETF 70 pimwg mtg notes
Date: Fri, 04 Jan 2008 17:09:04 -0800
Message-ID: <47951CBFA6409B4C8916514FCB05BFBE0372119D@xmb-sjc-219.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [pim] IETF 70 pimwg mtg notes
Thread-Index: AchOZZXvGKSRkg8LTauYjordCT7ZvwAABjtwAAHN/xAAMMesgA==
From: "Mike McBride (mmcbride)" <mmcbride@cisco.com>
To: pim@ietf.org
X-OriginalArrivalTime: 05 Jan 2008 01:09:06.0364 (UTC) FILETIME=[918AAFC0:01C84F37]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13942; t=1199495347; x=1200359347; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mmcbride@cisco.com; z=From:=20=22Mike=20McBride=20(mmcbride)=22=20<mmcbride@cisc o.com> |Subject:=20[pim]=20IETF=2070=20pimwg=20mtg=20notes |Sender:=20; bh=UwAGUJ0Wzzlb3MiEeeyMj/TzuThq+pWXyD22vAwZavY=; b=pKP0YoyYcWs80VmR3BWtsCiXpVOUOhorc4RiJ53ipxj2f7+w7sHVX6cdJY Cg9ZEtOFZLw8DeIC+Iv9QF0sqqTfqhYFH2RvoksHp79u2LuW/+zQRysNcUkt tNAq1S0xUi;
Authentication-Results: sj-dkim-4; header.From=mmcbride@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
Errors-To: pim-bounces@ietf.org

Please review and send any corrections to Stig and I.
thanks,
mike

Mike McBride: draft-ietf-pim-rpf-vector-05. Minimal edits made to it.
Two previous wglc's. We'll issue one more. We need to add IPR disclosure
info. Yakov/Dino submitted a patent for this back in 2000.

Bill Fenner: IPR stuff doesn't go into the draft anymore. RFC 3668 got
rid of that requirement. Make a general statement and make sure ipr
statement is filed on the IPR website. 

Mike: IPR statement has been filed, so its ready for wglc.

Stig Venaas: We need people to respond to the wglc for this. Its hard to
move the doc forward otherwise.

Bill Atwood: 
draft-ietf-pim-sm-linklocal-02 draft is really a keepalive. Minor
changes in title and housekeeping. Enlarged section on what the
communications patterns are. Most of the activity has occurred in the
background. Discussions on common features of pim-sm work and ospf work.
And possibility that some of the needs for secure communications of rsvp
can make use of these ideas. He came up with idea to extend GDOI for our
use. Also came up with an idea, with a student, on controlling the
adjacency. 

Communication is effectively in little groups. They share one address.
To manage this you can have single key for entire admin region or one
key per speaking router. That decision will be element of policy for
routers in domain. The group controller and key server need to
distribute the shared key to every router in the admin domain. In second
case each speaking router needs to distribute its key to all of its
adjacent routers but we want central control over this. The whole idea
is to automate this. Separate the group controller from the key servers.
GDOI doesn't disallow this but also doesn't have provision in it for the
protocol that would exist between group controller and key server. 

To get reliability, only the group controller needs to be replicated.
GDOI is formulated as a centralized entity so an extension needs to be
specified to specify the protocol between the centralized group
controller and the 100s or 1000s of individual key servers, one per
router. If we feel that this is the right approach, we need to talk to
the msec guys.

OSPF has the same link local problem but it can't assume unicast
connectivity with the central key server. So they really need the key
server to maintain info across restarts. 

RSVP does next hop which is almost link local. Some of the ideas here
may map to their requirements. 

There are probably other protocols that could make use of this nearest
neighbor communication.

One suggestion is to extract this common problem and describe in a new
draft. Not sure where that work would live. Brian thought it was a
reasonable approach.

The first issue is talking securely to the neighbor router. The second
issue is being permitted to talk to the neighbor router. Is he in fact
adjacent to me? Which routers are entitled to receiving keys? To ensure
rogue routers don't suddenly appear as neighbors, the group controller
can be mandated to maintain an adjacency matrix and only authorize true
neighbors.

In v6 you could use neighbor discovery. In general the multicast map
will be the same as the unicast map but not always. 

For v4 we'll have to use central group controller or create something. 

Plan: complete the exploration of adjacency control issues with others
to define extensions to GDOI and create a draft. Create a draft for sub
problem of key managenment. Then rewrite the linklocal draft to include
the proposed GDOI extensions.

Toerless Eckert: There is nothing in draft about these proposed
extensions. Why can't mcast simply inherent the security associations
from ospf or other igp? Where are the requirements coming from? Can see
the need to provide a signature for what I'm sending to identify each
other. But not seeing the justification to encrypt everything. Is there
info that needs to be protected in the pim messages?

Atwood: The ospf linkage has been going on off line, probably doesn't
belong in the draft. The common parts of the work will end up in the new
draft. Both drafts will reference the common work. Its only ospfv3 where
the work is going on. This has to work in both v4 and v6 communities. If
we feel we need a requirement draft first he's prepared to do that. 

Stig: Don't you need all of the routers on the link to understand each
others messages? If you encrypt messages you might have a problem. One
router, when speaking onto a link, needs to be understood by all of its
neighbors. Why do you want to encrypt this?

Atwood: Do we need the confidentiality? He didn't hear anything from the
group either way. To protect himself he put it in. The doc says IF you
do confidentiality you should do it this way. It doesn't say you must do
confidentiality.

We need communication with msec to communicate interest in shared work
in linklocal security and need extensions to achive that.

Stig: 
draft-ietf-pim-bsr-mib-04
Draft submitted to IESG. Fenner reviewed. Minor changes made, just
updating. Look at the diff and review the changes. Moving forward to get
this published. if you have a problem with any of the changes let us
know.

Archana: 
draft-kulkarni-pim-gr-enhancement-00.txt
draft-archana-pimwg-pim-ping-00                  

pim-gr (graceful restart): To support pim gr, pim uses hello message
genid field. When hello message, received with new genid, peer router
sends the bsm message with no forward bit set. Rebooted router doesn't
do any rfc check for this message and stores group/rp mappping from bsm
message. sm/bidir require *g, s,g joins to refresh states on rebooted
router. Some issues with existing pim gr support. This draft tries to
address those issues.

BSR: elected bsr reelection takes 5-23 seconds. bs_override interval.
Starts sending empty bsm message once elected as elected bsr. Now
candidate rp router doesn't know ebsr has rebooted and it started
advertisement message only after crp adv timer expired. so group to rp
mapping on a rebooted ebsr will be refreshed only during 0-60 sec
interval. During that interval you see a lot of state changes.

To solve this: when rebooted router receives the bsm message with peer
with routers own address as bsr address, it can directly transition to
ebsr state. After bsr election, it first sends bsm message. This bsm
message can help the restart bit set. Once the crp router receives bsm
message with restart bit set it knows the ebsr router has rebooted and
it starts sending crp adv message. The second bsm message will only be
generated after 10 seconds. Allows ebsr to learn all the group to rp
mapping from the crp routers. This is the new bsm message format. Same
but using one r bit from the reserve field to indicate that the bsr
router has rebooted. The c bit in the group to rp mapping is used for
the crp routers.

Also new candidate rp adv message format, added one bit from the reserve
field to indicate the crp has rebooted.

Issue with existing pim bidir gr support: when receive hello message
with new genid from upstream router. Downstream immediately triggers
join message. On upstream rp info may not be present or df election may
not have happeneed yet. So the join message sent by the downstream will
be ignored by the rebooted router. solution: do not trigger join when
receive hello message with new genid. approach two: have genid field in
df winner message same as hello. When the genid field has changed
message changes in df winner message, it knows the df winner has lost
state and triggered join can be sent.

Solution for pim sm gr: assert loser shouldn't move to no info state
when recieves hello with new genid from assert winner. 

pim ping draft: This feature is extension to existing PIM protocol to
check the convexity in PIM-Domain and to verify the RP consistency in
PIM domain. This feature can be extended to find the number of receivers
for source and to find minimun PMTU for receiver. It has two message
types, Request and Response and used PIM Type 14.

Dino Farinacci: About 3 years ago I proposed a pim hop count draft and
it was rejected by the pimwg. It adds a new source in the pim join
message that could periodically convey minimum bandwidth, max bandwith,
mtu, etc. But comments were said that statistics and acounting shouldn't
be in the protocol.

Mike: Your draft was likely rejected at the time because we were being
careful not to do anything to derail the pim-sm drafts completion and it
wasn't part of our charter to add extensions to pim. We've since
rechartered.

?: The new mtrace draft supports ipv6 and we changed packet format to
udp and not icmp or igmp. 

Archana: its not only tracing the mcast path, it also does an rp
consistency check.

Fenner: the pim version of it can have more pim specific features. One
of the things we talked about for mtrace is to add a tlv extension
mechanism so hops can insert relevant info without having to say where
everything is that needs to be inserted. Its seems like we can combined
these efforts. Its probably true that pim is the only mcast routing
protocol that people run. If instead we used traceroute as the basis
with these tlv's we could probably get the same functionality. I like
the functionality you are talking about.

Stig: have also had discussions about using mtrace using new tlv's.

Fenner: you can find the number of lans that have joined, not the number
of receivers. Dinos draft comes in to track this. The receiver tracking
may be something you want to do all of the time to allow incrementally
updating instead of asking the the network to tally the number of
receivers. Dinos draft is proably a good way to do it if that's what we
want to do. Which pieces of this makes since to do? I've heard from the
SPs that the content providers want to be able to count receivers. 

Dino: what about in a swiched network?

Fenner: You count the number of dsl routers that have subscribed, you
don't care about the actual number of receivers at a home. Its an
approximation. 

Mike: useful draft to address in pimwg? 

Fenner: it should happen in mboned with mtrace.

Stig: Is there an interest in this type of statistic info/debugging
within this wg?
(6 or so hands)

Mike: 
draft-mmcbride-pim-refresh-problem-statement-01
problem statement refresh draft completed. Please review. Welcome any
and all comments. The problem listed is in reference to mvpn, pim from
pe to pe. A few possible solution listed also.

Mike: 
draft-wen-pim-improved-register-00
Alcatel gentlemen in China submitted this draft but not able to attend
this ietf and requested we present it for them. It discusses a way to
improve the register process in sm. The review the expensiveness of
encapsulation from dr to rp. And how to not rely on the data plane to
set up the control plane. They propose not sending data from source
until state is created. Extensions to igmp or new protocol so source can
advertise that its interested in sending data. Having sender send a
sender request to dr, no data. The dr sends a register request to rp. rp
has the option to send joins towards source. The dr would then send a dr
ack or nack and the dr would also send an spt ok towards the rp. The
data would then flow. Trying to simplify the process, take burden off
the routers. 

Fenner: Trying to get rid of the requirement to look in the data plane
to set the spt bit?

Mike: right

Fenner: This is one of the things that has been one of the biggest
complaints of pim. This is a change to the existing model that the
senders don't have to do anything except send. Perhaps that needs to
change. To allow senders to send without doing anything, this is the
original model. 

Atwood: This would help secure multicast where you need to authenticate
the receivers and senders. It would be a useful trigger.

Mike: yes, the draft specifies the dr sending a dr nack if they were not
permitted.

Toerless: this is a dependency of a rewrite of rfc 1112 as the service
model that would be required. We did ssm in 2000 and that was a new
model. This is a good idea, same problems we've had for years.

Stig: Worried about changing the service model. But would be cool to do
bidir with embedded rp if you had this.

Beau Williamson: This is something that has been missing. But not
holding breath, we could start considering. While we are doing this, we
should introduce a request to send and clear to send.

Mike: the authors do have a sender alive and sender leave proposal.

Dino: Microsoft, in the day when they were intested in mcast, wanted a
request to send. They wanted router vendors to take the rsvp path
message and make that look like a request to send message. They backed
off from that but that could be a solution. Periodic, not end to end
acks. When path messages received from DR it could do all the back end
stuff being done here.

Stig: Also have had the msnip stuff which could be merged with this. 

Beau: The title is misleading, should be sender signalling. Could also
have the sender advertise how fast he intends to go.

Andy Kessler: This is a piece of the bigger picture of controlling
sources completely. Have to authenticate as part of aaa. Authenticated
at a particular rate. Its part of the bigger scheme, we should
authenticate sources, profile what they can send to and rate limit.

Dino: The disadvantage of changing the service model is what would a
brokerage firm say about its send latency when there is a short rtt and
long rtt and queuing delays from dr to rp. Send latency would be
affected by this.

Mike: we will take these comments to the authors and let them take it to
the list.







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