Re: [spring] [Idr] Comments on draft-ietf-idr-bgp-prefix-sid-01

[Eric C Rosen]

Hi Acee,


However, it still may be simpler operationally to advertise a Global
 Prefix-SID for a locally attached subnet comprised of nodes offering
 a particular service.


I don't think I suggested anything that would prevent one from
advertising a domain-wide prefix-SID for a locally attached subnet.


With respect to the Originator SRGB, I never could fully appreciate
the advantages of advertising it.


That suggests that you don't really see the use case for it.  I believe
the intended use case is the following.

Suppose node S has a packet to send to prefix D, and S knows (through
some magic) that it wants the packet to traverse nodes A, B, and C
(i.e., to follow the path S-A-B-C-D), even though this is not the
default shortest path from S to D.  Let's also suppose that this is a
loose source route, i.e., that A is not adjacent to B, B is not adjacent
to C, and C is not adjacent to D.

In order for S to force a packet through this loose source route, it is
necessary for S to push labels on the packet in the following order:

1. Push C's label for D.
2. Push B's label for C.
3. Push A's label for B.
4. Push whatever label will get the packet from S to A.

To compute label 1 above, S must know (a) C's SRGB and (b) the (global)
prefix-SID for D.

To compute label 2 above, S must know (a) B's SRGB and (b) the (global)
prefix-SID for C.

To compute label 3 above, S must know (a) A's SRGB and (b) the (global)
prefix-SID for B.

If A, B, and C,  each originates a BGP UPDATE with its own loopback
address as prefix, then each can advertise its own SRGB by attaching a
Prefix-SID attribute to the UPDATE, and specifying its SRGB in the
Originator-SRGB field of the Prefix-SID attribute.

I think all the use cases for Originator-SRGB will be like this; (a)
tunnel to the node whose SRGB it is, and (b) use that node's SRGB to
figure out what label to push beneath the labels that get you to the
tunnel endpoint.  I don't see how you can do this unless you know the
address of the node to which you are tunneling, and unless you know that
node's SRGB.  If you're not trying to do something like this, there is
no need for the Originator Sub-TLV.

In this example, one could imagine that A, B, C have the same SRGB, and
that there is a prefix covering the addresses of A, B, and C.  In that
case, it might make sense to advertise the Originator-SRGB in a route
whose to the covering prefix.  So I agree (now) that the prefix need not
be a /32 or /128.

Naturally, the originator SRGB sub-TLV is just one of several possible
ways of allowing a node to advertise its SRGB.  Another way for a node
to advertise its SRGB would be to use the segment routing extensions of
BGP-LS.  However, there are scenarios in which BGP-LS is not present,
but BGP-LU is in use.

There's also a completely different way of figuring out the labels for
the traffic engineered path, using the EPE extensions of BGP-LS.  Those
extensions allow a BGP speaker to advertise a (locally significant)
adjacency-SID for each of its BGP neighbors.  Since those labels are
locally significant, you don't need to know the SRGBs of the transit
nodes.  But that's a different use case.


If you advertise an Originator SRGB, it implies that there nodes
with differing SRGBs in the BGP Routing Domain. If this is the case,
there is a very good chance that nodes receiving the Prefix-SID
Attribute with the Originator SRGB will not have the same SRGB and
will not have the Originator-SRGB[label-index] label available for
local allocation.


Right.  In the use case I described above, the Originator-SRGB of a
particular node is used only to compute label values for the node whose
SRGB it is.  No one else uses it for local label allocation.


I can’t really see what different it makes whether or not it is a
host prefix or whether you can ascertain the node to which the SRGB
belongs.


Please see the use case described above.


It seems that the key constraint is that the label-index and the SRGB
came from the same node and this is always the case.


Now it's my turn to say that I don't understand the use case you have in
mind ;-)  If all you know is that the SRGB and the Prefix-SID sub-TLVs
were created by the same node, I don't see what good it does you to know
the SRGB.

Eric


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Idr] Comments on draft-ietf-idr-bgp-prefix-sid-01

[Eric C Rosen]

[Eric] Do you have an example in mind where it is useful to advertise
an Originator SRGB when the prefix in the NLRI is not a host
address?

[Stefano] in fact I don’t have any good example where a /32 (/128) must be
enforced…

Well, that's not the question I asked ;-)

