Subject: Re: [Isis-wg] draft-previdi-isis-segment-routing-extensions-05

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 22 Sep 2015 11:17:27 +0000

Hi Anil,

From: Isis-wg on behalf of "Anil Kumar S N (VRP Network BL)"
Date: Tuesday, September 22, 2015 at 12:13 PM
To: "Anil Kumar S N (VRP Network BL)", "[email-masked]<mailto:[email-masked]>", "[email-masked]<mailto:[email-masked]>", "[email-masked]<mailto:[email-masked]>", Hannes Gredler, "[email-masked]<mailto:[email-masked]>", Jeff Tantsura, "[email-masked]<mailto:[email-masked]>"
Cc: Isis-wg
Subject: Re: [Isis-wg] draft-previdi-isis-segment-routing-extensions-05

Hi Authors,

In Section : 2.1.  Prefix Segment Identifier (Prefix-SID Sub-TLV), L-Flag represent IGP segment is local or global (Suggest to change to G so that it will be consistent with Segment Routing Architecture draft) similar to that can we have A-Flag to indicate Anycast SID.
[Pushpasis] Actually in last IETF we discussed this in the context of [I-D.psarkar-spring-mpls-anycast-segments] and came to conclusion that no such indication should be needed. A receiver receiving a prefix-SID without N-bit set from more than one originators can safely interpret it as a anycast SID. Hope it addresses your concerns as well. If not, please let us know.

Thanks
-Pushpasis

L-Flag: Local Flag.  If set, then the value/index carried by
         the Prefix-SID has local significance.  By default the flag is
         UNSET.

https://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00#page-17
3.2<https://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00#section-3.2>.  IGP Segment Terminology
3.2.1<https://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00#section-3.2.1>.  IGP Segment, IGP SID
   The terms "IGP Segment" and "IGP SID" are the generic names for a
   segment attached to a piece of information advertised by a link-state
   IGP, e.g. an IGP prefix or an IGP adjacency.

   The IGP signaling extension to advertise an IGP segment includes the
   G-Flag indicating whether the IGP segment is global or local.
                                       IGP-SID
                                       +--+--+
                                      /   |   \
                             Prefix-SID   x   Adj-SID
                             +----+---+
                            /     |    \
                      Node-SID    y   Anycast-SID

                       Figure 7: IGP SID Terminology

   The IGP Segment terminology is introduced to ease the documentation
   of SR use-cases and hence does not propose a name for any possible
   variation of IGP segment supported by the architecture.  For example,
   y in Figure 7 could represent a local IGP segment attached to an IGP
   Prefix.  This variation, while supported by the SR architecture is
   not seen in the SR use-cases and hence does not receive a specific
   name.

Thanks & Regards
Anil S N

“Be liberal in what you accept, and conservative in what you send” - Jon Postel

