Subject: Re: [pim] PIM WG meeting notes

From: James Lingard <[email-masked]>
Date: Mon, 22 Nov 2004 15:38:55 -0000

Marshall,

Let me clarify what I said during the meeting.

There are currently two individual Internet-Drafts being considered by the
WG that propose adding information to the Encoded-Source Address structure
used within the PIM Join/Prune message, namely:

-  draft-wijnands-pim-proxy-00
-  draft-farinacci-pim-pop-count-00.

In both of these drafts, the way of doing this is to define a new value of
the 'Encoding Type' field, which when used causes the structure to contain
several extra fields.

The point I made was that (without wanting to comment on the merit or
otherwise of either of these drafts themselves) if we are going to start
adding information to PIM Join messages, there are clear benefits in doing
this in a generic TLV-based mechanism, independent of any particular
extension.  The most significant advantage would be the ability to use
multiple such extensions simultaneously.

Responses to your particular questions are inline below.

Regards,
James.

-----Original Message-----
From: Marshall Eubanks [mailto:[email-masked]]
Sent: 19 November 2004 14:25
To: Tom Pusateri
Cc: [email-masked]; [email-masked]
Subject: Re: [pim] PIM WG meeting notes

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

The draft I was referring to was draft-farinacci-mpls-multicast-03.  This
draft proposed a similar mechanism to the two drafts mentioned above, which
was used to distribute MPLS labels.  Instead of using a new 'Encoding Type'
value, it used a new 'Addr Family' - though it seems to me that a new
'Encoding Type' might have been more suitable in this situation as well.
Although this draft is long expired, I had heard a rumour that there was
interest in reviving this work.

None of the current P2MP LSP drafts in the mpls working group require this
or any other modifications to PIM.

> 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.

Indeed.  Depending on your point of view, one of the benefits of a generic
approach would be that people who wanted to send extra information in
Join/Prune messages would be able to do so more easily, and in a way that
could be ignored by existing routers, just by defining a new TLV.

-- 
James Lingard
Data Connection Ltd (DCL)
http://www.dataconnection.com/

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

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 22 Nov 2004 10:12:44 -0800

>> the 'Encoding Type' field, which when used causes the structure to contain

    Yes, good point. I mentioned this to Ice after the PIM working group 
    meeting in San Diego.

>> multiple such extensions simultaneously.

    Yes. But I hope some day we can stop changing the protocol.  ;-)

Dino

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 23 Nov 2004 14:05:43 -0500

Dear James;

Thanks for clarifying this (and my apologies for not catching the
spelling of your name).

One thing I would worry about about doing these things in PIM are
security issues, such as what happens if the MTU is exceeded. It would
be clearly
better to have one generic extension than to have several ad hoc ones.

Regards
Marshall