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

[<[e-mail]>]

Acee,

Another possibility to address the requirement of TE per link within a LAG bundle may be to create L3 adjacencies on each link in addition to an adjacency for the bundle. This does not work today but ...
This would be a new way to manage LAGs, IMHO (as I'm not an implementor), I don't see a reason for this to not work theorically. 
Then each L3 protocol has the choice to use a bundle-view or a per-link view. You will create more IGP adjacencies but that's not a big deal (CPU are quite big now :) ).
This behavior is more clear than the one proposed in the draft, as the target is to provide a kind of layer 3 forwarding on layer 2 links ... here this would be a true layer 3 forwarding on layer 3 links.

Example :

Interface Port-Channel1
 Ip address 1.1.1.1/30
 Ip router isis 
 Isis metric 100
!
Interface Te10
 Ip address 2.0.0.1/30
 Channel-group 1
 Ip router isis
 Isis metric max-metric
!
Interface Te20
 Ip address 3.0.0.1/30
 Channel-group 1
 Ip router isis
 Isis metric max-metric
!

Thoughts ?




-----Original Message-----
From: Acee Lindem (acee) [mailto:[e-mail]] 
Sent: Thursday, August 06, 2015 15:34
To: LITKOWSKI Stephane SCE/IBNF; Ebben Aries; [e-mail] list ([e-mail])
Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles



On 8/6/15, 9:19 AM, "[e-mail]"
<[e-mail]> wrote:

>I think this may have implications beyond SR but it seems there are 
>other areas where LAGs (aka, link-bundles) have permeated into L3 
>(e.g., BFD - RFC 7130).
>
>[SLI] Fully agree, IMO, we must not let the doors wide open to this 
>kind of permeation.

LAGs are ubiquitous and I think we are going to have to accommodate them in L3 protocols even if it is a layer violation. But this is just my opinion. 

Thanks,
Acee 



> 
>
>
>-----Original Message-----
>From: Acee Lindem (acee) [mailto:[e-mail]]
>Sent: Thursday, August 06, 2015 14:53
>To: LITKOWSKI Stephane SCE/IBNF; Ebben Aries; [e-mail] list
>([e-mail])
>Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles
>
>Hi Stephane,
>
>
>On 8/6/15, 4:01 AM, "[e-mail]"
><[e-mail]> wrote:
>
>>Hi Acee,
>>
>>Some comments inline
>>
>>-----Original Message-----
>>From: Acee Lindem (acee) [mailto:[e-mail]]
>>Sent: Wednesday, August 05, 2015 19:24
>>To: LITKOWSKI Stephane SCE/IBNF; Ebben Aries; [e-mail] list
>>([e-mail])
>>Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles
>>
>>Hi Stephane,
>>I think the IS-IS advertisement is merely a consequence of the fact 
>>that we are satisfying the requirement of incorporating these L2 links 
>>in the segment routing path.
>>[SLI] Yes, and IMO, that's bad.
>
>
>
>>- I still have some doubt on the reason to split LAGs for TE and 
>>keeping bundles for other protocols.
>>- Regarding TE, I don't really see how BW use cases can work with 
>>this, as there may be some TE tunnels using the bundle and some using 
>>specific link, so evaluating the remaining BW per link and for the 
>>bundle is hard.
>>- This "breaks" layers, IGP exposes Layer 3 topology by design, not 
>>layer
>>2 ... if we want to expose layer 2, that's not an issue, it's a kind 
>>of multilayer TE approach and BGP-LS may so come in the picture and is 
>>a good candidate to retrieve topological information. I do not want to 
>>see IS-IS or OSPF becoming a topology discovery protocol for everything :
>>while it's related to the Layer 3 topology it's fine to me to keep it 
>>in the IGP for other informations, may be we need to find another way.
>>
>>
>> If we limit advertisement to BGP-LS, it will have the following impact:
>>
>>     1. All routers in the IS-IS domain that use link-bundles will 
>>need some form of BGP LS peering, either to the controller directly or 
>>through some intermediary.
>>[SLI] Agree but I don't see this as a negative point, as I think most 
>>networks running TE, already have a BGP controlplane that can be reused.
>
>If there is BGP-LS peering on all the routers, then I agree that this 
>would work given the right local policy to specify what BGP-LS 
>information each router advertises.
>
>Thanks,
>Acee
>
>
>
>
>>
>>     2. Since the link-bundle itself is an IS-IS L3 link, one would 
>>need to correlate the information with the corresponding IS-IS link 
>>state information (assuming not every IS-IS router advertises the 
>>entire LSDB).
>>[SLI] Agree there is a need of correlation, but correlation is 
>>required in all cases (in the current proposal, we advertise some 
>>parent link information).
>>
>>Additionally, any time the information is coming from multiple 
>>sources, you are likely to trigger path computation more frequently.
>>[SLI] I would say that's implementation dependent.
>>
>>
>>I don’t think this added complexity warrants omitting them from the 
>>IGPs if we do, in fact, accept link bundle adjacency steering as a 
>>requirement.
>>
>>Thanks,
>>Acee
>>
>>
>>On 8/5/15, 4:12 AM, "Isis-wg on behalf of [e-mail]"
>><[e-mail] on behalf of [e-mail]>
>>wrote:
>>
>>>Hi,
>>>
>>>Pls find some inline comments.
>>>
>>>-----Original Message-----
>>>From: Ebben Aries [mailto:[e-mail]]
>>>Sent: Wednesday, August 05, 2015 01:39
>>>To: LITKOWSKI Stephane SCE/IBNF; [e-mail] list
>>>([e-mail])
>>>Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles
>>>
>>>I see BGP-LS extensions complementing this, not necessarily as a 
>>>replacement.
>>>[SLI] It's for sure an option, but my point is do we need to continue 
>>>to add extensions to both IGP and BGP LS ?
>>>Moreover I still have an issue with propagating L2 informations into 
>>>layer 3 routing protocol  (not technically ... more from a design 
>>>perspective).
>>>Let's say that tomorrow, you would like to advertise some L1 
>>>information under your layer 2 information ... ?? As we are breaking 
>>>layers, if you want to advertise some underlay topology, I would be 
>>>in favor to not doing it in IGP.
>>>
>>>For a use-case of a central entity learning these underlying l2 
>>>attributes to then do whatever you wish (impose label stacks, etc..) 
>>>- BGP-LS is a natural fit.
>>>[SLI] Nothing prevents to use BGP-LS in a distributed computation model.
>>>
>>>For this to remain in the IGP, a consideration could be the 
>>>propagation of these L2 attributes to then be included in TEDs for 
>>>additional logic from headend nodes (network elements within the IGP
>>>domain) - e.g.
>>>control packet per member from a remote endpoint overriding remote 
>>>hashing either by some policy/SLA or dynamic based off of per member 
>>>utilization, etc..
>>>
>>>[SLI] Even if TED was previously populated only by IGP (because there 
>>>was nothing else), this is not the case anymore. TED is also 
>>>populated by BGP-LS and we may be able to create also new processes 
>>>to populate the TED. So you can imagine having your process managing 
>>>LAGs to add those L2 TE information into the TED and then being able 
>>>to export it through BGP-LS to other nodes through the BGP 
>>>controlplane, so every one will have the same content in the TED.
>>>
>>>
>>>On 08/03/2015 07:02 AM, [e-mail] wrote:
>>>> Hi,
>>>> 
>>>>  
>>>> 
>>>> Thinking again about this draft, I wondering why not using BGP-LS 
>>>> for that purpose ?
>>>> 
>>>> I mean, the goal here is just to provide some topological  
>>>>information that are not related to IGP, as you want to keep L2  
>>>>bundles and so a single IP link. If you want to expose the  
>>>>underlaying topology, you may be able to do it in BGP-LS rather than  
>>>>adding this in the IGP as the information you want to expose is not 
>>>>necessary for the IGP to run.
>>>> 
>>>>  
>>>> 
>>>> Thx
>>>> 
>>>>  
>>>> 
>>>> Orange logo
>>>> <https://urldefense.proofpoint.com/v1/url?u=http://www.orange.com/&
>>>> k
>>>> =
>>>> Z
>>>> VNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaGV%2FvoQ%3D%3D%0A&
>>>> m
>>>> =
>>>> x
>>>> DbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0A&s=75085ca9001f9c
>>>> 7
>>>> a
>>>> 2
>>>> 4e6f23efb57f50f5d79a97cbadcbfe1ce65082d335dba35>
>>>> 
>>>>  
>>>> 
>>>> *Stephane Litkowski *
>>>> Network Architect
>>>> Orange/SCE/EQUANT/IBNF/ENDD/NDE
>>>> 
>>>> Orange Expert Future Networks
>>>> 
>>>> phone: [phone]
>>>> <https://urldefense.proofpoint.com/v1/url?u=https://monsi.sso.franc
>>>> e
>>>> t
>>>> e
>>>> lecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.france
>>>> t
>>>> e
>>>> l
>>>> ecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526r
>>>> o
>>>> o
>>>> t
>>>> service%253DSIGNATURE%2526to%253D%26%2343%3B33%25202%252023%252028%
>>>> 2
>>>> 5
>>>> 2
>>>> 049%252083%2520&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453yw
>>>> a
>>>> G
>>>> V
>>>> %2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%
>>>> 0
>>>> A &
>>>> s=4490d282c20720cdbe8d3350c17a191e1762a7ea211ff404be972fddea2f62f3>
>>>> mobile: [phone]
>>>> <https://urldefense.proofpoint.com/v1/url?u=https://monsi.sso.franc
>>>> e
>>>> t
>>>> e
>>>> lecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.france
>>>> t
>>>> e
>>>> l
>>>> ecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526r
>>>> o
>>>> o
>>>> t
>>>> service%253DSIGNATURE%2526to%253D%26%2343%3B33%25206%252037%252086%
>>>> 2
>>>> 5
>>>> 2
>>>> 097%252052%2520&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453yw
>>>> a
>>>> G
>>>> V
>>>> %2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%
>>>> 0
>>>> A &
>>>> s=696fa2cd342bca61fdf5e849c8d3d76abe1075281d4218eaac873227641f9514>
>>>> [e-mail] 
>>>> <mailto:[e-mail]>
>>>> 
>>>>  
>>>> 
>>>>  
>>>> 
>>>> ___________________________________________________________________
>>>> _ _ _ ___________________________________________________
>>>> 
>>>> 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.
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Isis-wg mailing list
>>>> [e-mail]
>>>> https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mai
>>>> l
>>>> m
>>>> a
>>>> n/listinfo/isis-wg&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh45
>>>> 3
>>>> y
>>>> w
>>>> aGV%2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%
>>>> 3
>>>> D
>>>> %
>>>> 0A&s=3211164dcbc94ec39a7390a5d1c8371f2c391ec0aeec8806884c6abfd44151
>>>> 1
>>>> 0
>>>> 
>>>
>>>_____________________________________________________________________
>>>_ _ ___ _______________________________________________
>>>
>>>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.
>>>
>>>_______________________________________________
>>>Isis-wg mailing list
>>>[e-mail]
>>>https://www.ietf.org/mailman/listinfo/isis-wg
>>
>>
>>______________________________________________________________________
>>_ ___ _______________________________________________
>>
>>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.
>>
>
>
>_______________________________________________________________________
>___ _______________________________________________
>
>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.
>


_________________________________________________________________________________________________________________________

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.