Given that the SRGB is a property of a node, it seems to make sense to 
associate an advertised SRGB with the address of a node.  As I 
explained, one can use this by pushing on a label that is computed by 
combining a domain-wide unique SID with the node's SRGB, and then 
pushing on a label that causes the packet to be delivered to the node in 
question.


However, I can see Acee's point that (if I understand it correctly) that 
all the nodes on a given subnet might use the same SRGB.


Suppose we modify my suggested text as follows:

---
OLD

   When a BGP speaker attaches a Prefix-SID attribute to a given route,
   the Originator SRGB TLV MUST NOT be included in the attribute unless
   the following conditions hold:

   - The prefix field of the route's NLRI contains a host address
 (i.e., a /32 IPv4 address or a /128 IPv6 address).

   - The value of the Originator SRGB TLV specifies the SRGB of the node
 that is identified by the prefix field of the NLRI.

   If a BGP route is received that contains a Prefix-SID attribute with
   an Originator SRGB TLV, but the prefix field of the NLRI does not
   contain a host address, the attribute SHOULD be regarded as
   malformed. If aPrefix-SID attribute contains more than one SRGB TLV,
   it SHOULD be regarded as malformed.  See section 7 for the treatment
   of a malformed Prefix-SID attribute.

   When a route carrying the Prefix-SID attribute is propagated, the
   Originator SRGB TLV (if present) MUST NOT be changed.

NEW

If a BGP speaker attaches a Prefix-SID attribute to a given route, and 
if the Prefix-SID attribute includes the Originator SRGB TLV, then:


- If the prefix field of the route's NLRI contains a host address
(i.e., a /32 IPv4 address or a /128 IPv6 address), the Originator SRGB 
TLV specifies the SRGB of the node to whom the host address belongs


- If the prefix field of the route's NLRI does not contain a host 
address, the Originator SRGB TLV specifies the SRGB that is used by the 
set of nodes whose host addresses match the prefix, but for which there 
is no "more specific" match that specifies a different Originator SRGB.


When a route carrying the Prefix-SID attribute is propagated, the
Originator SRGB TLV (if present) MUST NOT be changed.



This new text omits the enforcement, allows an SRGB to be advertised for 
an entire subnet (as suggested by Acee), but still explains how to 
figure out which nodes are using the specified SRGB.


Does this modification satisfy your objection?




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Idr] Comments on draft-ietf-idr-bgp-prefix-sid-01

[Stefano Previdi (sprevidi)]

> On Nov 17, 2015, at 3:52 PM, Eric C Rosen  wrote:
> 
> [Eric] Do you have an example in mind where it is useful to advertise
> an Originator SRGB when the prefix in the NLRI is not a host
> address?
> 
> [Stefano] in fact I don’t have any good example where a /32 (/128) must be
> enforced…
> 
> Well, that's not the question I asked ;-)
> 
> Given that the SRGB is a property of a node, it seems to make sense to 
> associate an advertised SRGB with the address of a node.


to me it makes sense to advertise the SRGB along with ANY prefix originated by 
that node, regardless the mask-length.

s.


>  As I explained, one can use this by pushing on a label that is computed by 
> combining a domain-wide unique SID with the node's SRGB, and then pushing on 
> a label that causes the packet to be delivered to the node in question.
> 
> However, I can see Acee's point that (if I understand it correctly) that all 
> the nodes on a given subnet might use the same SRGB.
> 
> Suppose we modify my suggested text as follows:
> 
> ---
> OLD
> 
>   When a BGP speaker attaches a Prefix-SID attribute to a given route,
>   the Originator SRGB TLV MUST NOT be included in the attribute unless
>   the following conditions hold:
> 
>   - The prefix field of the route's NLRI contains a host address
> (i.e., a /32 IPv4 address or a /128 IPv6 address).
> 
>   - The value of the Originator SRGB TLV specifies the SRGB of the node
> that is identified by the prefix field of the NLRI.
> 
>   If a BGP route is received that contains a Prefix-SID attribute with
>   an Originator SRGB TLV, but the prefix field of the NLRI does not
>   contain a host address, the attribute SHOULD be regarded as
>   malformed. If aPrefix-SID attribute contains more than one SRGB TLV,
>   it SHOULD be regarded as malformed.  See section 7 for the treatment
>   of a malformed Prefix-SID attribute.
> 
>   When a route carrying the Prefix-SID attribute is propagated, the
>   Originator SRGB TLV (if present) MUST NOT be changed.
> 
> NEW
> 
> If a BGP speaker attaches a Prefix-SID attribute to a given route, and if the 
> Prefix-SID attribute includes the Originator SRGB TLV, then:
> 
> - If the prefix field of the route's NLRI contains a host address
> (i.e., a /32 IPv4 address or a /128 IPv6 address), the Originator SRGB TLV 
> specifies the SRGB of the node to whom the host address belongs
> 
> - If the prefix field of the route's NLRI does not contain a host address, 
> the Originator SRGB TLV specifies the SRGB that is used by the set of nodes 
> whose host addresses match the prefix, but for which there is no "more 
> specific" match that specifies a different Originator SRGB.
> 
> When a route carrying the Prefix-SID attribute is propagated, the
> Originator SRGB TLV (if present) MUST NOT be changed.
> 
> 
> 
> This new text omits the enforcement, allows an SRGB to be advertised for an 
> entire subnet (as suggested by Acee), but still explains how to figure out 
> which nodes are using the specified SRGB.
> 
> Does this modification satisfy your objection?
> 
> 
> 
> 

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Idr] Comments on draft-ietf-idr-bgp-prefix-sid-01