From: Anil Kumar S N (VRP Network BL)
Sent: 21 September 2015 20:00
To: [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'; Jeff Tantsura
Cc: [email-masked]<mailto:[email-masked]>'
Subject: draft-previdi-isis-segment-routing-extensions-05

Hi Authors,

In Segment Routing Architecture draft,  There is a provision to allocate multiple Adj-SIDs to same adjacency in case of bundle interface.
In IGP extension draft we need to have one more Adjacency Segment Identifier (Adj-SID) Sub-TLV type to distribute SID’s for bundle members with bundle member ID.

Please let me know your opinion.

Reference :

https://tools.ietf.org/html/draft-ietf-spring-segment-routing-05

3.5.  IGP-Adjacency Segment, Adj-SID

A node MAY allocate multiple Adj-SIDs to the same adjacency.  An
   example is where the adjacency is established over a bundle
   interface.  Each bundle member MAY have its own Adj-SID.

Thanks & Regards
Anil S N

“Be liberal in what you accept, and conservative in what you send” - Jon Postel

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Tue, 22 Sep 2015 11:46:14 +0000

Hi Pushpasis,

        Switching to plain text “Message body is too big: 46607 bytes with a limit of 40 KB”

Please see inline.

I would wish both ISIS and OSPF flags were consistent with name and functionality. OSPF extension doesn’t have N-bit ☹

                Ex:
       ISIS : Prefix Segment Identifier (Prefix-SID Sub-TLV)
    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |R|N|P|E|V|L|   |
   +-+-+-+-+-+-+-+-+

       OSPF : Prefix SID Sub-TLV
     0  1  2  3  4  5  6  7
   +--+--+--+--+--+--+--+--+
   |  |NP|M |E |V |L |  |  |
   +--+--+--+--+--+--+--+--+

Thanks & Regards
Anil S N

From: Pushpasis Sarkar [mailto:[email-masked]]
Sent: 22 September 2015 16:47
To: Anil Kumar S N (VRP Network BL); [email-masked]; [email-masked]; [email-masked]; Hannes Gredler; [email-masked]; Jeff Tantsura; [email-masked]
Cc: [email-masked]
Subject: Re: [Isis-wg] draft-previdi-isis-segment-routing-extensions-05

Hi Anil,

From: Isis-wg on behalf of "Anil Kumar S N (VRP Network BL)"
Date: Tuesday, September 22, 2015 at 12:13 PM
To: "Anil Kumar S N (VRP Network BL)", "[email-masked]", "[email-masked]", "[email-masked]", Hannes Gredler, "[email-masked]", Jeff Tantsura, "[email-masked]"
Cc: Isis-wg
Subject: Re: [Isis-wg] draft-previdi-isis-segment-routing-extensions-05

Hi Authors,

[Anil >>] I would wish to have a new bit representing anycast  SID instead.
    Would it be good to treat all 32 mask in case of IPv4 and 128 mask in case of IPv6  prefix SID as Node SID by default and a anycast would be a special case which might need a bit.

[Anil >>] If discussion is already taken place then one  should respect that.
            I would wish to have detailed description in the draft about when an what cases a prefix SID must be treated as anycast SID.

[Anil >>] Reference :
   The N-Flag is used in order to define a Node-SID.  A router MAY set
   the N-Flag only if all of the following conditions are met:

      The prefix to which the Prefix-SID is attached is local to the
      router.  I.e.: the prefix is configured on one of the local
      interfaces. (e.g.: 'stable transport' loopback).

      The prefix to which the Prefix-SID is attached MUST have a Prefix
      length of either /32 (IPv4) or /128 (IPv6).

   The router MUST ignore the N-Flag on a received Prefix-SID if the
   prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6).

Thanks
-Pushpasis

https://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00#page-17
3.2.  IGP Segment Terminology
3.2.1.  IGP Segment, IGP SID
   The terms "IGP Segment" and "IGP SID" are the generic names for a
   segment attached to a piece of information advertised by a link-state
   IGP, e.g. an IGP prefix or an IGP adjacency.

Thanks & Regards
Anil S N

From: Anil Kumar S N (VRP Network BL)
Sent: 21 September 2015 20:00
To: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; Jeff Tantsura
Cc: [email-masked]'
Subject: draft-previdi-isis-segment-routing-extensions-05

Hi Authors,

Reference :

Thanks & Regards
Anil S N

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 22 Sep 2015 11:58:59 +0000

Hi Anil,

From: "Anil Kumar S N (VRP Network BL)"
Date: Tuesday, September 22, 2015 at 5:16 PM
To: Pushpasis Sarkar, "[email-masked]<mailto:[email-masked]>", "[email-masked]<mailto:[email-masked]>", "[email-masked]<mailto:[email-masked]>", Hannes Gredler, "[email-masked]<mailto:[email-masked]>", Jeff Tantsura, "[email-masked]<mailto:[email-masked]>"
Cc: Isis-wg
Subject: RE: [Isis-wg] draft-previdi-isis-segment-routing-extensions-05

Hi Pushpasis,

Please see inline.

I would wish both ISIS and OSPF flags were consistent with name and functionality. OSPF extension doesn’t have N-bit L
 [Pushpasis] For OSPF the N-bit is moved to Extended Prefix TLV [I-D.ietf-ospf-prefix-link-attr]. This will be soon done with ISIS as well. So after sometime they will be soon consistent. And yes implementation do need to tally both the Prefix-SID sub/TLVs and Extened-Prefix sub/TLVs for figuring out wether a given prefix-SID is a node-SID/unicast Prefix-SID/anycast-Prefix-SID.

