Subject: [Idr] Clarify my commennts on draft-patel-raszuk-bgp-vector-routing-01

From: Xuxiaohu <[email-masked]>
Date: Fri, 8 Nov 2013 18:16:43 +0000

Hi co-authors of this draft,

It said "Vector Node attribute consist of one or more TLVs which carry ordered lists of IP Transit Hops that needs to be traversed before the packet is forwarded to its destination" in the presentation slides.

My question to the speaker was whether the above IP Transit Hops must be BGP routers. The answer is No. If so, when a packet is forwarded  to one of the above Transit Hop which is non-BGP router according to the vector routing proposed by this draft, how could that Transit Hop know what the next IP Transit Hop is given that this draft doesn't require any change to the forwarding plane?

BR,
Xiaohu

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 Nov 2013 05:15:37 +0100

Hi,

The term Transit Hop is being overloaded here. Let's divide it to term
BGP Vector Node and P router.

BGP Vector Node is a BGP speaker ... P router is not. P router just
switches IP packet or MPLS packet to its destination embedded in the
encapsulation header.

Best regards,
R.

On Fri, Nov 8, 2013 at 7:16 PM, Xuxiaohu <[email-masked]> wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 9 Nov 2013 06:03:26 +0000

Hi,

The term "Transit Hop" is not overloaded HERE since there is a clear context that these Transit Hops are contained in the TLVs of BGP Vector Node attribute. BTW, there is only one place of your draft where "IP transit hops" is used.

".... this document defines a new BGP
   attribute known as a BGP Vector Node attribute.  The BGP Vector Node
   attribute consist of an ordered list of IP transit hops that needs to
   be traversed before the packet is forwarded to its BGP NEXT HOP.  The
   information carried in the ordered list of Vector Node is used
   towards augmenting the NEXT HOP information for the BGP prefixes as
   carried in the MP_REACH attribute."

According to the above description, it seems there is no differece in semantics between "an ordered list of IP transit hops" and "an ordered list of Vector Nodes". 

To support traffic-enginnering for a given VPN traffic flow destined to a given CE host or customer site, since these Vector Nodes MUST be BGP routers, the TE mechanism proposed by this draft seems inflexible and unscalable compared to the source routing-based TE mechanism. Furthermore, with the TE mechanism defined in this draft, all traffic destined for a given prefix which is associated with a BGP Vector Node attribute would be influenced no matter the source of the traffic. This is unpractical in many cases. For instance, an operator may just want to perform traffic-enginnering on the traffic from site X to site Z, but not on the traffic from site Y to site Z.

Best regards,
Xiaohu

________________________________________
发件人: [email-masked] [[email-masked]] 代表 Robert Raszuk [[email-masked]]
发送时间: 2013年11月9日 12:15
收件人: Xuxiaohu
抄送: [email-masked]
主题: Re: [Idr] Clarify my commennts on   draft-patel-raszuk-bgp-vector-routing-01

Hi,

Best regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 Nov 2013 07:33:22 +0100

Hi Xiaohu,

We will fix the terminology in next rev removing the notion of
"transit node" entirely.

> To support traffic-enginnering for a given VPN traffic flow destined to a
> given CE host or customer site, since these Vector Nodes MUST be
> BGP routers, the TE mechanism proposed by this draft seems inflexible
> and unscalable compared to the source routing-based TE mechanism.

As clearly mentioned today already this mechanism works for BGP routes
in the global table or within context of VPN in any particular VRF.
Naturally the solution focuses on steering the traffic going outside
of your AS being global IPv4 and IPv6.

This is not intended to steer traffic between your IGP next hops - for
that you are much better to use Segment Routing technology. That is
why those two are complimentary not exclusive solutions.

Said this if I build data center model based on the EBGP interconnects
across my fabric core as documented in the draft http://goo.gl/3ZMYl6
BGP vector routing can be of very good use to steer your virtualized
tenant traffic.

> Furthermore, with the TE mechanism defined in this draft, all traffic
> destined for a given prefix which is associated with a BGP Vector
> Node attribute would be influenced no matter the source of the traffic.
> This is unpractical in many cases. For instance, an operator may just
> want to perform traffic-enginnering on the traffic from site X to site Z,
> but not on the traffic from site Y to site Z.

That is not true either. As mentioned today you can apply this
attribute to flow-spec SAFI and use it with any much more finer
granularity of the flow as compared with per dst based routing.

Best regards,
R.

> On Sat, Nov 9, 2013 at 7:03 AM, Xuxiaohu <[email-masked]> wrote:
> Hi,
>

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 9 Nov 2013 07:33:21 +0000

Hi Robert,

________________________________________
发件人: [email-masked] [[email-masked]] 代表 Robert Raszuk [[email-masked]]
发送时间: 2013年11月9日 14:33
收件人: Xuxiaohu
抄送: [email-masked]
主题: Re: [Idr]   答复: Clarify my commennts on draft-patel-raszuk-bgp-vector-routing-01

Hi Xiaohu,

[Xiaohu] Even for global IP traffic, there is no need for ER hops to maintain a lot of routes for the destinations of those global traffic in the source-routing-based TE mechanism. ER hops just needs to know how to reach the next ER hop.

[Xiaohu] Sorry that I have not yet found any mention of flow-spec SAFI in your current draft;)  It seems that you intend to go a step further beyond the Redirect to IP Extended Community by redirecting to a loose explicit path. It would be better to mention this in the draft.

Best regards,
Xiaohu

Best regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 Nov 2013 08:51:20 +0100

> [Xiaohu] Even for global IP traffic, there is no need for ER hops to maintain a
> lot of routes for the destinations of those global traffic in the source-routing-based
> TE mechanism. ER hops just needs to know how to reach the next ER hop.

That's a trade-off if you are encoding the path in each data packet,
signalling your path by for example RSVP-TE or you building the
topology in the control plane.

IMHO there is room for all three of the above in current networks and
it would be operators to choose which architecture they use and which
fits best their needs.

> [Xiaohu] Sorry that I have not yet found any mention of flow-spec SAFI in
> your current draft;)

Please seriously consider taking a second look. The text is pretty
clear there in version -01:

   In the presence of requirement for more selective then to entire IP
   destination packet handling (example separate port 80 http traffic
   from delay sensitve packets) the BGP Vector Node attribute can be
   attached to BGP update containing Dissemination of Flow Specification
   Rules RFC 5575 [RFC5575] where traffic action is defined as new E bit
   (Encapsulate).

                          40  41  42  43  44  45  46  47
                        +---+---+---+---+---+---+---+---+
                        |      reserved     | E | S | T |
                        +---+---+---+---+---+---+---+---+

   E-bit - defines new action which results in encapsulation of matching
   packets to the next vector node as specified in the BGP Vector Node
   Attribute.

Regards,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 9 Nov 2013 09:06:48 +0000

Hi Robert,

Thanks for pointing it out. I have only read the -00 draft which was listed on the agenda.

BTW, the ordered list of Vector Nodes looks like a highway while the normal BGP path looks like a road, once a car (i.e., a packet) enters the highways somehow, it should not exit the highway until it has reached the final destination.Otherwise, it may cause loop. Hence, it seems that those BGP Vector Nodes listed in the BGP Vector Node attribute must be new BGP routers which can recognize this BGP Vector Node attribute, in addition, the last Vector Node on the list must be the egress of the prefix. It would be better to add the above considerations to the draft.

Xiaohu

                          40  41  42  43  44  45  46  47

Regards,
R.