[Acee Lindem (acee)]

Hi Eric, 

On 11/17/15, 12:15 PM, "Eric C Rosen"  wrote:

>On 11/17/2015 10:31 AM, Stefano Previdi (sprevidi) wrote:
>> to me it makes sense to advertise the SRGB along with ANY prefix
>> originated by that node, regardless the mask-length.
>
>But in that case, you don't know who the originator node is.  Could you
>explain to me how you use an SRGB when you don't know the node to which
>it belongs?

The use cases I came up with could definitely be accomplished with either
an additional label or recursive resolution through the Node-SID. However,
it still may be simpler operationally to advertise a Global Prefix-SID for
a locally attached subnet comprised of nodes offering a particular
service. 

With respect to the Originator SRGB, I never could fully appreciate the
advantages of advertising it. If you advertise an Originator SRGB, it
implies that there nodes with differing SRGBs in the BGP Routing Domain.
If this is the case, there is a very good chance that nodes receiving the
Prefix-SID Attribute with the Originator SRGB will not have the same SRGB
and will not have the Originator-SRGB[label-index] label available for
local allocation. I can’t really see what different it makes whether or
not it is a host prefix or whether you can ascertain the node to which the
SRGB belongs. It seems that the key constraint is that the label-index and
the SRGB came from the same node and this is always the case.


Thanks,
Acee 

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Idr] Comments on draft-ietf-idr-bgp-prefix-sid-01

[Eric C Rosen]

On 11/10/2015 3:00 PM, Acee Lindem (acee) wrote:

I agree the predominant use case will be advertisement of a loopback.
However, independent of whether or not the Originator-SRGB TLV is
included, I see no reason why a BGP Speaker could not associate a
label-index with a locally attached subnet.


I agree that a label-index could be associated with a prefix, I didn't 
mean to suggest otherwise.  But what does it mean exactly to associate 
an originator-SRGB with a prefix (other than a host address)?


On 11/11/2015 3:00 AM, Stefano Previdi (sprevidi) wrote:

I don’t want to constrain the advertisement of the Originator-SRGB to
a /32 (or even to a loopback interface prefix).


Do you have an example in mind where it is useful to advertise an 
Originator SRGB when the prefix in the NLRI is not a host address?


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Idr] Comments on draft-ietf-idr-bgp-prefix-sid-01

[Stefano Previdi (sprevidi)]

> On Nov 16, 2015, at 3:44 PM, Eric C Rosen  wrote:
> 
> On 11/10/2015 3:00 PM, Acee Lindem (acee) wrote:
>> I agree the predominant use case will be advertisement of a loopback.
>> However, independent of whether or not the Originator-SRGB TLV is
>> included, I see no reason why a BGP Speaker could not associate a
>> label-index with a locally attached subnet.
> 
> I agree that a label-index could be associated with a prefix, I didn't mean 
> to suggest otherwise.  But what does it mean exactly to associate an 
> originator-SRGB with a prefix (other than a host address)?
> 
> On 11/11/2015 3:00 AM, Stefano Previdi (sprevidi) wrote:
>> I don’t want to constrain the advertisement of the Originator-SRGB to
>> a /32 (or even to a loopback interface prefix).
> 
> Do you have an example in mind where it is useful to advertise an Originator 
> SRGB when the prefix in the NLRI is not a host address?


