Subject: Re: [CCAMP] New Version Notification for draft-li-ccamp-role-based-automesh-02.txt

From: "Daniel King" <[email-masked]>
Date: Wed, 2 Jul 2014 21:20:28 +0100

Hi Mach & Greg,

Having read the recent version of the I-D, I had some operational questions:

1. What happens if a malicious or misconfigured router joins a role-based
mesh-group? Is there anything (dangerous) that can be learned about the
network by inspecting role-based mesh-group TLVs?

2. Is it legitimate to set the Root and Leaf bits, what about setting all
the bits? Just wondering if there are certain role combinations that may be
defined as illegitimate. The I-D might also benefit from an error handling
sub-section. 

3. Are there scaling issues related to:

o The number of mesh groups that may exist?
o The number of mesh groups to which any router can belong?
o Is it possible by misconfiguration, design, or (again) maliciousness to
advertise a very large number of groups?  

4. The I-D was proposed early 2013, any update/feedback on implementations?
It would be worth raising awareness of "running code" for the proposal, as
per RFC6982. 

Br, Dan. 

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Mach Chen
Sent: 26 June 2014 09:28
To: [email-masked]
Subject: Re: [CCAMP] New Version Notification for
draft-li-ccamp-role-based-automesh-02.txt

Hi,

We uploaded an update for the role based auto mesh draft, we'd like you
could take a look at the draft, your suggestions and comments are always
welcome!

Thanks,
Mach

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, June 17, 2014 5:22 PM
> To: Mach Chen; Greg Mirsky; Lizhenbin; Mach Chen; Greg Mirsky; 
> Lizhenbin
> Subject: New Version Notification for 
> draft-li-ccamp-role-based-automesh-02.txt
> 
> 
> A new version of I-D, draft-li-ccamp-role-based-automesh-02.txt
> has been successfully submitted by Mach(Guoyi) Chen and posted to the 
> IETF repository.
> 
> Name:		draft-li-ccamp-role-based-automesh
> Revision:	02
> Title:		Routing Extensions for Discovery of Role-based MPLS
Label
> Switching Router (MPLS LSR) Traffic Engineering (TE) Mesh Membership
> Document date:	2014-06-17
> Group:		Individual Submission
> Pages:		14
> URL:
> http://www.ietf.org/internet-drafts/draft-li-ccamp-role-based-automesh
> -02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-li-ccamp-role-based-automesh/
> Htmlized:
> http://tools.ietf.org/html/draft-li-ccamp-role-based-automesh-02
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-li-ccamp-role-based-automesh-02
> 
> Abstract:
>    A Traffic Engineering (TE) mesh-group is defined as a group of Label
>    Switch Routers (LSRs) that are connected by a full mesh of TE LSPs.
>    Routing (OSPF and IS-IS) extensions for discovery Multiprotocol Label
>    Switching (MPLS) LSR TE mesh membership has been defined to automate
>    the creation of mesh of TE LSPs.
> 
>    This document introduces a role-based TE mesh-group that applies to
>    the scenarios where full mesh TE LSPs is not necessary and TE LSPs
>    setup depends on the roles of LSRs in a TE mesh-group.  Interior
>    Gateway Protocol (IGP) routing extensions for automatic discovery of
>    role-based TE mesh membership are defined accordingly.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at
tools.ietf.org.
> The IETF Secretariat

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Mach Chen <[email-masked]>
Date: Fri, 4 Jul 2014 06:10:32 +0000

Hi Dan,

Thanks for reading the draft, very good comments and questions.

Please see my reply inline...

> -----邮件原件-----
> 发件人: Daniel King [mailto:[email-masked]] 代表 Daniel King
> 发送时间: 2014年7月3日 4:20
> 收件人: Mach Chen; 'Gregory Mirsky'
> 抄送: [email-masked]
> 主题: RE: [CCAMP] New Version Notification for
> mesh-group?

This will result in establishing some unnecessary LSPs, but it should be far less than the amount of full-mesh.

> Is there anything (dangerous) that can be learned about the

By inspecting the role-based mesh-group TLVs, it will learn the roles of each LSR. IGP has already used to distribute many things that include topology, node capabilities, etc. IMHO, the role of an LSR is not special to those topology and node capabilities. But you are right, security consideration is always needed. We will think more about this.

> 
> 2. Is it legitimate to set the Root and Leaf bits, what about setting all the bits?
> Just wondering if there are certain role combinations that may be defined as
> illegitimate. The I-D might also benefit from an error handling sub-section.

We have plan to remove the P2MP part. But as for the combined role, there are indeed such some scenarios that a node may have both R and L, or both H and S role.

> o The number of mesh groups to which any router can belong?

Very good question, I have not data in hand, but we will try to collect the data and do some math work, and will share the data once we got it.

> advertise a very large number of groups?

For LSA/LSP advertisement, any misconfiguration, design, or (again) maliciousness will cause some unwanted advertisements, but I don't think it will cause large number of unnecessary advertisements, unless the configuration and design are really mess :-)

> It would be worth raising awareness of "running code" for the proposal, as per
> RFC6982.

As I know, there is an on-going implementation this time.

Thanks,
Mach

> We uploaded an update for the role based auto mesh draft, we'd like you could
> take a look at the draft, your suggestions and comments are always welcome!
> 
> Thanks,
> Mach
>