Re: [Idr] 2 week WG adoption call for draft-previdi-idr-bgpls-segment-routing-epe-03 (5/31 to 6/14)

["Stefano Previdi (sprevidi)" <[e-mail]>]

On Jun 12, 2015, at 2:11 PM, Acee Lindem (acee) <[e-mail]> wrote:
> Hi Bruno, 
> 
> From: Bruno Decraene <[e-mail]>
> Date: Friday, June 12, 2015 at 4:04 AM
> To: Acee Lindem <[e-mail]>, Susan Hares <[e-mail]>, "[e-mail]" <[e-mail]>
> Cc: "Keyur Patel (keyupate)" <[e-mail]>, "[e-mail]" <[e-mail]>, "Clarence Filsfils (cfilsfil)" <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: RE: [Idr] 2 week WG adoption call for draft-previdi-idr-bgpls-segment-routing-epe-03 (5/31 to 6/14)
> 
> Hi Acee,
>  
> Thanks for the discussion.
> More inline (*2)
>  
> From: Acee Lindem (acee) [mailto:[e-mail]] 
> Sent: Thursday, June 11, 2015 4:12 PM
> To: DECRAENE Bruno IMT/OLN; Susan Hares; [e-mail]
> Cc: Keyur Patel (keyupate); [e-mail]; Clarence Filsfils (cfilsfil); [e-mail]
> Subject: Re: [Idr] 2 week WG adoption call for draft-previdi-idr-bgpls-segment-routing-epe-03 (5/31 to 6/14)
>  
> Hi Bruno, 
>  
> From: Bruno Decraene <[e-mail]>
> Date: Tuesday, June 9, 2015 at 5:42 AM
> To: Bruno Decraene <[e-mail]>, Susan Hares <[e-mail]>, "[e-mail]" <[e-mail]>
> Cc: "Keyur Patel (keyupate)" <[e-mail]>, "[e-mail]" <[e-mail]>, "Clarence Filsfils (cfilsfil)" <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Re: [Idr] 2 week WG adoption call for draft-previdi-idr-bgpls-segment-routing-epe-03 (5/31 to 6/14)
>  
> I meant: One option may be to add the related Peer-SID in the Peer Adjacency Segment.
>  
> The Peer-SID then would have to be an identifier in NLRI (for uniqueness) rather than attribute and it wouldn’t handle the case of parallel unnumbered interfaces with the same peer. In addition to parallel unnumbered interfaces, there is also the adjacency-sid ambiguity problem of parallel IPv6  interfaces (non-ethernet) that only have link-local addresses. We are discussing these scenarios with the authors. 
> [Bruno] Good to know. Thanks.
>  
> As for peering with two BGP speakers with the same BGP router-id and private AS number, I think this is a misconfiguration even there is nothing in the BGP protocol that prevents it. I would think that the use of the private AS implies a single administrator or at least closely collaborating administrators. 
> [Bruno] If it’s allowed by the protocol and works, I would not call this misconfiguration. Not allowing it anymore, I would call it a regression. There may be reasons for this, but it would be good to discuss them now. And if restrictions are kept, they should be indicated in the document.
> As for the implications/reasons for the use of private AS, this may be related to RIRs or ISPs policy, which are numerous plus may have changed over time, so I would a priori assume diversity. So I’m not sure to see why the solution would be designed not to work in this case, even if I agree that this is a corner case.
> 
> I agree that we should document that the tuple <ASN, BGP-ROUTER-ID> MUST be unique within the BGP LS Domain. I just don’t think we should try and fix it by adding a third node identifier to support uniqueness in this case that could be avoided by the network administrator. 


I agree and will document that.

s.


> 
> Thanks,
> Acee 
> 
> 
> 
>  
> Thanks
> /Bruno
>  
> Thanks,
> Acee 
>  
>  
> From: Idr [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: Tuesday, June 09, 2015 11:39 AM
> To: Susan Hares; [e-mail]
> Cc: Keyur Patel (keyupate); [e-mail]; Clarence Filsfils (cfilsfil); [e-mail]
> Subject: Re: [Idr] 2 week WG adoption call for draft-previdi-idr-bgpls-segment-routing-epe-03 (5/31 to 6/14)
>  
> > From: Acee Lindem (acee)
> > I support IDR working group adoption. I reviewed the document and believe it provides a useful functionality in controller-based deployments and particularly when BGP is used in lieu of an IGP, i.e., https://www.ietf.org/id/draft-ietf-rtgwg-bgp-routing-large-dc-02.txt. 
>  
> +1
>  
> I admit I haven’t had time to really review the doc in detail, but I’ll try one comment, just in case it may be useful.
> Regarding Peer Adj Segment, in theory couldn’t we have:
> - 2 different BGP peers having the same private AS number and the same BGP Router ID?
> - un-numbered external interfaces
>  
> In which case I’m not sure how those 2 peer adj segment would be distinguished, nor how the related to the Peer SID be identified. One option may be to add the related Peer-SID in Peer Adjacency SID.
>  
> /Bruno
>  
>  
> From: Idr [mailto:[e-mail]] On Behalf Of Acee Lindem (acee)
> Sent: Monday, June 01, 2015 3:31 PM
> To: Susan Hares; [e-mail]
> Cc: Keyur Patel (keyupate); [e-mail]; Clarence Filsfils (cfilsfil); [e-mail]
> Subject: Re: [Idr] 2 week WG adoption call for draft-previdi-idr-bgpls-segment-routing-epe-03 (5/31 to 6/14)
>  
> I support IDR working group adoption. I reviewed the document and believe it provides a useful functionality in controller-based deployments and particularly when BGP is used in lieu of an IGP, i.e., https://www.ietf.org/id/draft-ietf-rtgwg-bgp-routing-large-dc-02.txt. 
>  
> Thanks,
> Acee 
>  
> From: Susan Hares <[e-mail]>
> Date: Sunday, May 31, 2015 at 11:26 PM
> To: "[e-mail]" <[e-mail]>
> Cc: "Clarence Filsfils (cfilsfil)" <[e-mail]>, "[e-mail]" <[e-mail]>, "Keyur Patel (keyupate)" <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: [Idr] 2 week WG adoption call for draft-previdi-idr-bgpls-segment-routing-epe-03 (5/31 to 6/14)
>  
> This begins a 2 week WG adoption call for draft-previdi-idr-bgpls-segment-routing-epe-03.txt.  The authors (Stefano, Clarence, Saikat, Keyur, Mach and Jie) should indicate if they know if any IPR.  The draft can be found at:
>  
> http://datatracker.ietf.org/doc/draft-previdi-idr-bgpls-segment-routing-epe/
>  
> In the discussion, please consider:
> a)      Does this addition to BGP-LS for exporting BGP egress point topologies provides useful information for BGP deployments in the internet,
> b)      Are there scaling issues in adding this information to BGP-LS, and
> c)       The technical merits and issues with this proposal.
>  
> Susan Hares and John Scudder
>  
> _________________________________________________________________________________________________________________________
>  
> 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.
>