in fact I don’t have any good example where a /32 (/128) must be enforced…

s.



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Idr] Comments on draft-ietf-idr-bgp-prefix-sid-01

[Stefano Previdi (sprevidi)]

On Nov 9, 2015, at 5:02 PM, Eric C Rosen  wrote:
> 
> On 11/6/2015 8:18 AM, Stefano Previdi (sprevidi) wrote:
>> A prefix may have a shorter mask than 32 (or 128) and still be ok for
>> the Originator SRGB to be there.
> 
> Stefano,
> 
> On further thought, I wonder if I misunderstood the point of your question.  
> If all the addresses falling under a given prefix are loopback addresses of 
> the same node, then the same SRGB might apply to all of them.


yes, but note that nothing mandates that we use only loopback addresses and 
nothing mandates a loopback address to be a /32.


>  In that case, it might make sense to have a shorter prefix but still 
> advertise the Originator-SRGB.  Is that what you're thinking?


yes and more widely, I don’t want to constrain the advertisement of the 
Originator-SRGB to a /32 (or even to a loopback interface prefix).

s.

 
>  But on the other hand, if a node has multiple loopback addresses, it 
> probably won't want the same SID assigned to all of them.
> 
> Eric

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Idr] Comments on draft-ietf-idr-bgp-prefix-sid-01

[Acee Lindem (acee)]

Hi Eric, 

On 11/9/15, 10:22 AM, "spring on behalf of Eric C Rosen"
 wrote:

>Hi Stefano,
>
>>>If a BGP route is received that contains a Prefix-SID attribute
>>>with an
>>>Originator SRGB TLV, but the prefix field of the NLRI does not
>>>contain a
>>>host address, the attribute SHOULD be regarded as malformed. If a
>>>Prefix-SID attribute contains more than one SRGB TLV, it SHOULD be
>>>regarded as malformed.  See section 7 for the treatment of a
>>>malformed
>>>Prefix-SID attribute.
>>>
>>>When a route carrying the Prefix-SID attribute is propagated, the
>>>Originator SRGB TLV (if present) MUST NOT be changed.
>
>> why would you need such limitation ? A prefix may have a shorter mask
>> than 32 (or 128) and still be ok for the Originator SRGB to be there.
>
>The SRGB is a property of a node, not a property of a prefix.  To make
>use of the "Originator SRGB", you have to know the node whose property
>it is.  And you have to be able to tunnel packets to that node.  In the
>text I wrote above, the prefix field in the NLRI identifies the node to
>which the "Originator SRGB" belongs, and the prefix-SID field
>essentially gives you a node-SID that you can use to tunnel to the node
>in question.

I agree the predominant use case will be advertisement of a loopback.
However, independent of whether or not the Originator-SRGB TLV is
included, I see no reason why a BGP Speaker could not associate a
label-index with a locally attached subnet.

Thanks,
Acee 




>
>> The Originator-SRGB may only be inserted by the originator of the
>> prefix, maybe we should emphasize that, but the masklength is mostly
>> irrelevant here.
>
>I don't see that the Originator-SRGB TLV is useful without an explicit
>identification of the node whose SRGB it describes.  Certainly if you
>are trying to set up an explicitly routed path (perhaps as a loose
>source route) what you need are the node-SIDs are of the hops you want
>to specify, and the SRGB of each hop.
>
>When you talk about "the originator of the prefix", I think what you
>really mean is "the last node of the BGP prefix segment".  But I don't
>think that that term necessarily denotes a unique node, as there might
>be multiple ECMP paths to the prefix, and the prefix-SID does not
>distinguish among them.  E.g., the prefix itself might be multi-homed,
>or there might be multiple exit points from the SR domain, all of which
>are equidistant from the prefix.  In cases like that, you have no way of
>knowing whether a label computed from the Originator-SRGB is actually
>going to be correctly interpreted, because you don't really know the
>path a packet will take when it is labeled with the prefix-SID.
>
>Eric
>
>
>
>
>___
>spring mailing list
>spring@ietf.org
>https://www.ietf.org/mailman/listinfo/spring

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Idr] Comments on draft-ietf-idr-bgp-prefix-sid-01

[Eric C Rosen]

On 11/6/2015 8:18 AM, Stefano Previdi (sprevidi) wrote:

A prefix may have a shorter mask than 32 (or 128) and still be ok for
the Originator SRGB to be there.


Stefano,