Thanks
-Pushpasis
                Ex:

Thanks & Regards
Anil S N

From: Pushpasis Sarkar [mailto:[email-masked]]
Sent: 22 September 2015 16:47
To: Anil Kumar S N (VRP Network BL); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Hannes Gredler; [email-masked]<mailto:[email-masked]>; Jeff Tantsura; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Isis-wg] draft-previdi-isis-segment-routing-extensions-05

Hi Anil,

Hi Authors,

[Anil >>] Reference :

Thanks
-Pushpasis

Thanks & Regards
Anil S N

Hi Authors,

Reference :

Thanks & Regards
Anil S N

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 22 Sep 2015 12:03:00 +0000

Regarding ISIS, N-Flag has already been added in [I-D.ietf-isis-prefix-attributes]. It will be probably removed later from the Prefix-SID subTLV later.

From: Isis-wg on behalf of Pushpasis Sarkar
Date: Tuesday, September 22, 2015 at 5:28 PM
To: "Anil Kumar S N (VRP Network BL)", "[email-masked]<mailto:[email-masked]>", "[email-masked]<mailto:[email-masked]>", "[email-masked]<mailto:[email-masked]>", Hannes Gredler, "[email-masked]<mailto:[email-masked]>", Jeff Tantsura, "[email-masked]<mailto:[email-masked]>"
Cc: Isis-wg
Subject: Re: [Isis-wg] draft-previdi-isis-segment-routing-extensions-05

Hi Anil,

Hi Pushpasis,

Please see inline.

Thanks
-Pushpasis
                Ex:

Thanks & Regards
Anil S N

Hi Anil,

Hi Authors,

[Anil >>] Reference :

Thanks
-Pushpasis

Thanks & Regards
Anil S N

Hi Authors,

Reference :

Thanks & Regards
Anil S N

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 22 Sep 2015 12:11:31 +0000

Hi Anil,

Please find answers to rest of the comments inline. I kind of missed it due to the plain text.

Hi Pushpasis,

Please see inline.

                Ex:

Thanks & Regards
Anil S N

Hi Anil,

Hi Authors,

[Anil >>] I would wish to have a new bit representing anycast  SID instead.
    Would it be good to treat all 32 mask in case of IPv4 and 128 mask in case of IPv6  prefix SID as Node SID by default and a anycast would be a special case which might need a bit.
[Pushpasis] Personally I don’t see a need for the A-bit. Assumimg a /32 or /256 instead of N-bit also does not look good. If you can come up with a convincing reason I am sure the SR authors will add one.

[Anil >>] If discussion is already taken place then one  should respect that.
            I would wish to have detailed description in the draft about when an what cases a prefix SID must be treated as anycast SID.
[Pushpasis] If you mean adding a text in SR architecture document, I will leave it to the SR authors to reply.

[Anil >>] Reference :

   The router MUST ignore the N-Flag on a received Prefix-SID if the
   prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6).
[Pushpasis] Still does not mean all /32 and /128 addresses are representing node SIDs. They may be re-originated prefixes (from one level/area to another).

Thanks
-Pushpasis

Thanks
-Pushpasis

Thanks & Regards
Anil S N

Hi Authors,

Reference :

Thanks & Regards
Anil S N

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Tue, 22 Sep 2015 12:24:11 +0000

Hi Pushpasis,

So you mean say all the attributes of a prefixes and links will be move completely to below mentioned drafts  and references to the same will be updated in SR IGP extension drafts ?
https://tools.ietf.org/html/draft-ietf-isis-prefix-attributes-01 
https://tools.ietf.org/html/draft-ietf-ospf-prefix-link-attr-13

Please find replay inline [Anil >>]  
 
Thanks & Regards
Anil S N

