Subject: [pim] PIM WG meeting notes

From: Mike McBride <[email-masked]>
Date: Thu, 18 Nov 2004 11:58:02 -0800 (PST)

Thanks to Marshall for the minutes:

IETF 61 : PIM WG
Tom Pusateri and Mike McBride presiding

Status of the new standard of PIM-SM -v2

For a new standard need

1. A well written spec - absolutely
2. Must have an Internet draft of the MIB - exists, plus a new draft in the works
3. Security architecture in the spec (they exist)
4. At least one implementation : We have at least Infosys, IOX, Xorp.

Isidor Kouvelas  : IOS is using it for IPv6

Mark Handley : We tried to make the spec backwards compatible as well, so
old implementations in a sense count too.

Tom Pusateri : But they were not written using the new spec, so they don't.

5. Major features tested. This is done using the deployed code

Mark Handley : for Xorp we have a pretty complete internal test suite.

6.) Write up and submission to the IESG.

This is in the works.

At that point, the document will be out of the WG.

----

Stig Venaas - [email-masked]

BSR spec. Graphs are at
http://domen.uninett.no/~venaas/bsrietf61.pdf

Issue :

How to withdraw RPs from  a group range

IWNH      - Implicit withdrawal of the RP, by not including it on the list
EW Expiry - Explicit : use a hold time of zero to withdraw an RP
IW        - combination of the above

Previous specs seemed to be IW or IWNH but not clear from the drafts.

Some backwards compatibility issues.

Which approach should the group back ? Each approach takes some real work, so we don't want to do
ones that are not needed. We need feedback as to  what implementations exist.

Mark Handley. The spec is badly done, so the intent does not matter.
These seem to be equivalent in practice. What we need to know is
what people are doing

Bharat from Infosystems : We use a hold time (EW) approach.

Paul Kepler of BG systems : We do implicit withdrawal, because that is how we read the spec.

Stig - We need to poll the group to see what the majority of people actually do.

-----
Stig - How to cope with IPv6 and admin scopes

Scopes are numerically 1,2,5,8,E, etc.

Scope 5 gives FFc5::/16

Each scope has 16 possible ranges.
FF05::/16 FF15::/16 FF25::/16 etc.

Don't want too have to specify 16 different ranges.

Is a simple 4 bit scope Identifier sufficient ?
How should we encode it ?

There may be issues with scopes with overlapping ranges
and unions of ranges.

Brian Habermann. I had a conversation with Steve Deering. The intent was that you should only look
at the 4 bits and the flags are irrelevant.

I would argue that you would want to keep it simple. Just use the 4 bits.

Toerless - What keeps one scope from being ASM and another being Bi-Dir ? Is that allowed ? I would
like to be able to do this.

Mike McBride : Some notes from the co-author :
We want to keep the v4 and v6 specs the same. If we only use 4 bits then v4 and v6 will diverge.

--------
PIM MIB
Bharat Joshi, Infosys India

How many people want this done ?
(About a 40% raise of hands.)

John Meylor - Don't correlate the amount of feedback with the importance of the draft.

Original Pim MIB authorized by J. Nicholas - expired May 2004
Defined Sparse and Dense Mode tables

IPv6 needs to be done - there is a document in review.
The tables are pretty similar with IPv4.

Bill Fenner - There was a proposed v6 MIB proposed, but so long ago that it is forgotten

Bharat - I looked for this but I couldn't find it. - can you send this to the list ?

Tom Pusateri - SHould it be referenced  assuming it can be found ?

Fenner - I think that this should be independent of the IPMroute MIB. A loose association between
the two tables is OK - the current tight association is not good.

Bharat : Actions :

Ran "smilint" on the MIB and fixed any problems
made changes to make the order proper
added a new object for interface BSR borders

Mark Handley : What is a BSR border ?
Bharat  : It is a BSR interface at a scope border
Mark - But that is not a PIM thing. It maybe should be somewhere else.

Bharat -
There may be changes because of changes in  PIM-SM and BSR drafts.

Road Map :

