Re: [Isis-wg] draft-ginsberg-isis-l2bundles

["Ahmed Bashandy (bashandy)" <[e-mail]>]

Sorry for the late reply

So now we have a 4th proposal, which is to have a mix of L2 and L3 
bundles and somehow modify applications on routers as well as management 
tools to pick and choose what links and IP prefixes to use. Let's add it 
to the table and see how it scores. I added new 5 rows, which are 
"provisioning overhead", "code change", "Works with RSVP", "Two way 
connectivity check", and  "Must deconfigure/reconfigure L2 bundles". The 
last row is particularly important for users who extensively use L2 
bundles with large number of links (16, 32, 64,..., etc)

BTW, as Ebben and myself replied to Hannes, we do not understand how 
BGP-LS can be used without IGPs. Instead we think it is a complimentary 
solution. But I am adding it here for the sake of argument
Also there is no use case for the "two way connectivity" check on 
individual L2 bundle member and "working with RSVP". But again I added 
them for the sake of argument


	ISIS to advertise L2 bundles 	BGP-LS to advertise L2 bundle 	L2 bundles 
as unnumbered interfaces in ISIS 	Mix or L2 and L3 bundles as in ISIS
Scalability 	Minimal scale overheard (+1) 	Minimal scale overhead (+1) 
Significant scale overhead: Number of advertised links and ISIS 
adjacencies are multiplied by average number of bundle members(-1) 	VERY 
significant Scale overhead
- Number of advertised links and ISIS adjacencies multiplied by number 
of bundle members
- Number of advertised and downloaded prefixes multiplied by the average 
number number of bundle members
(-2)
Mandate the deployment of a protocol that was not deployed before 	No 
(+1) 	Yes (-1) 	No (+1) 	No (+1)
Impact on basic routing functionality 	Minimal (+1) 	Minimal (+1) 
Significant (-1): Sharp increase in the number of links in LSDB and 
SPF 	 VERY Significant (-2):
- Sharp increase in the number of links in LSDB and SPF
- sharp increase in number of prefixes to download to RIB and FIB
Works for both P2P and LAN 	Simple (+1) 	Simple (+1) 	Difficult (-1)
	Simple (+1)
Using 1 protocol for diverse functionilities 	Yes (+1) 	No (-1)
	Yes (+1) 	Yes (+1)
Exposing L2 info in L3 protocoL 	Yes (-1) 	Yes (-1) 	No (+1) 	No (+1)
Protocol change 	Yes (-1) 	Yes (-1) 	No (+1) 	No (+1)
Risk 	Small (Minimal impact on baseline functionality and managements 
tools while not deploying any new protocol) (+1) 	Medium (Have to deploy 
BGP-LS everywhere) (0) 	Significant (Have to make sure that baseline 
functionality on all routers as well as management and monitoring tools 
are not impacted by the sharp increase in number of links) (-1) 	VERY 
Significant (Have to make sure that baseline functionality on all 
routers as well as management and monitoring tools are not impacted by 
the sharp scale increase in both number of links and IP prefixes) (-2)
Provisioning Overhead
	Small: Only need to enable the CLI under ISIS (+1)
	Medium: (Have to configure BGP-LS everywhere) (0) 	Significant: Have to 
deconfigure the bundle interfaces and make members unnumbered then add 
the member interfaces under ISIS process (-1)
	VERY significant:
- Have to deconfigure the bundle interfaces and add them under ISIS
- Have to configure and maintain a very large number of prefixes between 
adjacent routers and make sure there is no prefix mismatch between peers 
(-2)
Code change
	Medium: Only change to ISIS (0)
	Medium: Only change to BGP (0)
	None: can be achieved with current code (+1)
	Very intrusive code change (-2)
- Have to make changes to many application on the router to be able to 
somehow selectively ignore or handle the significant increase in the 
number of IP prefixes and L3 links
- Have to make changes to the management and monitoring tools to 
selectively ignore and/or handle increas in both number links and number 
of prefixes
Works with RSVP without RSVP modification
	No (-1)
	No (-1)
	Yes(+1)
	Yes (+1)
Two way connectivity check
	Simple because the draft allows advertising most of subTLVs in TLV22 in 
the bundle attribute TLV. Hence a router can  include Sub-TLV 4 (+1) 	I 
do not think it is possible (-1)
	Simple using existing ISIS functionality (+1)
	Simple using existing ISIS functionality (+1)
Must deconfigure/reconfigure L2 bundles
	No (+1)
	No (+1)
	yes (-1)
	Yes (-1)
Sum
	6
	-2
	1
	-3



Thanks

Ahmed



On 8/18/2015 1:28 AM, [e-mail] wrote:
>
> Hi,
>
> I understood from the discussion during the WG meeting about the use 
> case of this proposal, that this is useful for traffic engineering 
> (mostly/only ?) and people wanted to keep hiding the physical topology 
> for other applications (LDP, IGP routing, multicast ?). The criteria 
> is not clearly highlighted in the table.
>
> What I’m saying here, is that with solution #4, we can achieve the 
> same goal without any standardization, just a local feature.
>
> Unnumbered vs not unnumbered is just optimizing IP address space 
> usage, other solution possible : use /31 for p2p, or use IPv6.
>
> Solution#4 is having an IP layer on each interface (unnumbered or 
> not), and creating adjacencies on each link in addition to the LAG 
> (this require some code change as it’s not possible AFAIK today) :
>
> Interface Port-Channel1
>
> Ip address 1.1.1.1/30
>
> Ip router isis
>
> !
>
> Interface Eth0
>
> Ip address 2.2.2.1/30
>
> Ip router isis
>
> Channel-group 1
>
> !
>
> Interface Eth1
>
> Ip address 2.2.3.1/30
>
> Ip router isis
>
> Channel-group 1
>
> !
>
> Based on this each application can choose to use LAG or Layer 3 bundle 
> or individual links.
>
> Moreover having an adjacency on a topological link is IMO better, as 
> it will allow to ensure that the link is almost working properly (MTU 
> OK, two way connectivity OK).
>
> In addition, the solution works with RSVP-TE also while the one you 
> provided is SR only.
>
> Hope it helps,
>
> Stephane
>
> *From:*Les Ginsberg (ginsberg) [mailto:[e-mail]]
> *Sent:* Monday, August 17, 2015 23:36
> *To:* LITKOWSKI Stephane SCE/IBNF; Ahmed Bashandy (bashandy); Acee 
> Lindem (acee); Ebben Aries; [e-mail] <mailto:[e-mail]> 
> list ([e-mail] <mailto:[e-mail]>)
> *Subject:* RE: [Isis-wg] draft-ginsberg-isis-l2bundles
>
> Stephane –
>
> I guess I don’t understand what you mean when you say:
>
> “With solution #4, you have the choice per protocol/application to use 
> the LAG or individual interfaces.”
>
> Do you mean that it is not necessary to have L3 adjacencies on all 
> interfaces? If so, even with the solution defined in the draft it is a 
> local matter as to what L2 bundle members are advertised. It could be 
> all of them or a subset – that is a matter for local configuration and 
> does not need to be standardized. This is why I said your new column 
> seems no different than Ahmed’s existing column 3 – other than perhaps 
> you are suggesting we should not use unnumbered – in which case I 
> think you have made using L3 adjacencies more onerous.
>
> Please clarify.
>
> Thanx.
>
> Les
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.