From: Pushpasis Sarkar [mailto:[email-masked]] 
Sent: 22 September 2015 17:42
To: Anil Kumar S N (VRP Network BL); [email-masked]; [email-masked]; [email-masked]; Hannes Gredler; [email-masked]; Jeff Tantsura; [email-masked]
Cc: [email-masked]
Subject: Re: [Isis-wg] draft-previdi-isis-segment-routing-extensions-05

Hi Anil,

From: "Anil Kumar S N (VRP Network BL)"
Date: Tuesday, September 22, 2015 at 5:16 PM
To: Pushpasis Sarkar, "[email-masked]", "[email-masked]", "[email-masked]", Hannes Gredler, "[email-masked]", Jeff Tantsura, "[email-masked]"
Cc: Isis-wg
Subject: RE: [Isis-wg] draft-previdi-isis-segment-routing-extensions-05

Hi Pushpasis,

       Please see inline.

                Ex: 

Thanks & Regards
Anil S N

 
Hi Anil,

Hi Authors, 

[Anil >>] I would wish to have a new bit representing anycast  SID instead. 
           Would it be good to treat all 32 mask in case of IPv4 and 128 mask in case of IPv6  prefix SID as Node SID by default and a anycast would be a special case which might need a bit.
[Pushpasis] Personally I don’t see a need for the A-bit. Assumimg a /32 or /256 instead of N-bit also does not look good. If you can come up with a convincing reason I am sure the SR authors will add one.
[Anil >>]  Does SR care differently for multi-homed prefix and anycast prefix ?
 
[Anil >>] If discussion is already taken place then one  should respect that. 
            I would wish to have detailed description in the draft about when an what cases a prefix SID must be treated as anycast SID.
[Pushpasis] If you mean adding a text in SR architecture document, I will leave it to the SR authors to reply.
[Anil >>]  I would like that to be part of IGP extension drafts. I don’t SR architecture document need this description.

[Anil >>] Reference :

 
   The router MUST ignore the N-Flag on a received Prefix-SID if the
   prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6).
[Pushpasis] Still does not mean all /32 and /128 addresses are representing node SIDs. They may be re-originated prefixes (from one level/area to another).
[Anil >>]  Re-Originated prefixed should have “R-Flag: Re-advertisement flag” right ? Why would that be related to this ?

Thanks
-Pushpasis

Thanks
-Pushpasis

 

 
Thanks & Regards
Anil S N

 
Hi Authors,

 
Reference :

 
 
Thanks & Regards
Anil S N

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 22 Sep 2015 12:44:57 +0000

as far as SR is concerned, the R and N flags defined in draft-ietf-isis-prefix-attributes will replace (after a transition period) the R and N flags currently defined in draft-ietf-isis-segment-routing-extensions.

s.

On Sep 22, 2015, at 2:30 PM, Pushpasis Sarkar <[email-masked]> wrote:

> Date: Tuesday, September 22, 2015 at 5:51 PM
> [Pushpasis] I don't think all will be moved to these. But definitely N-Flag. Still wait to hear back from the SR authors.
>  
> 
>  
> [Anil >>]  Does SR care for multi-homed prefix and anycast prefix ?
> [Pushpasis] I think so. Because there are R-flags as well. 
>  
> [Pushpasis] Again you need to wait for a reply from the authors of the IGP extensions.
>  
> [Anil >>] Reference :
> [Pushpasis] I assumed you are saying to just look at the subnet-length and not look at the flags at all. 
> 
> Thanks
> -Pushpasis
>  
> Thanks
> -Pushpasis
>  
>  
> Thanks
> -Pushpasis
>

---

From: Peter Psenak <[email-masked]>
Date: Tue, 22 Sep 2015 14:45:52 +0200

Anil,

> https://tools.ietf.org/html/draft-ietf-ospf-prefix-link-attr-13

noting will be moved from OSPF SR draft to ospf-prefix-link-attr-13. 
What we have in SR draft is SR specific and will stay there.

thanks,
Peter

> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Tue, 22 Sep 2015 13:01:52 +0000

Hi,

Consolidating discussion : Below are my concerns 

