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

From: <[email-masked]>
Date: Mon, 3 Aug 2015 13:02:39 +0000

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]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE
Orange Expert Future Networks
phone: +33 2 23 28 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
mobile: +33 6 37 86 97 52 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
[email-masked]<mailto:[email-masked]>

_________________________________________________________________________________________________________________________

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.

---

From: Ebben Aries <[email-masked]>
Date: Tue, 4 Aug 2015 17:38:42 -0600

I see BGP-LS extensions complementing this, not necessarily as a
replacement.  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.

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

On 08/03/2015 07:02 AM, [email-masked] wrote:
> 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=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaGV%2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0A&s=75085ca9001f9c7a24e6f23efb57f50f5d79a97cbadcbfe1ce65082d335dba35>
> 
>  
> 
> *Stephane Litkowski *
> Network Architect
> phone: +33 2 23 28 49 83
> <https://urldefense.proofpoint.com/v1/url?u=https://monsi.sso.francetelecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.francetelecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526rootservice%253DSIGNATURE%2526to%253D%26%2343%3B33%25202%252023%252028%252049%252083%2520&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaGV%2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0A&s=4490d282c20720cdbe8d3350c17a191e1762a7ea211ff404be972fddea2f62f3>
> mobile: +33 6 37 86 97 52
> <https://urldefense.proofpoint.com/v1/url?u=https://monsi.sso.francetelecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.francetelecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526rootservice%253DSIGNATURE%2526to%253D%26%2343%3B33%25206%252037%252086%252097%252052%2520&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaGV%2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0A&s=696fa2cd342bca61fdf5e849c8d3d76abe1075281d4218eaac873227641f9514>
> [email-masked] <mailto:[email-masked]>
> 
>  
> 
>  
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailman/listinfo/isis-wg&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaGV%2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0A&s=3211164dcbc94ec39a7390a5d1c8371f2c391ec0aeec8806884c6abfd4415110
>

---

From: <[email-masked]>
Date: Wed, 5 Aug 2015 08:12:50 +0000

Hi,

Pls find some inline comments.

-----Original Message-----
From: Ebben Aries [mailto:[email-masked]] 
Sent: Wednesday, August 05, 2015 01:39
To: LITKOWSKI Stephane SCE/IBNF; [email-masked] list ([email-masked])
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, [email-masked] wrote:
> 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=75085ca9001f9c7a2
> 4e6f23efb57f50f5d79a97cbadcbfe1ce65082d335dba35>
> 
>  
> 
> *Stephane Litkowski *
> Network Architect
> <https://urldefense.proofpoint.com/v1/url?u=https://monsi.sso.francete
> lecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.francetel
> ecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526root
> service%253DSIGNATURE%2526to%253D%26%2343%3B33%25202%252023%252028%252
> 049%252083%2520&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaGV
> %2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0A&
> s=4490d282c20720cdbe8d3350c17a191e1762a7ea211ff404be972fddea2f62f3>
> <https://urldefense.proofpoint.com/v1/url?u=https://monsi.sso.francete
> lecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.francetel
> ecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526root
> service%253DSIGNATURE%2526to%253D%26%2343%3B33%25206%252037%252086%252
> 097%252052%2520&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaGV
> %2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0A&
> s=696fa2cd342bca61fdf5e849c8d3d76abe1075281d4218eaac873227641f9514>
> ______________________________________________________________________
> ___________________________________________________
> 
> 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.
> https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailma
> n/listinfo/isis-wg&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453yw
> aGV%2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%
> 0A&s=3211164dcbc94ec39a7390a5d1c8371f2c391ec0aeec8806884c6abfd4415110
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 5 Aug 2015 17:24:07 +0000

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. 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.
     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).
Additionally, any time the information is coming from multiple sources,
you are likely to trigger path computation more frequently.

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 [email-masked]"
<[email-masked] on behalf of [email-masked]>
wrote:

>replacement.  
>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] 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.
>
>
>> 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.
>> 
>> privileged information that may be protected by law; they should not be
>>distributed, used or copied without authorisation.
>__________________________________________________________________________
>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,
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>https://www.ietf.org/mailman/listinfo/isis-wg

---

From: <[email-masked]>
Date: Thu, 6 Aug 2015 08:01:46 +0000

Hi Acee,

