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

["Acee Lindem (acee)" <[e-mail]>]

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=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.
>