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

[Saikat Ray <[e-mail]>]

Bruno:

RFC6286, section 2.1 requires the BGP identifier (router-id) to be unique
within an AS (i.e., the <ASN, BGP identifier> tuple is globally unique).
However, as Acee said, we should clarify this in the drafts.

Thanks.

On Fri, Jun 12, 2015 at 1:04 AM, <[e-mail]> wrote:

>  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.
>
>
>
> Thanks
>
> /Bruno
>
>
>
> Thanks,
>
> Acee
>
>
>
>
>
> *From:* Idr [mailto:[e-mail] <[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] <[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.
>
>


-- 
Saikat Ray
Web: http://raysaikat.googlepages.com