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

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 3 Nov 2015 15:23:14 +0000

Hi Eric,

sorry for coming back late to you. I’ll go through our suggestions asap.

Thanks.
s.

> On Oct 22, 2015, at 10:16 PM, Eric C Rosen <[email-masked]> 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.  None are defined in this document. 
>       Flags SHOULD be clear on transmission and MUST be ignored at 
>       reception. 
> 
>    o  SRGB: 3 octets of base followed by 3 octets of range.  Note that the 
>       SRGB field MAY appear multiple times.  If the SRGB field appears 
>       multiple times, the SRGB consists of multiple ranges.  The meaning of 
>       an SRGB with multiple ranges is explained in Section 3.2 ("SID/Label 
>       Range TLV") of [I-D.ietf-ospf-segment-routing-extensions]. 
> 
> [Added some text about the semantics of the SRGB field appearing multiple 
> times, with reference to a document that actually explains it.] 
> 
>    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. 
> 
> [This paragraph and bullet items are added in order to make clear just what 
> the semantics of the TLV are.] 
> 
>    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. 
> 
> ----------------- 
> 
> 
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 6 Nov 2015 13:18:19 +0000

Hi Eric,

the proposed text looks good but with one question below.

On Oct 22, 2015, at 10:16 PM, Eric C Rosen <[email-masked]<mailto:[email-masked]>> wrote:

--------------------

3.1.  MPLS Prefix Segment

4.3.  Originator SRGB TLV

     0                   1 2                   3

   where:

   o  Type is 3.

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 Originator-SRGB may only be inserted by the originator of the prefix, maybe we should emphasize that, but the masklength is mostly irrelevant here.

s.

-----------------

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 9 Nov 2015 10:22:00 -0500

Hi Stefano,

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

> 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

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 9 Nov 2015 11:02:43 -0500

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 10 Nov 2015 20:00:19 +0000

Hi Eric, 

>essentially gives you a node-SID that you can use to tunnel to the node

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 

>spring mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/spring

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 11 Nov 2015 08:00:39 +0000

On Nov 9, 2015, at 5:02 PM, Eric C Rosen <[email-masked]> wrote:
> 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

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 16 Nov 2015 09:44:23 -0500

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

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 17 Nov 2015 07:49:20 +0000

> On Nov 16, 2015, at 3:44 PM, Eric C Rosen <[email-masked]> wrote:
> 
> 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)?
> 
> 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.

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 17 Nov 2015 09:52:42 -0500

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

    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.

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.

--------------------

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?

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 17 Nov 2015 15:31:30 +0000

> On Nov 17, 2015, at 3:52 PM, Eric C Rosen <[email-masked]> wrote:
> 
> 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.
> 
> 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:
> 
> (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.
> 
> 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.
>

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 17 Nov 2015 12:15:43 -0500

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?

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 18 Nov 2015 02:19:57 +0000

Hi Eric, 

>explain to me how you use an SRGB when you don't know the node to which

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

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 18 Nov 2015 10:55:23 -0500

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 19 Nov 2015 12:06:35 +0000

Hi Eric, 

>nodes.  But that's a different use case.

Okay - I understand the motivation now. The Originator-SRGB TLV is simply
a mechanism for node to advertise its local SRGB to a controller or other
BGP speaker that will construct segments. I now recall the non-concluded
discussion on the IDR list with respect to this requirement.

Thanks,
Acee