Need more reviewers of the draft
Need an extensive review of he IPv6 MIB
The result will be PIM MIB v 2

Tom Pusateri

There are separate IPv4 and v6 tables; these need to be combined.

Bharat
PIM MIB mailing list is at

http://www.mountain2sea.com/mailman/listinfo/pim-mib
[email-masked]
[email-masked]

Bill Fenner -
Can we combine this work back into the main PIM WG mailing list ?
----
Mike McBride - the following drafts are not yet part of the PIM WG. At MBONED we had discussion
about expanding the PIM work to include MPLS LSP and related topics.

Who would be open to expanding the PIM charter ? (Maybe 20 hands or 30%)
Who would not like to do this (no hands at all).

-----

PIM Proxy
Arjen Boers, Cisco Systems
IJsbrand Wijnands, Cisco Systems

How do you do PIM in networks with no routes towards  the RP ?

Solution : Use a proxy. There needs to be more information to do routes back to the RP. Do this by
adding TLV to the PIM join

Proxy types :

1.) Vector

Isidor Kouvelas : Why are you calling this a proxy ?

Arjen :  Because you can put a lot of things in the proxy.

2.) MDT-SAFI - for the interdomain or VPN case case

Vector plus RD is added to the proxy.

Can build an explicit path in the network

Isidor Kouvelas : Shouldn't the TLV's be defined in the draft ? Also, this means of  carrying
additional information is not the same as a proxy.

Yakov Richter - You want to explicitly route PIM join messages.
What is the problem you are trying to solve ?
The MDT-SAFI version is based on the Rosen draft, which was never approved by the L3VPN group.

How many providers would like to have a BGP free core ? That is what this is really aiming towards.

John Meylor : This is never adequately addressed in the working group. The providers have said that
that they need it.

Mark Handley. At times there are circular dependencies, and at some times
you just have to break them by moving on.

Mike McBride - the chairs will be meeting tomorrow to discuss these matters.

Arjen - We are not claiming to meet the requirements documents,

Yakov - we need the requirements before we consider solutions to those requirements.

Tom Pusateri - It might be useful to split this into 3 documents.

Isidor Kouvelas - I can see other applications here. This is a very basic building block.

John Meylor  - There have been service providers that have stood up and expressed interest in the
vector proxy draft.

Tom Pusateri - L3 and AT&T expressed interest on the list.

John Meylor - It is near miraculous to get 2 ISPs to discuss such interest on a mailing list.

Bill Fenner - I have heard that AT&T wants to remove BGP from the core to guard against possible
denial of service attacks on the core.

Mike McBride - L3 said on the mailing list that not having this is a competitive disadvantage.

Toerless - this is a modular component which can be used or not. What sort of solutions requirement
was requirement before IP source routing ? This is a pure control plain change.

Yakov - If you want to introduce this into PIM, found it on requirements from the requirements
document.

John Meylor - One thing that this IETF has done is to expose the absolute  confusion between some of
the IETF working groups.

Mark Handley - What are the deployment concerns - do you have to upgrade all of your PIM routers in
the domain  ?

Arjen - Correct.

------
Mike McBride-

Two new drafts

draft-farinacci-pim-pop-count-00

This introduces accounting information into the PIM join packets.

Not really a completely new protocol - but should it be in PIM ?

James Leelow from Data Connection - We need a generic TLV mechanism to add information to the PIM
Join. This should have a common format if it is going to be done at all.

Toerless - Which group is going to write a requirements document for this

Tom Pusateri - I do not think that this is productive. No one on the list has been arguing for this
(the POP-Count draft). As for the proxy draft, Mike and I will be meeting with the other working
group chairs

Toerless - I think that there is an abuse of process. Why  should feedback from other WG always be
required to pass judgment on a draft before it goes forward ? This can always be used to shoot down
a draft.

John Meylor - Multipoint LSP is a tough nut to crack, so working with other working groups makes
sense.

-----

draft-atwood-pim-sm-linklocal-00