Some comments inline

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Wednesday, August 05, 2015 19:24
To: LITKOWSKI Stephane SCE/IBNF; Ebben Aries; [email-masked] list ([email-masked])
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.

     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 

wrote:

>[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 ?
>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.
>
>[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.
>
>
>> %2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0A
>> & s=4490d282c20720cdbe8d3350c17a191e1762a7ea211ff404be972fddea2f62f3>
>> %2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0A
>> & s=696fa2cd342bca61fdf5e849c8d3d76abe1075281d4218eaac873227641f9514>
>> _____________________________________________________________________
>> _ ___________________________________________________
>> 
>>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.
>_______________________________________________________________________
>___ _______________________________________________
>
>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 
>information that may be protected by law; they should not be

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 6 Aug 2015 12:52:52 +0000

Hi Stephane, 

On 8/6/15, 4:01 AM, "[email-masked]"
<[email-masked]> wrote:

>segment routing path.

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

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

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

---

From: <[email-masked]>
Date: Thu, 6 Aug 2015 13:19:22 +0000

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. 

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

Hi Stephane, 

On 8/6/15, 4:01 AM, "[email-masked]"
<[email-masked]> wrote:

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

>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.
>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.
>
>
>some form of BGP LS peering, either to the controller directly or 
>through some intermediary.

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).
>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
>
>
>>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.
>>> 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=75085ca9001f9c7
>>> a
>>> 2
>>> <https://urldefense.proofpoint.com/v1/url?u=https://monsi.sso.france
>>> t
>>> e
>>> lecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.francet
>>> e
>>> l
>>> ecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526ro
>>> o
>>> t
>>> service%253DSIGNATURE%2526to%253D%26%2343%3B33%25202%252023%252028%2
>>> 5
>>> 2
>>> 049%252083%2520&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywa
>>> G
>>> V
>>> %2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0
>>> A & 
>>> <https://urldefense.proofpoint.com/v1/url?u=https://monsi.sso.france
>>> t
>>> e
>>> lecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.francet
>>> e
>>> l
>>> ecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526ro
>>> o
>>> t
>>> service%253DSIGNATURE%2526to%253D%26%2343%3B33%25206%252037%252086%2
>>> 5
>>> 2
>>> 097%252052%2520&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywa
>>> G
>>> V
>>> %2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0
>>> A & 
>>> ____________________________________________________________________
>>> _ _ ___________________________________________________
>>> 
>>> As emails may be altered, Orange is not liable for messages that 
>>>have been modified, changed or falsified.
>>> Thank you.
>>> 
>>> 
>>> 
>>> https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mail
>>> m
>>> a
>>> n/listinfo/isis-wg&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453
>>> y
>>> w
>>> aGV%2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3
>>> D
>>> %
>>_ ___ _______________________________________________
>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 6 Aug 2015 13:34:18 +0000

>[SLI] Fully agree, IMO, we must not let the doors wide open to this kind

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 

>would work given the right local policy to specify what BGP-LS
>information each router advertises.
>
>Thanks,
>Acee 
>
>
>
>
>>

---

From: <[email-masked]>
Date: Thu, 6 Aug 2015 14:31:32 +0000

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:[email-masked]] 
Sent: Thursday, August 06, 2015 15:34
To: LITKOWSKI Stephane SCE/IBNF; Ebben Aries; [email-masked] list ([email-masked])
Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles

On 8/6/15, 9:19 AM, "[email-masked]"
<[email-masked]> 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).
>

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 

>>- 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 
>>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 
>>     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 
>>[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.
>>>layers, if you want to advertise some underlay topology, I would be 
>>>in favor to not doing it in IGP.
>>>
>>>attributes to then do whatever you wish (impose label stacks, etc..) 
>>>- BGP-LS is a natural fit.
>>>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.
>>>
>>>
>>>> ___________________________________________________________________
>>>> _ _ _ ___________________________________________________
>>>> 
>>>>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.
>>>> 
>>>> 0A&s=3211164dcbc94ec39a7390a5d1c8371f2c391ec0aeec8806884c6abfd44151
>>>> 1
>>>> 0
>>>> 
>>>
>>>_ _ ___ _______________________________________________
>>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 7 Aug 2015 00:07:57 +0000

Hi Stephane, 

On 8/6/15, 10:31 AM, "[email-masked]"
<[email-masked]> 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

---

From: <[email-masked]>
Date: Fri, 7 Aug 2015 07:28:30 +0000

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:[email-masked]] 
Sent: Friday, August 07, 2015 02:08
To: LITKOWSKI Stephane SCE/IBNF; Ebben Aries; [email-masked] list ([email-masked])
Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles

