Re: [Idr] draft-keyupate-idr-bgp-prefix-sid-00 & VPN

Hi Jakob,

> From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com]> Sent: Sunday, November 23, 2014 12:19 AM
> 
> You are free to allocate a prefix-sid for every prefix.
> However, AFAICT a prefix-sid is only intended for nexthops in a segment list.

Could you please elaborate on your last sentence? I'm not sure to catch your point nor how this is related to my 2 points.

Thanks,
Bruno
(possibly till jet-lagged :-) )
> 
> --Jakob
> 
> 
> > -----Original Message-----
> > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of
> > bruno.decraene@orange.com
> > Sent: Tuesday, November 18, 2014 8:54 AM
> > To: idr@ietf. org
> > Subject: [Idr] draft-keyupate-idr-bgp-prefix-sid-00 & VPN
> >
> > Hi authors,
> >
> > Please find below 2 questions/comments regarding VPN applicability
> >
> > 1) Carrier's Carrier (CsC)
> > In IP VPN CsC, both the customer/CEs and the Service Provider/PE use
> > labelled BGP routes (respectively 3107, 2547) for the same IP NLRI.
> > How does the draft handle this? as both usage of the SID attribute are
> > likely to interfere (especially since both ASes will likely start
> > their SID number from 1, hence collision is very likely).
> >
> > May be adding, in the attribute, the AFI/SAFI of the SID may help.
> >
> > 2) SID allocation
> > Would SID be allocated per AS or per PE?
> > The former would waste the SRGB space (as 1 VPN prefix would burn a
> > SRGB/label entry on _all_ PEs).
> > The latter would create SID/label collision on option B ASBR (SID 1
> > allocated on PE1 would collide with SID 1 allocated on PE2)
> >
> > Thanks,
> > Regards,
> > Bruno
> >
> >
> __________________________________________________________
> __________
> > _____________________________________________________
> >
> > 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.
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr

_________________________________________________________________________________________________________________________

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.