This draft makes it so that the anti-replay mechanism is not disabled, as is the case for the PIM-SM
draft.

One comment on the list, from Pekka, said that link local threats to PIM should be added to MAGMA
draft dealing with link-local drafts for IGMP and MLD.

Brian Habermann - Greg's draft for MAGMA is just a individual submission.
This probably should not be added to that - this would be applicable to other routing protocols than
PIM.

Tom Pusateri - At the L3VPN WG meeting, it was suggested to add state refresh reduction to PIM. This
is an RFC for this for RSVP, so that might be used as a template.

Toerless - What else should be added to PIM once the proposed standard is published ?

Pusateri - When you start getting large amounts of (S,G) it starts to be an issue to refresh it all
every 60 seconds.

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 18 Nov 2004 15:56:20 -0800

>> (the POP-Count draft). As for the proxy draft, Mike and I will be meeting with the other working

    Tom, why can't the working group be innovative and build something  
    without a requirement? Sometimes, when you build it, they will come.

Dino

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 18 Nov 2004 19:21:44 -0800

Dino,
	I think the notes are a little scrambled here.

1. When I said "I do not think this is productive" I was referring to
   a smart remark someone made during the meeting.

2. As far as the pop count draft goes, its not really my decision.
   The issue was brought before the working group on the mailing list
   and the working group was asked if they wanted to adopt this
   work. There were 5 responses all suggesting changes or other
   places to do this work. There were no responses in favor.
   The working group chairs didn't vote either way or try to promote
   it or obstruct it. We went for concensus as we are supposed to do.

3. In the case of the proxy draft, there was not consensus.

Thanks,
Tom

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 19 Nov 2004 09:24:45 -0500

Tom is clearly correct. At that stage in the meeting there were a
number of side remarks being made
and the "productive" remark refers to those remarks, not the draft. I
apologize if I gave the wrong
 impression in the minutes. (FWIW I agree with Tom in his assessment
of those remarks.)

I do support the POP count effort, and I think others do too, I am
just not sure it belongs in PIM.

Someone suggested that the POP count could be done as an application;
I suggested a stand alone protocol. I am dubious in general about
overloading one protocol with messages for another. Dino, can you give
us reasons why this belongs in the PIM join message as opposed to
somewhere else ?

Will MPLS LPS require additional information in the PIM join, as James
Leelow seemed to indicate ?
Is there a draft or even a presentation or memo on this ?

If this is really being opened up, it certainly makes Dino's idea less
of a stretch for PIM, as it could be included in the more general
changes.

Regards
Marshall Eubanks

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 19 Nov 2004 19:26:39 -0800

>> us reasons why this belongs in the PIM join message as opposed to

    So you have sub-tree information at every hop. So you can get the 
    information quickly without polling. If it was easy to do at the app
    level, why hasn't it been done already.

    It's not a protocol. It's data that can be carried with and processed the
    same time with join state. It's trying to be efficient.

>> Is there a draft or even a presentation or memo on this ?

    I missed the IETF so didn't see this comment. What was the comment?

Dino

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 20 Nov 2004 05:04:28 -0500

Well, I can see several problems with doing it as an app - it would be
hard to get the app everywhere.

James suggested that the newly hot MPLS LSP will need TLV info in the PIM join :

>James Leelow from Data Connection - We need a generic TLV mechanism
to add information to the PIM >Join. This should have a common format
if it is going to be done at all.

I haven't waded through the 5 L3VPN  multicast drafts enough to know
what he is referring
to yet.

Marshall

---

From: Marc Manthey <[email-masked]>
Date: Sat, 20 Nov 2004 23:02:29 +0100

On Nov 20, 2004, at 11:04 AM, Marshall Eubanks wrote:

> Marshall--

hello all

during my  research  found something interesting  here:

.... the authentication of Intermediate System to
    Intermediate System (IS-IS) Protocol Data Units (PDUs) using the
    Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5)
    algorithm as found in RFC 2104...........

http://rfc.sunsite.dk/rfc/rfc3567.html

is there a way to implement this ?

http://brain.let.de