Will there be a section in ISIS SR extension draft describing advertizing and processing of anycast SID? 
Will there be an update to In ISIS SR extension draft to have one more Adjacency Segment Identifier (Adj-SID) Sub-TLV type to distribute SID’s for bundle members with bundle member ID ?
Will consistency of Flag names and features related to SID advertisement maintained b/w OSPF and ISIS SR extension ?

Thanks & Regards
Anil S N

> -----Original Message-----
> From: Peter Psenak [mailto:[email-masked]]
> Sent: 22 September 2015 18:16
> To: Anil Kumar S N (VRP Network BL); Pushpasis Sarkar;
> [email-masked]; [email-masked]; [email-masked]; Hannes
> Gredler; [email-masked]; Jeff Tantsura; draft-previdi-
> [email-masked]
> Cc: [email-masked]
> > So you mean say all the attributes of a prefixes and links will be
> move completely to below mentioned drafts  and references to the same
> will be updated in SR IGP extension drafts ?
> > To: Anil Kumar S N (VRP Network BL); [email-masked];
> [email-masked]; [email-masked]; Hannes Gredler;
> [email-masked]; Jeff Tantsura; draft-previdi-isis-
> [email-masked]
> > Cc: [email-masked]
> > To: Pushpasis Sarkar, "[email-masked]", "[email-masked]",
> "[email-masked]", Hannes Gredler, "[email-masked]",
> Jeff Tantsura, "draft-previdi-isis-segment-routing-extensions-
> [email-masked]"
> > Cc: Isis-wg
> >         I would wish both ISIS and OSPF flags were consistent with
> name and functionality. OSPF extension doesn’t have N-bit ☹
> >
> >                  Ex:
> > To: Anil Kumar S N (VRP Network BL); [email-masked];
> [email-masked]; [email-masked]; Hannes Gredler;
> [email-masked]; Jeff Tantsura; draft-previdi-isis-
> [email-masked]
> > Cc: [email-masked]
> > To: "Anil Kumar S N (VRP Network BL)", "[email-masked]",
> "[email-masked]", "[email-masked]", Hannes Gredler,
> "[email-masked]", Jeff Tantsura, "draft-previdi-isis-
> [email-masked]"
> > Cc: Isis-wg
> > In Section : 2.1.  Prefix Segment Identifier (Prefix-SID Sub-TLV), L-
> Flag represent IGP segment is local or global (Suggest to change to G
> so that it will be consistent with Segment Routing Architecture draft)
> similar to that can we have A-Flag to indicate Anycast SID.
> > [Pushpasis] Actually in last IETF we discussed this in the context of
> [I-D.psarkar-spring-mpls-anycast-segments] and came to conclusion that
> no such indication should be needed. A receiver receiving a prefix-SID
> without N-bit set from more than one originators can safely interpret
> it as a anycast SID. Hope it addresses your concerns as well. If not,
> please let us know.
> >
> >             Would it be good to treat all 32 mask in case of IPv4 and
> 128 mask in case of IPv6  prefix SID as Node SID by default and a
> anycast would be a special case which might need a bit.
> > [Pushpasis] Personally I don’t see a need for the A-bit. Assumimg a
> /32 or /256 instead of N-bit also does not look good. If you can come
> up with a convincing reason I am sure the SR authors will add one.
> >              I would wish to have detailed description in the draft
> about when an what cases a prefix SID must be treated as anycast SID.
> > [Pushpasis] If you mean adding a text in SR architecture document, I
> will leave it to the SR authors to reply.
> > [Anil >>]  I would like that to be part of IGP extension drafts. I
> don’t SR architecture document need this description.
> >
> > [Anil >>] Reference :
> > [Pushpasis] Still does not mean all /32 and /128 addresses are
> representing node SIDs. They may be re-originated prefixes (from one
> level/area to another).
> > [Anil >>]  Re-Originated prefixed should have “R-Flag: Re-
> advertisement flag” right ? Why would that be related to this ?
> >
> > Thanks
> > -Pushpasis
> >
> >
> > Thanks
> > -Pushpasis
> >
> > To: [email-masked]'; [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'; Jeff Tantsura
> > Cc: [email-masked]'
> > In Segment Routing Architecture draft,  There is a provision to
> allocate multiple Adj-SIDs to same adjacency in case of bundle
> interface.
> > In IGP extension draft we need to have one more Adjacency Segment
> Identifier (Adj-SID) Sub-TLV type to distribute SID’s for bundle
> members with bundle member ID.
> >

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 22 Sep 2015 15:30:14 +0000

