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

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

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

>- 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=75085ca9001f9c7a
>>> 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.francet
>>> e 
>>> lecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.francete
>>> l 
>>> ecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526roo
>>> t
>>> service%253DSIGNATURE%2526to%253D%26%2343%3B33%25202%252023%252028%25
>>> 2 
>>> 049%252083%2520&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaG
>>> V 
>>> %2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0A
>>> & s=4490d282c20720cdbe8d3350c17a191e1762a7ea211ff404be972fddea2f62f3>
>>> mobile: [phone]
>>> <https://urldefense.proofpoint.com/v1/url?u=https://monsi.sso.francet
>>> e 
>>> lecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.francete
>>> l 
>>> ecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526roo
>>> t
>>> service%253DSIGNATURE%2526to%253D%26%2343%3B33%25206%252037%252086%25
>>> 2 
>>> 097%252052%2520&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaG
>>> V 
>>> %2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0A
>>> & 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/mailm
>>> a 
>>> n/listinfo/isis-wg&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453y
>>> w 
>>> aGV%2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D
>>> %
>>> 0A&s=3211164dcbc94ec39a7390a5d1c8371f2c391ec0aeec8806884c6abfd4415110
>>> 
>>
>>_______________________________________________________________________
>>___ _______________________________________________
>>
>>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.
>