Hi Stephane, 

On 8/6/15, 10:31 AM, "[email-masked]"
<[email-masked]> wrote:

>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.
>view. You will create more IGP adjacencies but that's not a big deal 
>(CPU are quite big now :) ).

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 

>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
>
>
>
>> 
>>
>>
>>>that we are satisfying the requirement of incorporating these L2 
>>>links in the segment routing path.
>>>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
>>>:
>>>need some form of BGP LS peering, either to the controller directly 
>>>or through some intermediary.
>>>>[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 ?
>>>>[SLI] Even if TED was previously populated only by IGP (because 
>>>>there was nothing else), this is not the case anymore. TED is also 
>>>>>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
>>>>> <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
>>>>> >
>>>>> <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
>>>>> >
>>>>> __________________________________________________________________
>>>>> _ _ _ _ ___________________________________________________
>>>>> 
>>>>>etant susceptibles d'alteration, Orange decline toute 
>>>>>responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>>> 
>>>>>privileged information that may be protected by law; they should 
>>>>>not be distributed, used or copied without authorisation.
>>>>> 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
>>>>> %
>>>>_ _ _ ___ _______________________________________________
>>>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 7 Aug 2015 14:43:00 +0000

Hi Stephane, 
I agree this clever solution could be made to work. However, once you
assign IP addresses to the constituents you are losing some of the
operational benefits that LAGs provide. Additionally, if we were to go
this route, I think we’d want a separate abstraction in order to avoid
misconfiguration (e.g., forgetting max-metric) and to optimize on the fact
that the adjacency will never be part of the topology. Finally, as a long
time IGP developer, I could never be a fan of a solution that requires
adjacencies that will not be part of the topology ;^)

Consequently, my vote would be to view this LAG constituent information
the same as we view other TE data that is not used by IS-IS itself. From
that perspective, it is much more palatable.

Thanks,
Acee  

On 8/7/15, 3:28 AM, "[email-masked]"
<[email-masked]> wrote:

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

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 11 Aug 2015 17:23:55 +0200

hi ebben,

what i haven't got my head around is why do we need this, given
that there is no IS-IS receive side functionality to be implemented
on routers and static labels (read: predictable) are preferred anyway ?

/hannes

On Tue, Aug 04, 2015 at 05:38:42PM -0600, Ebben Aries wrote:
| I see BGP-LS extensions complementing this, not necessarily as a
| replacement.  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.
| 
| 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..
| 
| On 08/03/2015 07:02 AM, [email-masked] 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=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaGV%2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0A&s=75085ca9001f9c7a24e6f23efb57f50f5d79a97cbadcbfe1ce65082d335dba35>
| > 
| >  
| > 
| > *Stephane Litkowski *
| > Network Architect
| > Orange/SCE/EQUANT/IBNF/ENDD/NDE
| > 
| > Orange Expert Future Networks
| > 
| > phone: +33 2 23 28 49 83
| > <https://urldefense.proofpoint.com/v1/url?u=https://monsi.sso.francetelecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.francetelecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526rootservice%253DSIGNATURE%2526to%253D%26%2343%3B33%25202%252023%252028%252049%252083%2520&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaGV%2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0A&s=4490d282c20720cdbe8d3350c17a191e1762a7ea211ff404be972fddea2f62f3>
| > mobile: +33 6 37 86 97 52
| > <https://urldefense.proofpoint.com/v1/url?u=https://monsi.sso.francetelecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.francetelecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526rootservice%253DSIGNATURE%2526to%253D%26%2343%3B33%25206%252037%252086%252097%252052%2520&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaGV%2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0A&s=696fa2cd342bca61fdf5e849c8d3d76abe1075281d4218eaac873227641f9514>
| > [email-masked] <mailto:[email-masked]>
| > 
| >  
| > 
| >  
| > 
| > _________________________________________________________________________________________________________________________
| > 
| > 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
| > [email-masked]
| > https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailman/listinfo/isis-wg&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaGV%2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0A&s=3211164dcbc94ec39a7390a5d1c8371f2c391ec0aeec8806884c6abfd4415110
| > 
| 
| _______________________________________________
| Isis-wg mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Mon, 10 Aug 2015 17:05:27 -0700

