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

[<[e-mail]>]

The gain is that there is no need for a new ISIS extension, you can use TLV22 as usual.
IMO, maintaining a real adjacency is not a big deal moreover it allow for detection of MTU mismatch ...
And as the interface is an IP interface, there is no more "layer breakage".

So to do this, no need of IETF standardization, just local behavior on the node.


-----Original Message-----
From: Acee Lindem (acee) [mailto:[e-mail]] 
Sent: Friday, August 07, 2015 02:08
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, 10:31 AM, "[e-mail]"
<[e-mail]> wrote:

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

I don’t think you’d want to establish a separate adjacency over each of the LAG constituent links. I guess you may be inventing a lower overhead adjacency similar to a TE forwarding adjacency (RFC 4206) to represent the constituents. This would also work but I don’t see that much difference from the existing proposal other than the abstraction and that you have an anchor point for TE attributes (which could be a good thing if these proliferate). 

Thanks,
Acee 


>
>
>
>
>-----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=75085ca9001f9
>>>>> c
>>>>> 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.fran
>>>>> c
>>>>> e
>>>>> t
>>>>> e
>>>>> lecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.franc
>>>>> e
>>>>> t
>>>>> e
>>>>> l
>>>>> ecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526
>>>>> r
>>>>> 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=GJQFPrZyyh453y
>>>>> w
>>>>> 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.fran
>>>>> c
>>>>> e
>>>>> t
>>>>> e
>>>>> lecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.franc
>>>>> e
>>>>> t
>>>>> e
>>>>> l
>>>>> ecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526
>>>>> r
>>>>> 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=GJQFPrZyyh453y
>>>>> w
>>>>> 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/ma
>>>>> i
>>>>> l
>>>>> m
>>>>> a
>>>>> n/listinfo/isis-wg&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh4
>>>>> 5
>>>>> 3
>>>>> y
>>>>> w
>>>>> aGV%2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U
>>>>> %
>>>>> 3
>>>>> D
>>>>> %
>>>>> 0A&s=3211164dcbc94ec39a7390a5d1c8371f2c391ec0aeec8806884c6abfd4415
>>>>> 1
>>>>> 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.
>


_________________________________________________________________________________________________________________________

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.