user9382: Deterministically signing a Tx with RFC6979 returns v, r, s, where r and s are the 2 values used in standard ECDSA signatures. v = 27 + (y % 2), so 27 + the parity of r, as pybitcointools indicates. 
So for even r, we get v = 27, odd r we get v = 28. 
How is the value of v (27 or 28) important? Why is it necessary to have a v value? Also, why is it 27? 

user100828: v is needed to recover the public key. As a result of recovering the public key from ECDSA signature, 0, 1, or 2 points can be returned. In order to strictly indicate which point corresponds to the "original" public key, an additional byte is used

user6091: I don't think that the v you describe is part of RFC6979 because I cannot find it in that document.  This v happens to be part of the ecdsa_raw_sign raw sign function in pybitcointools, which calls deterministic_generate_k, which is an implementation of RFC6979.
RFC6979 just helps you generate a deterministic k value for signing.  It does not help you generate r and s.  To generate r and s, you just use the normal ECDSA algorithm; you don't have to refer to RFC6979 after you have used it to generate k.  RFC6979 generates k, which is an input to the signing algorithm that can generate r and s.

user6441: As all the other answers already outline: v is required to recover the correct public key for a signature because there are sometimes (even with low probability) more than one valid public key to be retrieved by a signature.
Here's a cheat sheet:

27 uncompressed public key, y-parity 0, magnitude of x lower than the curve order
28 uncompressed public key, y-parity 1, magnitude of x lower than the curve order
29 uncompressed public key, y-parity 0, magnitude of x greater than the curve order
30 uncompressed public key, y-parity 1, magnitude of x greater than the curve order
31 compressed public key, y-parity 0, magnitude of x lower than the curve order
32 compressed public key, y-parity 1, magnitude of x lower than the curve order
33 compressed public key, y-parity 0, magnitude of x greater than the curve order
34 compressed public key, y-parity 1, magnitude of x greater than the curve order

For any v >= 35 you might be dealing with Ethereum signatures as per EIP-155:
v = recovery_id + CHAIN_ID * 2 + 35


user208: This has nothing to do with RFC6979, but with ECDSA signing and public key recovery.
The (r, s) is the normal output of an ECDSA signature, where r is computed as the X coordinate of a point R, modulo the curve order n.
In Bitcoin, for message signatures, we use a trick called public key recovery. The fact is that if you have the full R point (not just its X coordinate) and s, and a message, you can compute for which public key this would be a valid signature. What this allows is to 'verify' a message with an address, without needing to know the full key (we just do public key recovery on the signature, and then hash the recovered key and compare it with the address).
However, this means we need the full R coordinates. There can be up to 4 different points with a given "X coordinate modulo n". (2 because each X coordinate has two possible Y coordinates, and 2 because r+n may still be a valid X coordinate). That number between 0 and 3 we call the recovery id, or recid. Therefore, we return an extra byte, which also functions as a header byte, by using 27+recid (for uncompressed recovered pubkeys) or 31+recid (for compressed recovered pubkeys).
Strictly speaking the recid is not necessary, as we can just cycle through all the possible coordinate pairs and check if any of them match the signature. The recid just speeds up this verification.
In general, if h is the cofactor, the maximum number of different points with given "X coordinate modulo n" will be 2(h+1). In the case of secp256k1, which has cofactor 1, we get 2(1+1) = 4.

9382: <p>Deterministically signing a Tx with RFC6979 returns <code>v, r, s</code>, where <code>r</code> and <code>s</code> are the 2 values used in standard ECDSA signatures. <code>v = 27 + (y % 2)</code>, so 27 + the parity of <code>r</code>, <a href="https://github.com/simcity4242/pybitcointools/blob/9f79e2aa967a5c10a5a8ba16030c9b6fe0388c0e/bitcoin/main.py#L541-L542" rel="noreferrer">as pybitcointools indicates</a>. </p>

<p>So for even <code>r</code>, we get <code>v = 27</code>, odd <code>r</code> we get <code>v = 28</code>. </p>