Folks

In attempt to provide a relatively quantitative measurement of the 
proposed solutions to the problem at hand, I thought I would prepared a 
small comparison table between ISIS for L2 bundles, BGP-LS for L2 
bundles, and changing all L2 bundles members to L3 links as unnumbered 
interfaces. I put +1 for (IMHO) what looks like an advantage, -1 for 
(IMHO) what looks like a disdavantage, and (0) what looks like a minor 
disadvantage or advantage

	ISIS to advertise L2 bundles
	BGP-LS to advertise L2 bundle
	L2 bundles as unnumbered interfaces in ISIS
Scalability
	Minimal scale overheard (+1)
	Minimal scale overhead (+1)
	Significant scale overhead (-1)
Mandate the deployment of a protocol that was not deployed before
	No (+1)
	Yes (-1)
	No (+1)
Impact on basic routing functionality
	Minimal (+1)
	Minimal (+1)
	Significant (-1)
Works for both P2P and LAN
	Simple (+1)
	Simple (+1)
	Difficult (unnumbered not easy with LANs) (-1)
Using 1 protocol for diverse functionilities
	Yes (+1)
	No (-1)
	Yes (+1)
Exposing L2 info in L3 protocol
	Yes (-1) 	Yes (-1) 	No (+1)
Protocol change
	Yes (-1) 	Yes (-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 scale increase) (-1)
Sum
	5
	-1
	-2

One Important point, I agree with Ebben that BGP-LS is not an 
alternative to using ISIS but rather a complementary solution to be used 
by networks that do not use ISIS and OSPF. If we assume that BGP-LS will 
be used by networks that already employ BGP, then using ISIS and BGP-LS 
will have almost the same score

Thanks

Ahmed

---

From: <[email-masked]>
Date: Mon, 17 Aug 2015 08:06:59 +0000

Hi Acee,

Inline.

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Friday, August 07, 2015 16:43
To: LITKOWSKI Stephane SCE/IBNF; Ebben Aries; [email-masked] list ([email-masked])
Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles

Hi Stephane,
I agree this clever solution could be made to work. However, once you assign IP addresses to the constituents you are losing some of the operational benefits that LAGs provide. 
[SLI] What benefits ? IMO, you are not losing anything as you can still use the single IP representing the LAG when you want.

Additionally, if we were to go this route, I think we’d want a separate abstraction in order to avoid misconfiguration (e.g., forgetting max-metric) and to optimize on the fact that the adjacency will never be part of the topology. 
[SLI] Sure this can be done by a local mechanism.

Finally, as a long time IGP developer, I could never be a fan of a solution that requires adjacencies that will not be part of the topology ;^)
[SLI] The link is part of the TE topology (but not the IGP routing one, at least in the use case presented), so it makes sense to establish an adjacency.

Consequently, my vote would be to view this LAG constituent information the same as we view other TE data that is not used by IS-IS itself. From that perspective, it is much more palatable.

Thanks,
Acee  

On 8/7/15, 3:28 AM, "[email-masked]"
<[email-masked]> wrote:

