Hi Bhuvanesh ,

Thanks very much  for taking time to read through the draft.

-          Application based traffic offload/routing requirement most often 
comes from enterprise segment, never seen from service providers.
Since BGP is proposed in the draft to achieve application based routing but BGP 
is most often used between Autonomous systems (between Service providers and 
Enterprise and Service Providers), Why widely accepted and deployed IGPs (OSPF 
and EIGRP) cannot work to achieve proposed functionality? If IGPs are supported 
to have application based routing it will great value add for large Enterprises 
segment without any major change in existing routing.

<<ARUN>>

My  draft focus on Enterprise networks that are globally spread across . 
Typically they will go for MPLS or other forms of VPN technology with choice of 
Last miles.  Invariably bottle neck or congestion will happen on the last mile 
and not the SP's core. Hence the draft focus on managing congestion on the last 
miles. This we do by offloading applications on to other available Paths to the 
SP's VPN cloud. Just to clarify , the draft does not care about load sharing 
with in LAN or Campus network. The Focus really on global Wan networks.  

BGP is the widely used protocol on the wan network (between the CE and PE 
devices) .

Again , My draft does not suggest BGP  for signalling. However I have mentioned 
BGP is used in the current implementations. In the current implementation of 
BGP available in market , there are enough flexibility to pass on signalling 
information directly to forwarding plane. That's was reason current 
implementations are done through BGP.

Infact I have also posted another draft 
(draft-arumuganainar-rtgwg-dps-l4-ppn-00)  exclusively on signalling . Here I 
have proposed to use the signalling to be done during TCP connection 
establishment phase( 3 way handshake ). When implemented this could result in 
more dynamic offloading then we can achieve today. 

To summarise , BGP is one way to do signalling for DPS. But other ways could be 
developed as well. I am always open for suggestion . I would be very happy if 
we could refine the signalling techniques.

<<ARUN>>

-          Draft proposes static configuration to define application profile, 
how to achieve the routing for the applications dynamic in nature and use 
dynamic port numbers etc. ?
 
<<ARUN>>

 Again I am from SP background with very little scope for modifying code and 
trying out new things. Our implementations are constrained  by limitation of 
products currently available in the market . Current implementation allow only 
static definition.  But the proposed frame work allows more dynamic path 
selection as well ( Pls. refer to use cases draft - 
draft-arumuganainar-rtgwg-dps-use-cases-00  ; where dynamic scenarios are 
discussed ).

However most of use cases  would require more development to be done .  That 
was one of the reason I have come to IETF. Requirements Draft is more of a 
problem statement than proposed solution :-).

<<ARUN>>

Pls. let me know if you have any further clarifications.

Thanks and Regards
Arun


Arun Arumuganainar
CCIE#16918 ( R&S and SP )     
Technical Design Authority 
Advanced Solution Delivery
Tata Communications Limited
Direct +44 207 029 9513   |  Fax +44 207 519 4609   |  Mobile +44 7771 831 052  
 |  IP 709513
[email protected]

-----Original Message-----
From: rtgwg [mailto:[email protected]] On Behalf Of [email protected]
Sent: 01 October 2014 20:01
To: [email protected]
Subject: rtgwg Digest, Vol 118, Issue 2

Send rtgwg mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/rtgwg
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of rtgwg digest..."


Today's Topics:

   1. Requesting Comments about the Draft :
      draft-arumuganainar-rtgwg-dps-requirements-00.txt (Bhuvanesh Rajput)
   2. Re: Barry Leiba's No Objection on charter-ietf-rtgwg-04-02:
      (with COMMENT) (Alia Atlas)


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

Message: 1
Date: Wed, 1 Oct 2014 15:09:00 +0000
From: Bhuvanesh Rajput <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Requesting Comments about the Draft :
        draft-arumuganainar-rtgwg-dps-requirements-00.txt
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset="us-ascii"

Hi,

Dynamic path selections draft is well written to have application based 
flexibility in the routing.

Seek clarification on following


-          Application based traffic offload/routing requirement most often 
comes from enterprise segment, never seen from service providers.
Since BGP is proposed in the draft to achieve application based routing but BGP 
is most often used between Autonomous systems (between Service providers and 
Enterprise and Service Providers), Why widely accepted and deployed IGPs (OSPF 
and EIGRP) cannot work to achieve proposed functionality? If IGPs are supported 
to have application based routing it will great value add for large Enterprises 
segment without any major change in existing routing.


-          Draft proposes static configuration to define application profile, 
how to achieve the routing for the applications dynamic in nature and use 
dynamic port numbers etc. ?


Regards
Bhuvanesh Rajput

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://www.ietf.org/mail-archive/web/rtgwg/attachments/20141001/94dc8d35/attachment.html>

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

Message: 2
Date: Wed, 1 Oct 2014 11:13:34 -0400
From: Alia Atlas <[email protected]>
To: Barry Leiba <[email protected]>
Cc: "[email protected]" <[email protected]>, "[email protected]"
        <[email protected]>, The IESG <[email protected]>,
        "[email protected]" <[email protected]>
Subject: Re: Barry Leiba's No Objection on charter-ietf-rtgwg-04-02:
        (with COMMENT)
Message-ID:
        <CAG4d1rfyR1WrUGCyiJxT25Mf4+6ZjtdKNj=67+m887hpw8a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Wed, Oct 1, 2014 at 9:34 AM, Barry Leiba <[email protected]> wrote:

> Barry Leiba has entered the following ballot position for
> charter-ietf-rtgwg-04-02: No Objection
>
> When responding, please keep the subject line intact and reply to all 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/charter-ietf-rtgwg/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I agree with the comment that "optional" should be removed from the 
> first sentence.
>

Sure.  It was put in to make it clear that RTGWG isn't a mandatory hurdle for 
work that is large/organized/ready for a BoF.

Alia


>
>
> _______________________________________________
> rtgwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rtgwg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://www.ietf.org/mail-archive/web/rtgwg/attachments/20141001/ded443d3/attachment.html>

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

Subject: Digest Footer

_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg


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

End of rtgwg Digest, Vol 118, Issue 2
*************************************

_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to