On further thought, I wonder if I misunderstood the point of your 
question.  If all the addresses falling under a given prefix are 
loopback addresses of the same node, then the same SRGB might apply to 
all of them.  In that case, it might make sense to have a shorter prefix 
but still advertise the Originator-SRGB.  Is that what you're thinking? 
 But on the other hand, if a node has multiple loopback addresses, it 
probably won't want the same SID assigned to all of them.


Eric

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Idr] Comments on draft-ietf-idr-bgp-prefix-sid-01

[Stefano Previdi (sprevidi)]

Hi Eric,

the proposed text looks good but with one question below.


On Oct 22, 2015, at 10:16 PM, Eric C Rosen 
> wrote:

I'd like to make some suggestions for textual changes to sections 3.1 and
4.3 of draft-ietf-idr-prefix-sid.  The main purpose of these suggestions is
to clarify the use of the Originator SRGB TLV, and to remove what I
think is an excessive and distracting amount of repetition about the
inadvisability of allowing different nodes to use different SRGBs.

My proposal for the text of these sections follows.  In addition to the
changes I mentioned above, some typos in the original text are fixed, and
there is a suggestion (explained below in brackets) for slightly modifying
the text about the AFI/SAFIs with which the Prefix-SID attribute may be
used.  A few other explanations can be found in brackets below inside the
proposed text.



3.1.  MPLS Prefix Segment

   In this document, we specify "MPLS Prefix Segments" only for BGP routes
   that have an AFI/SAFI of 1/4 or 2/4.  The applicability of MPLS prefix
   segments to other AFI/SAFIs is outside the scope of this document.

[The original text said "A Multiprotocol BGP labeled IPv4/IPv6 Unicast
([RFC3107]) session type is required", I don't think that is quite precise.
If a session has multiple AFI/SAFIs, including 1/4, I don't think we want to
say that the attribute can be placed in any UPDATE on that session.  Also,
it's not quite accurate to say that RFC3107 is restricted to 1/4 and 2/4;
RFC3107 doesn't mention the AFI.  And we may want to leave it open that the
Prefix Segment notion may eventually be applied somehow to SAFI-128 routes.]

   The BGP Prefix Segment is realized on the MPLS dataplane in the
   following way:

  As described in [I-D.ietf-spring-segment-routing-msdc] the
  operator assigns a globally unique "index", L_I, to a locally
  sourced prefix of a BGP speaker N which is advertised to all other
  BGP speakers in the SR domain.

  According to [I-D.ietf-spring-segment-routing], each BGP speaker
  is configured with a label block called the Segment Routing Global
  Block (SRGB).  (While it is recommended to use the same SRGB across
  all the nodes within the SR domain, the SRGB of a node is a local
  property and could be different on different speakers).

  The index L_I is a 32 bit offset in the SRGB.  Each BGP speaker
  derives its local MPLS label, L, by adding L_I to the start value
  of its own SRGB, and programs L in its MPLS dataplane as its
  incoming/local label for the prefix.  (See section 5.1 for more
  details.)

[Added reference to section 5.1.]

  The outgoing label for the prefix is found in the NLRI of the
  Multiprotocol BGP labeled IPv4/IPv6 Unicast prefix advertisement.
  The index L_I is only used as a hint to derive the local/incoming
  label.

   Section 4.1 of this document specifies the Label-Index TLV of the BGP
   Prefix-SID attribute; this TLV can be used to advertise the label index
   of a given prefix.

   If the BGP speakers are not all configured with the same SRGB, and if
   traffic-engineering within the SR domain is required, each node may be
   required to advertise its local SRGB.  One way of advertising the local
   SRGB is to use the segment routing extensions of BGP-LS
   (draft-gredler-idr-bgp-ls-segment-routing-ext-00.txt). An alternative
   option is to use the Originator SRGB TLV of the prefix-SID attribute, as
   specified in Section 4.3 of this document.

[Rearranged last paragraphs slightly to improve flow, imo.]



4.3.  Originator SRGB TLV

   The Originator SRGB TLV is an optional TLV and has the following
   format:

 0   1 2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type  |  Length   |Flags  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRGB 1 (6 octets) |
|   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRGB n (6 octets) |
|   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[I can rarely get the ascii art to render correctly, but the diagram above
is supposed to be unchanged from what appears in the draft.]

   where:

   o  Type is 3.

   o  Length is the total length of the value portion of the TLV: 2 +
  multiple of 6.

   o  Flags: 16 bits of flags.