Subject: Re: [rbridge] Do people prefer new ISIS PDU types for advertising multicast groups?

From: Ayan Banerjee <[email-masked]>
Date: Tue, 04 May 2010 23:08:58 -0700

I believe that we had substantial discussion on the merits of this approach.
I have attached a pointer to the meeting minutes on this after IETF-73 -
http://tools.ietf.org/wg/isis/minutes?item=minutes73.html . There was also a
lot of discussion on this during the Feb/March/April 2009 timeframe in the
IS-IS WG mailing list on this.

In summary, the reasons outlined during those discussions are:
- Separation is desired since the join/leave frequency
  of the multicast members will be much higher than unicast topology
  changes.
- Opens up space for additional fragments to improve scalability
  and carrying capacity of the base protocol
- Operational convenience of having separate unicast and
  multicast information.
- Use of other extensions to the protocols, like Extended LSP,
  Multi-Instance support etc, just fall in place.

This additional PDU introduces very minimal complexity into the process. The
update process of MGROUP-PDU follows the exact same design/update flow as
the regular PDU. This flow is well understood and other than just
maintaining a parallel database, there is really not much of a concern here.

This PDU has been out there in the WG for 18 odd months now. I am a bit
concerned about changing things at this juncture, when we should be really
wrapping things up.

Thanks,
Ayan

On 4/28/10 1:33 PM, "Radia Perlman" <[email-masked]> wrote:

> But I still prefer not doing anything; no flag, no new PDU types.
> 
> IS-IS as originally designed for DECnet/CLNP had endnode information
> in LSPs. The same argument could have been made back then -- that
> there should be a different type of LSP for the endnode information
> because that wouldn't trigger SPF, and would be more volatile.
> 
> Merely recommending that the more volatile, non-SPF-producing
> information go into separate fragments, seems solution enough. Any RB
> not following that will cause a bit of suboptimality, but no other
> problems.
> 
> Radia
> 
> 
> 
> On Wed, Apr 28, 2010 at 12:48 PM, James Carlson
> <[email-masked]> wrote:
>> Radia Perlman wrote:
>>> Re: James question below
>>> 
>>> Ah. I was assuming that you'd only set the flag if the fragment only
>>> contains endnode information, and that fragment number NEVER contained
>>> anything but endnode information.
>>> 
>>> I think you were assuming I was recommending you'd set the flag if the
>>> adjacencies reported there haven't changed, or that previous sequence
>>> numbers of that fragment contained adjacencies that got removed from
>>> that fragment because of going down, or being moved to another
>>> fragment.
>> 
>> Exactly.
>> 
>>> I was recommending setting the flag only if the only TLVs in the
>>> fragment are endnode type information (which in TRILL would only be
>>> multicast groups), and that fragment n *never* contained anything but
>>> endnode information (though it's not a problem if those adjacencies
>>> get moved to a different fragment...it's just a problem if they go
>>> away and their absence is SPF-relevant information). If advertising
>>> multicast groups is relegated to its own fragment, then this wouldn't
>>> be a problem.
>> 
>> Based on what I remember in Quagga, I think that might be hard to
>> achieve there, but I can imagine that someone who tracks fragment
>> contents over time more carefully could do this.
>> 
>> Thanks; I get it now.  I'm not sure where (in what implementation) it'd
>> be workable, but at least I understand how it'd function.
>> 
>> --
>> James Carlson         42.703N 71.076W         <[email-masked]>
>> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 7 May 2010 18:23:39 -0700

I agree.  We should not make any changes unless they
are absolutely needed.

Anoop

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Radia Perlman
> Sent: Wednesday, April 28, 2010 1:34 PM
> To: James Carlson
> Cc: [email-masked]
> Subject: Re: [rbridge] Do people prefer new ISIS PDU types for
> advertising multicast groups?
>

---

From: "Hari Balasubramanian (harih)" <[email-masked]>
Date: Wed, 26 May 2010 08:14:54 -0700

I agree with Ayan's comments here. It has been the understanding of early implementers of TRILL spec that the pros and cons of using new ISIS PDU types for advertising multicast groups  were discussed and  it was agreed to use new PDU types as early as April 2009. It has been more than an year since such an understanding was reached and it is concerning that the issue is being opened again. Are there any new concerns that are being raised now that did not come up during the discussions last year? 

I understand the early implementers of any protocol, especially before standardization, should be well aware of the risk of some churn in the specs, based on wider comments etc. But I believe it is not unreasonable to hope that the approaches on which a consensus was developed will substantially retain the structure as per the consensus, especially the ones that have been made an year or more back.

Thanks, Hari

> Behalf Of Ayan Banerjee (ayabaner)
> Sent: Tuesday, May 04, 2010 11:09 PM
> To: Radia Perlman; James Carlson
> Cc: [email-masked]

---

From: Radia Perlman <[email-masked]>
Date: Wed, 26 May 2010 09:45:20 -0700

It was never discussed on the TRILL list, and a lot of people
(including me) assumed that the l2-ISIS spec was just defining syntax
of the fields explicitly called out in the TRILL protocol spec, which
lists all the fields to be included in Hello and LSP.  A design issue
like that should be discussed on the TRILL mailing list and, if there
were a consensus in TRILL for something like that, it should be
covered in the TRILL protocol spec (in addition to having the syntax
in the l2-ISIS spec).

So, definitely I'm sorry I didn't pay more attention to that spec,
but my understanding was that the fields TRILL needed were explicitly
listed in the TRILL protocol document, and so I assumed the l2-isis
document was just syntax, so I could safely ignore it.

Radia

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 28 May 2010 05:44:24 -0700

> I agree with Ayan's comments here. It has been the understanding of early implementers of TRILL spec that the pros and cons of using new ISIS PDU types for advertising multicast groups  were discus…