<p>How is the value of <code>v</code> (27 or 28) important? Why is it necessary to have a <code>v</code> value? Also, why is it <code>27</code>? </p>
 100828: <p><code>v</code> is needed to recover the public key. As a result of recovering the public key from ECDSA signature, 0, 1, or 2 points can be returned. In order to strictly indicate which point corresponds to the "original" public key, an additional byte is used</p>
 6091: <p>I don't think that the <em>v</em> you describe is part of <a href="https://www.rfc-editor.org/rfc/rfc6979" rel="nofollow noreferrer">RFC6979</a> because I cannot find it in that document.  This <em>v</em> happens to be part of the <code>ecdsa_raw_sign</code> raw sign function in pybitcointools, which calls <code>deterministic_generate_k</code>, which is an implementation of RFC6979.</p>
<p>RFC6979 just helps you generate a deterministic <em>k</em> value for signing.  It does not help you generate <em>r</em> and <em>s</em>.  To generate <em>r</em> and <em>s</em>, you just use the normal ECDSA algorithm; you don't have to refer to RFC6979 after you have used it to generate <em>k</em>.  RFC6979 generates <em>k</em>, which is an input to the signing algorithm that can generate <em>r</em> and <em>s</em>.</p>
 6441: <p>As all the other answers already outline: <code>v</code> is required to recover the correct public key for a signature because there are sometimes (even with low probability) more than one valid public key to be retrieved by a signature.</p>
<p>Here's a cheat sheet:</p>
<ul>
<li><code>27</code> uncompressed public key, y-parity <code>0</code>, magnitude of <code>x</code> lower than the curve order</li>
<li><code>28</code> uncompressed public key, y-parity <code>1</code>, magnitude of <code>x</code> lower than the curve order</li>
<li><code>29</code> uncompressed public key, y-parity <code>0</code>, magnitude of <code>x</code> <em>greater</em> than the curve order</li>
<li><code>30</code> uncompressed public key, y-parity <code>1</code>, magnitude of <code>x</code> <em>greater</em> than the curve order</li>
<li><code>31</code> <em>compressed</em> public key, y-parity <code>0</code>, magnitude of <code>x</code> lower than the curve order</li>
<li><code>32</code> <em>compressed</em> public key, y-parity <code>1</code>, magnitude of <code>x</code> lower than the curve order</li>
<li><code>33</code> <em>compressed</em> public key, y-parity <code>0</code>, magnitude of <code>x</code> <em>greater</em> than the curve order</li>
<li><code>34</code> <em>compressed</em> public key, y-parity <code>1</code>, magnitude of <code>x</code> <em>greater</em> than the curve order</li>
</ul>
<p>For any <code>v &gt;= 35</code> you might be dealing with Ethereum signatures as per <a href="https://eips.ethereum.org/EIPS/eip-155" rel="nofollow noreferrer">EIP-155</a>:</p>
<pre><code>v = recovery_id + CHAIN_ID * 2 + 35
</code></pre>
 208: <p>This has nothing to do with RFC6979, but with ECDSA signing and public key recovery.</p>

<p>The (r, s) is the normal output of an ECDSA signature, where r is computed as the X coordinate of a point R, modulo the curve order n.</p>

<p>In Bitcoin, for message signatures, we use a trick called public key recovery. The fact is that if you have the full R point (not just its X coordinate) and s, and a message, you can compute for which public key this would be a valid signature. What this allows is to 'verify' a message with an address, without needing to know the full key (we just do public key recovery on the signature, and then hash the recovered key and compare it with the address).</p>

<p>However, this means we need the full R coordinates. There can be up to 4 different points with a given "X coordinate modulo n". (2 because each X coordinate has two possible Y coordinates, and 2 because r+n may still be a valid X coordinate). That number between 0 and 3 we call the recovery id, or recid. Therefore, we return an extra byte, which also functions as a header byte, by using 27+recid (for uncompressed recovered pubkeys) or 31+recid (for compressed recovered pubkeys).</p>

<p>Strictly speaking the recid is not necessary, as we can just cycle through all the possible coordinate pairs and check if any of them match the signature. The recid just speeds up this verification.</p>

<p>In general, if h is the cofactor, the maximum number of different points with given "X coordinate modulo n" will be 2(h+1). In the case of secp256k1, which has cofactor 1, we get 2(1+1) = 4.</p>