>>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 :) ).
>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
>
>
>>
>>
>>
>>
>>>>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.
>>>>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.
>>>>
>>>>
>>>>[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.
>>>
>>>>>Moreover I still have an issue with propagating L2 informations 
>>>>>into layer 3 routing protocol  (not technically ... more from a 
>>>>>design perspective).
>>>>>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.
>>>>>
>>>>>additional logic from headend nodes (network elements within the 
>>>>>IGP
>>>>>domain) - e.g.
>>>>>hashing either by some policy/SLA or dynamic based off of per 
>>>>>member utilization, etc..
>>>>>
>>>>>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.
>>>>>
>>>>>
>>>>>> _________________________________________________________________
>>>>>> _ _ _ _ _ ___________________________________________________
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> If you have received this email in error, please notify the 
>>>>>>sender and delete this message and its attachments.
>>>>>> 0A&s=3211164dcbc94ec39a7390a5d1c8371f2c391ec0aeec8806884c6abfd441
>>>>>> 5
>>>>>> 1
>>>>>> 1
>>>>>> 0
>>>>>> 
>>>>>
>>>>>_ _ _ _ ___ _______________________________________________
>>>>>

---

From: <[email-masked]>
Date: Mon, 17 Aug 2015 08:41:19 +0000

You can add in the table as a new solution : establish L3 adjacency on each link in addition to the LAG.

Establish L3 adjacencies on each link in addition to on LAG

Scalability

-1

No (+1)

Minimal (+1)

Simple (+1)

Yes (+1)

No (+1)

Protocol change

No (+1)

Risk

Small (Minimal impact on baseline functionality and managements tools while not deploying any new protocol) (+1)

Sum

6

As for the layer 3 bundles, for the scaling part, it adds some adjacencies, but honestly I don’t think today this is an issue with controlplane resources we have and multithreading.

In the table, you can also add  a section regarding failure detection :
As for solution #1 (L2 bundles in ISIS) and solution #2 (BGP-LS), you need a mechanism outside the protocol to monitor the status on each individual link and report it to the protocol which requires to implement something in addition (it does not work by itself), solution#3 and #4 (see above) : ISIS hellos are doing the job if fast detection is not required.

Regarding the risk :
What is the risk to deploy BGP-LS ? It’s an operational cost (and you already count it before) but there is no risk associated.

For solution #3, what is the impact on the base routing ?

Regarding the criteria : “Using 1 protocol for diverse functionalities”, This is always counted in “Mandate the deployment of a protocol that was not deployed before” moreover using IMO, 1 protocol to do everything is never good … (like using a single router to do every features ☺ )

Best Regards,

From: Ahmed Bashandy (bashandy) [mailto:[email-masked]]
Sent: Tuesday, August 11, 2015 02:05
To: LITKOWSKI Stephane SCE/IBNF; Acee Lindem (acee); Ebben Aries; [email-masked]<mailto:[email-masked]> list ([email-masked]<mailto:[email-masked]>)
Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles

Folks

In attempt to provide a relatively quantitative measurement of the proposed solutions to the problem at hand, I thought I would prepared a small comparison table between ISIS for L2 bundles, BGP-LS for L2 bundles, and changing all L2 bundles members to L3 links as unnumbered interfaces. I put +1 for (IMHO) what looks like an advantage, -1 for (IMHO) what looks like a disdavantage, and (0) what looks like a minor disadvantage or advantage

Scalability

No (+1)

Yes (-1)

No (+1)

Minimal (+1)

Minimal (+1)

Significant (-1)

Simple (+1)

Simple (+1)

Yes (+1)

No (-1)

Yes (+1)

Yes (-1)

Yes (-1)

No (+1)

Protocol change

Yes (-1)

Yes (-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 scale increase) (-1)

Sum

5

-1

-2

One Important point, I agree with Ebben that BGP-LS is not an alternative to using ISIS but rather a complementary solution to be used by networks that do not use ISIS and OSPF. If we assume that BGP-LS will be used by networks that already employ BGP, then using ISIS and BGP-LS will have almost the same score

Thanks

Ahmed

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 17 Aug 2015 14:40:52 +0000

Stephane –

Your new column is already covered by Ahmed’s column #3: “L2 bundles as unnumbered interfaces in ISIS”

Problem is – the two of you disagree on what is +/- for a number of rows.

I don’t think assigning addresses for a much larger set of interfaces (e.g. if there are 128 bundle members this is 128 * the number of L3 interfaces) should be considered easy to do – which is why Ahmed suggested using unnumbered.

Perhaps you could explain why you disagree with Ahmed’s assessment of the rows for his column #3??

    Les

From: Isis-wg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, August 17, 2015 1:41 AM
To: Ahmed Bashandy (bashandy); Acee Lindem (acee); Ebben Aries; [email-masked] list ([email-masked])
Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles

Scalability

-1

No (+1)

Minimal (+1)

Simple (+1)

Yes (+1)

No (+1)

Protocol change

No (+1)

Risk

Sum

6

Regarding the risk :

Best Regards,

Folks

Scalability

No (+1)

Yes (-1)

No (+1)

Minimal (+1)

Minimal (+1)

Significant (-1)

Simple (+1)

Simple (+1)

Yes (+1)

No (-1)

Yes (+1)

Yes (-1)

Yes (-1)

No (+1)

Protocol change

Yes (-1)

Yes (-1)

No (+1)

Risk

Sum

5

-1

-2

Thanks

Ahmed

Thank you.

---

From: <[email-masked]>
Date: Mon, 17 Aug 2015 15:17:08 +0000

Les,

I thought that column #3 was using L3 bundles with unnumbered interfaces, and in this case you loose the ability to hide topology to some protocols : all layer 3 protocols see individual links. With solution #4, you have the choice per protocol/application to use the LAG or individual interfaces.

As I mentioned in my previous mail, here are my comments :

Column#3 scaling :  it adds some adjacencies, but honestly I don’t think today this is an issue with controlplane resources we have and multithreading. But yes there is an additional cost.

Regarding the risk :
What is the risk to deploy BGP-LS ? It’s an operational cost (and you already count it before) but IMO there is no risk associated with. Do you know networks that would use this feature and that does not have already a BGP controlplane ?
For column#3, all the individual links have to be seen by the management system, so whatever they are L2 or L3, there is no scaling issue here.

Column#3 impact on base routing, what is the impact on the base routing ?

Best Regards,

Stephane

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Monday, August 17, 2015 16:41
To: LITKOWSKI Stephane SCE/IBNF; Ahmed Bashandy (bashandy); Acee Lindem (acee); Ebben Aries; [email-masked]<mailto:[email-masked]> list ([email-masked]<mailto:[email-masked]>)
Subject: RE: [Isis-wg] draft-ginsberg-isis-l2bundles

Stephane –

    Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 17 Aug 2015 21:35:59 +0000

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

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, August 17, 2015 8:17 AM
To: Les Ginsberg (ginsberg); Ahmed Bashandy (bashandy); Acee Lindem (acee); Ebben Aries; [email-masked] list ([email-masked])
Subject: RE: [Isis-wg] draft-ginsberg-isis-l2bundles

Les,

Regarding the risk :

Best Regards,

Stephane

Stephane –

    Les

Thank you.

---

From: <[email-masked]>
Date: Tue, 18 Aug 2015 08:28:19 +0000

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:[email-masked]]
Sent: Monday, August 17, 2015 23:36
To: LITKOWSKI Stephane SCE/IBNF; Ahmed Bashandy (bashandy); Acee Lindem (acee); Ebben Aries; [email-masked]<mailto:[email-masked]> list ([email-masked]<mailto:[email-masked]>)
Subject: RE: [Isis-wg] draft-ginsberg-isis-l2bundles