I don't recall such discussion in the TRILL WG. Do you have references 
to minutes or emails for the TRILL WG indicating when we discussed this?

Ayan was referring to ISIS minutes, which is different.

    Erik

>> On 4/28/10 1:33 PM, "Radia Perlman"<[email-masked]>  wrote:
>>

---

From: "Hari Balasubramanian (harih)" <[email-masked]>
Date: Fri, 28 May 2010 06:25:50 -0700

> Do you have references

Sorry, I do not recall any emails on TRILL WG on this topic. I was also
referring to ISIS WG minutes.

Thanks, Hari

> Behalf Of Erik Nordmark
> Sent: Friday, May 28, 2010 5:44 AM
> To: [email-masked]
> > I agree with Ayan's comments here. It has been the understanding of
> early implementers of TRILL spec that the pros and cons of using new
> ISIS PDU types for advertising multicast groups  were discussed and
it
> was agreed to use new PDU types as early as April 2009. It has been
> more than an year since such an understanding was reached and it is
> concerning that the issue is being opened again. Are there any new
> concerns that are being raised now that did not come up during the
> discussions last year?
> 
> > I understand the early implementers of any protocol, especially
> before standardization, should be well aware of the risk of some churn
> in the specs, based on wider comments etc. But I believe it is not
> unreasonable to hope that the approaches on which a consensus was
> developed will substantially retain the structure as per the
consensus,
> especially the ones that have been made an year or more back.
> >
> > Thanks, Hari
> >
> >> From: [email-masked]
[mailto:[email-masked]]
> On
> >> I have attached a pointer to the meeting minutes on this after
IETF-
> 73
> >> -
> >> http://tools.ietf.org/wg/isis/minutes?item=minutes73.html . There
> was
> >> also a
> >> lot of discussion on this during the Feb/March/April 2009 timeframe
> in
> >> the
> >> update process of MGROUP-PDU follows the exact same design/update
> flow
> >> as
> >> maintaining a parallel database, there is really not much of a
> concern
> >> here.
> >>
> >>>>> I think you were assuming I was recommending you'd set the flag
> if
> >> the
> >>>>> multicast groups), and that fragment n *never* contained
anything
> >> but
> >>>> Thanks; I get it now.  I'm not sure where (in what
implementation)
> >> it'd

---

From: Jukka Manner <[email-masked]>
Date: Fri, 28 May 2010 17:43:08 +0300

Hi,

I was wondering, has anyone done a detailed analysis of the threats 
associated with deploying and using TRILL? All the WG documens basically 
just go around the topic by comparing and refering to other similar 
technologies and saying that TRILL should not be worse.

Regards,
Jukka

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 May 2010 08:18:50 -0700

Hi, Jukka,

> technologies and saying that TRILL should not be worse.

While I realize that such analyses are currently popular, what exactly
is worth stating beyond "we're not worse than Ethernet"? Does that need
to be shown in detail, e.g., in regards to the protocols/mechanisms we add:

- IS-IS
	which we now depend on, rather than STP

- edge label tables
	which should have the same issues as ARP

It would be useful to point us to a similar threat analysis of Ethernet
to build upon, but the key question I would have is:

	what do you expect in this doc that isn't already in
	the Security Considerations of the RFCs?

Joe

---

From: Jukka Manner <[email-masked]>
Date: Fri, 28 May 2010 18:44:58 +0300

Hi Joe,

I was mostly thinking in the direction of

a) Deployment guidelines: what people should understand when looking for 
deploying TRILL. Yes, concrete details would be good.

b) Future work: how could we make TRILL more secure and trustworthy than 
legacy Ethernet since we don't need to carry all that legacy (yes, I 
know, the simplicity requirement of TRILL is against this).

I don't have a pointer to Ethernet for comparison.

Jukka

---

From: Andy Davidson <[email-masked]>
Date: Fri, 28 May 2010 17:11:48 +0100

On 28 May 2010, at 16:44, Jukka Manner <[email-masked]> wrote:

> a) Deployment guidelines: what people should understand when looking for deploying TRILL. Yes, concrete details would be good.

Yes, please. 

> b) Future work: how could we make TRILL more secure and trustworthy than legacy Ethernet since we don't need to carry all that legacy (yes, I know, the simplicity requirement of TRILL is against this).

No, thank you.  Not every packet on a network segment will pass through an inter switch link that encapsulates the frame inside a trill packet.  Therefore, operators will need to do everything at the security layer that they do today, and can't rely on new security features in trill. Let's stick to building a robust method to mesh layer 2 networks with loops, and get this shipped!

Andy

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 28 May 2010 10:28:25 -0700

> know, the simplicity requirement of TRILL is against this).

Earlier we had talked about the option of getting more security using 
the combination of:
  - IS-IS with reasonable security (something which already exists in IS-IS)
  - Using ESADI for host address announcements (supported in the 
standard with higher confidence then the learned addresses)
  - Using 802.1X or similar as the only want an edge rbridge would add a 
MAC address to its ESADI announcements.

If somebody wants to work on this it might make sense to right it up as 
an informational document. I don't think any new standards work would be 
needed - it is more a question about gluing together the pieces and 
looking at what the resulting security would be for such an approach.

    Erik

---

From: Joe Touch <[email-masked]>
Date: Sat, 29 May 2010 10:16:25 -0700

Hi, Jukka,

> know, the simplicity requirement of TRILL is against this).

I don't understand this goal; TRILL relies on Ethernet. Just as it can't make
Ethernet scale, it can't make Ethernet more secure than it already is.

*IF* we're going to address TRILL security, IMO it needs to be limited to the
ways in which TRILL extends Ethernet only.

Joe