Resending removing the lengthy conversations

From: Pushpasis Sarkar
Date: Tuesday, September 22, 2015 at 6:00 PM
To: "Anil Kumar S N (VRP Network BL)", "[email-masked]<mailto:[email-masked]>", "[email-masked]<mailto:[email-masked]>", "[email-masked]<mailto:[email-masked]>", Hannes Gredler, "[email-masked]<mailto:[email-masked]>", Jeff Tantsura, "[email-masked]<mailto:[email-masked]>"
Cc: Isis-wg
Subject: Re: [Isis-wg] draft-previdi-isis-segment-routing-extensions-05

Hi Anil,

Hi Pushpasis,

Thanks & Regards
Anil S N

…

[Anil >>] Reference :

Thanks
-Pushpasis

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 22 Sep 2015 11:55:56 +0000

Hi Anil,

From: "Anil Kumar S N (VRP Network BL)"
Date: Tuesday, September 22, 2015 at 5:12 PM
To: Pushpasis Sarkar, "[email-masked]<mailto:[email-masked]>", "[email-masked]<mailto:[email-masked]>", "[email-masked]<mailto:[email-masked]>", Hannes Gredler, "[email-masked]<mailto:[email-masked]>", Jeff Tantsura, "[email-masked]<mailto:[email-masked]>"
Cc: Isis-wg
Subject: RE: [Isis-wg] draft-previdi-isis-segment-routing-extensions-05

Hi Pushpasis,

                Please see inline.

                I would wish both ISIS and OSPF flags were consistent with name and functionality. OSPF extension doesn’t have N-bit ☹
[Pushpasis] For OSPF the N-bit is moved to Extended Prefix TLV [I-D.ietf-ospf-prefix-link-attr]. This will be soon done with ISIS as well. So after sometime they will be soon consistent.

Thanks
-Pushpasis

                Ex:

     0  1  2  3  4  5  6  7

   |  |NP|M |E |V |L |  |  |

Thanks & Regards
Anil S N

Hi Anil,

Hi Authors,

If discussion is already taken place then one  should respect that.
 I would wish to have detailed description in the draft about when an what cases a prefix SID must be treated as anycast SID.

Thanks & Regards
Anil S N

Hi Authors,

Reference :

Thanks & Regards
Anil S N

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 22 Sep 2015 12:30:47 +0000

Hi Anil,

Hi Pushpasis,

Thanks & Regards
Anil S N

Hi Anil,

Hi Pushpasis,

Please see inline.

                Ex:

Thanks & Regards
Anil S N

Hi Anil,

Hi Authors,

[Anil >>] Reference :

Thanks
-Pushpasis

Thanks
-Pushpasis

Thanks
-Pushpasis

Thanks & Regards
Anil S N

Hi Authors,

Reference :

Thanks & Regards
Anil S N

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Tue, 22 Sep 2015 11:42:14 +0000

Hi Pushpasis,

                Please see inline.

                Ex:

     0  1  2  3  4  5  6  7

   |  |NP|M |E |V |L |  |  |

Thanks & Regards
Anil S N

Hi Anil,

Hi Authors,

Thanks & Regards
Anil S N

Hi Authors,

Reference :

Thanks & Regards
Anil S N

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Tue, 22 Sep 2015 12:21:04 +0000

Hi Pushpasis,

Thanks & Regards
Anil S N

Hi Anil,

Hi Pushpasis,

Please see inline.

                Ex:

Thanks & Regards
Anil S N

Hi Anil,

Hi Authors,

[Anil >>] Reference :

Thanks
-Pushpasis

Thanks
-Pushpasis

Thanks & Regards
Anil S N

Hi Authors,

Reference :

Thanks & Regards
Anil S N