Stephane –

Please clarify.
Thanx.

   Les

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 21 Aug 2015 10:29:01 +0200

hi ahmed,

did some checking of "LAG-child LSPs" asks among my SP customers
and what is not clear to me is:

"why do we need IS-IS extensions for this ?"

couple of observations:

- your proposal of exposing sub-LAG LSPs is valid and there is
  interest to run OAM traffic on LAG-child links

- there is no receive side component in your draft -
  i.e. IS-IS is used only as a northbound protocol

- there is general desire for label-predictability - so most SPs were
  happy to *statically* allocate a label per LAG child link, such
  that even no transmit side support is needed.

- there are some concerns to bloat the IGP (which does topology
  discovery) with non routing related functions.

so coming back to stephane's argument about "BGP-LS" it seems that
this is only relevant to operators which do not want to deploy
BGP-LS on routers running LAGs.

is that a fair summary ?

/hannes

On Mon, Aug 10, 2015 at 05:05:27PM -0700, Ahmed Bashandy (bashandy) wrote:
|    Folks
| 
|    In attempt to provide a relatively quantitative measurement of the
|    proposed solutions to the problem at hand, I thought I would prepared a
|    small comparison table between ISIS for L2 bundles, BGP-LS for L2 bundles,
|    and changing all L2 bundles members to L3 links as unnumbered interfaces.
|    I put +1 for (IMHO) what looks like an advantage, -1 for (IMHO) what looks
|    like a disdavantage, and (0) what looks like a minor disadvantage or
|    advantage
| 
|    +------------------------------------------------------------------------+
|    |                   |ISIS to advertise |BGP-LS to    |L2 bundles as      |
|    |                   |L2 bundles        |advertise L2 |unnumbered         |
|    |                   |                  |bundle       |interfaces in ISIS |
|    |-------------------+------------------+-------------+-------------------|
|    |Scalability        |Minimal scale     |Minimal scale|Significant scale  |
|    |                   |overheard (+1)    |overhead (+1)|overhead (-1)      |
|    |-------------------+------------------+-------------+-------------------|
|    |Mandate the        |No (+1)           |Yes (-1)     |No (+1)            |
|    |deployment of a    |                  |             |                   |
|    |protocol that was  |                  |             |                   |
|    |not deployed before|                  |             |                   |
|    |-------------------+------------------+-------------+-------------------|
|    |Impact on basic    |Minimal (+1)      |Minimal (+1) |Significant (-1)   |
|    |routing            |                  |             |                   |
|    |functionality      |                  |             |                   |
|    |-------------------+------------------+-------------+-------------------|
|    |Works for both P2P |Simple (+1)       |Simple (+1)  |Difficult          |
|    |and LAN            |                  |             |(unnumbered not    |
|    |                   |                  |             |easy with LANs)    |
|    |                   |                  |             |(-1)               |
|    |-------------------+------------------+-------------+-------------------|
|    |Using 1 protocol   |Yes (+1)          |No (-1)      |Yes (+1)           |
|    |for diverse        |                  |             |                   |
|    |functionilities    |                  |             |                   |
|    |-------------------+------------------+-------------+-------------------|
|    |Exposing L2 info in|Yes (-1)          |Yes (-1)     |No (+1)            |
|    |L3 protocol        |                  |             |                   |
|    |-------------------+------------------+-------------+-------------------|
|    |Protocol change    |Yes (-1)          |Yes (-1)     |No (+1)            |
|    |-------------------+------------------+-------------+-------------------|
|    |Risk               |Small (Minimal    |Medium (Have |Significant (Have  |
|    |                   |impact on baseline|to deploy    |to make sure that  |
|    |                   |functionality and |BGP-LS       |baseline           |
|    |                   |managements tools |everywhere)  |functionality on   |
|    |                   |while not         |(0)          |all routers as well|
|    |                   |deploying any new |             |as management and  |
|    |                   |protocol) (+1)    |             |monitoring tools   |
|    |                   |                  |             |are not impacted by|
|    |                   |                  |             |the sharp scale    |
|    |                   |                  |             |increase) (-1)     |
|    |-------------------+------------------+-------------+-------------------|
|    |Sum                |5                 |-1           |-2                 |
|    +------------------------------------------------------------------------+
| 
|    One Important point, I agree with Ebben that BGP-LS is not an alternative
|    to using ISIS but rather a complementary solution to be used by networks
|    that do not use ISIS and OSPF. If we assume that BGP-LS will be used by
|    networks that already employ BGP, then using ISIS and BGP-LS will have
|    almost the same score
| 
|    Thanks
| 
|    Ahmed
| 
|    On 8/7/2015 12:28 AM, [1][email-masked] wrote:
| 
|  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) [[2]mailto:[email-masked]]
|  Sent: Friday, August 07, 2015 02:08
|  To: LITKOWSKI Stephane SCE/IBNF; Ebben Aries; [3][email-masked] list ([4][email-masked])
|  Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles
| 
|  Hi Stephane,
| 
|  On 8/6/15, 10:31 AM, [5]"[email-masked]"
|  <[email-masked]> 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) [[6]mailto:[email-masked]]
|  Sent: Thursday, August 06, 2015 15:34
|  To: LITKOWSKI Stephane SCE/IBNF; Ebben Aries; [7][email-masked] list
|  ([8][email-masked])
|  Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles
| 
| 
| 
|  On 8/6/15, 9:19 AM, [9]"[email-masked]"
|  <[email-masked]> 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) [[10]mailto:[email-masked]]
|  Sent: Thursday, August 06, 2015 14:53
|  To: LITKOWSKI Stephane SCE/IBNF; Ebben Aries; [11][email-masked] list
|  ([12][email-masked])
|  Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles
| 
|  Hi Stephane,
| 
| 
|  On 8/6/15, 4:01 AM, [13]"[email-masked]"
|  <[email-masked]> wrote:
| 
| 
|  Hi Acee,
| 
|  Some comments inline
| 
|  -----Original Message-----
|  From: Acee Lindem (acee) [[14]mailto:[email-masked]]
|  Sent: Wednesday, August 05, 2015 19:24
|  To: LITKOWSKI Stephane SCE/IBNF; Ebben Aries; [15][email-masked] list
|  ([16][email-masked])
|  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 [17][email-masked]"
|  [18]<[email-masked] on behalf of [email-masked]>
|  wrote:
| 
| 
|  Hi,
| 
|  Pls find some inline comments.
| 
|  -----Original Message-----
|  From: Ebben Aries [[19]mailto:[email-masked]]
|  Sent: Wednesday, August 05, 2015 01:39
|  To: LITKOWSKI Stephane SCE/IBNF; [20][email-masked] list
|  ([21][email-masked])
|  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, [22][email-masked] 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
|  [23]<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: +33 2 23 28 49 83
|  <[24]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: +33 6 37 86 97 52
|  <[25]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
| 
| 
|  [26][email-masked]
|  <mailto:[email-masked]>
| 
| 
| 
| 
| 
|  __________________________________________________________________
|  _ _ _ _ ___________________________________________________
| 
|  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
|  [27][email-masked]
|  [28]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
|  [29][email-masked]
|  [30]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.
| 
|  _______________________________________________
|  Isis-wg mailing list
|  [31][email-masked]
|  [32]https://www.ietf.org/mailman/listinfo/isis-wg
| 
| References
| 
|    Visible links
|    1. mailto:[email-masked]
|    2. mailto:[email-masked]
|    3. mailto:[email-masked]
|    4. mailto:[email-masked]
|    5. mailto:[email-masked]
|    6. mailto:[email-masked]
|    7. mailto:[email-masked]
|    8. mailto:[email-masked]
|    9. mailto:[email-masked]
|   10. mailto:[email-masked]
|   11. mailto:[email-masked]
|   12. mailto:[email-masked]
|   13. mailto:[email-masked]
|   14. mailto:[email-masked]
|   15. mailto:[email-masked]
|   16. mailto:[email-masked]
|   17. mailto:[email-masked]
|   18. mailto:[email-masked]@orange.com
|   19. mailto:[email-masked]
|   20. mailto:[email-masked]
|   21. mailto:[email-masked]
|   22. mailto:[email-masked]
|   23. https://urldefense.proofpoint.com/v1/url?u=http://www.orange.com/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaGV%2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0A&s=75085ca9001f9c7a24e6f23efb57f50f5d79a97cbadcbfe1ce65082d335dba35
|   24. https://urldefense.proofpoint.com/v1/url?u=https://monsi.sso.fran
|   25. https://urldefense.proofpoint.com/v1/url?u=https://monsi.sso.fran
|   26. mailto:[email-masked]
|   27. mailto:[email-masked]
|   28. https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/ma
|   29. mailto:[email-masked]
|   30. https://www.ietf.org/mailman/listinfo/isis-wg
|   31. mailto:[email-masked]
|   32. https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Wed, 26 Aug 2015 15:34:33 -0700

Hi Hannes

Let me respond inline

Ahmed

>    interest to run OAM traffic on LAG-child links
AB> Agreed, but keep in mind that OAM is NOT the only use case 
applicable by this draft
>    i.e. IS-IS is used only as a northbound protocol
AB> TE RFCs, such as rfc 5305, 5307, 6119,.., did not specify a receive 
side component.
If they did and I missed them, then the receive side components in the 
TE rfcs are the same for draft-ginsberg-isis-l2bundles:)
>    that even no transmit side support is needed.
AB> I disagree with you regarding the existence of a general desire not 
to advertise static information. If that is the case, then we might as 
well not advertise anything static at all, such as static routes or 
static TE metric such as max BW
Besides label predictabiliy is an internal implementation and the 
existence of such predictability does not mean that the labels should 
not be advertised. Otherwise, we might as well not advertise any label 
at all in any protocol (e.g. LDP, RSVP, BGP) unless the label value is 
completely random.
>    discovery) with non routing related functions.
AB> The draft is proposing TE-related extensions just like other TE 
RFCs. Why did TE metrics become a bloat for this draft? Besides a good 
implementation is expected to only advertise these additional TE 
attributes via explicit configuration. So it would not be a bloat for a 
user who wants them.
> BGP-LS on routers running LAGs.
AB> As Ebben mentioned (as well as myself in the email below), BGP-LS is 
a complementary not an alternative solution. Besides, I am not sure how 
to practically (or even possibly) use  BGP-LS on its own to advertise 
link-state information without IGPs (I did not want to argue about that 
in that thread because it is a different topic all together). If it is 
possible, then an operator that accepts running BGP-LS should completely 
refrain from advertising any TE attributes in IGPs.