gmane.network.quagga.devel

[quagga-dev 10540] Re: bgp and Multiprotocol Extension Capability

'Chris Hall' — 2013-05-22T17:18:36

Pradosh Mohapatra wrote (on Sun 19-May-2013 at 16:09 +0100):
.....

I dunno.  The last sentence has all the appearance of a statement of
the blindingly obvious.

I guess it is meant to mean that you can advertise Graceful Restart
for IPv4/Unicast without supporting [BGP-MP]... but (even) in that
case, IPv4/Unicast needs to be included explicitly in the list,
despite the fact that you: a) don't understand any other afi/safi; b)
don't issue any MP-Ext; c) use the encoding of [BGP-4].

If it is meant to mean anything else, then I fear it has gone *way*
over my head :-(

Chris

[quagga-dev 10539] FW: bgp and Multiprotocol Extension Capability

'Chris Hall' — 2013-05-21T18:25:12

Pradosh Mohapatra wrote (on Sun 19-May-2013 at 16:09 +0100):
 

Ah.  This is an interpretation I had not considered :-)

So, by this interpretation, the presence of an MP-Ext for a given
afi/safi says that the peer supports the sending/receiving of
MP_REACH/MP_UNREACH attributes for that afi/safi, and nothing more.
Hence:

  * for IPv4/Unicast, an MP-Ext signals only that MP_REACH/
    MP_UNREACH may be used for IPv4/Unicast...

    ...but, says nothing at all about the exchange of
    IPv4/Unicast in the "ordinary" or "old" way[1],
    which is implicitly enabled at all times.

  * however, for other afi/safi: MP_REACH/MP_UNREACH are
    essential for the exchange of routes, so the MP-Ext 
    implicitly enables that exchange.

OK.  If I have understood the interpretation, then now I understand
assertions elsewhere that sending an MP-Ext for IPv4/Unicast is not
"strictly required" by RFC4760.  But that's not to say that I agree
with the interpretation[2] :-)

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

Yup: if no MP-Ext at all are received, treat as if MP-Ext for
IPv4/Unicast has been received [3].

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

I agree that this is the most straightforward approach.

If the peer sends 'peer can preserve forwarding' for (say)
IPv6/Unicast, that does NOT imply 'peer can exchange IPv6/Unicast' --
the capabilities are independent.  And, similarly for all other
afi/safi related capabilities.

I think the horse is now quite dead, but I will flog it one last
time...  the presence of MP-Ext for a given afi/safi may be treated as
a "gate"[5] for other capabilities related to that afi/safi[6]...

...*EXCEPT* when no MP-Ext at all are received.  A capability which
applies to named afi/safi may be applied to IPv4/Unicast, *without*
requiring support for Multiprotocol BGP.  Hence the rule "if no MP-Ext
at all are received, treat as if MP-Ext for IPv4/Unicast has been
received."

Goodness... what a lot of pencil for such a small issue !

Chris

------------------
[1] i.e. using the "Withdawn Routes" and/or "Network Layer
Reachability Information" fields of the UPDATE message -- and not
using MP_REACH and/or MP_UNREACH attributes.

------------------
[2] Amongst the difficulties I have with this interpretation is that
it does not allow a peer to "disable" the exchange of IPv4/Unicast
routes.

Further, I think the interpretation is incompatible with Section 7,
"Use of BGP Capability Advertisement", in RFC2858, and the same
section (Section 8) in RFC4760.

The first paragraph of the RF2858 section says:

  "A BGP speaker that uses Multiprotocol Extensions should 
   use the Capability Advertisement procedures [BGP-CAP] to
   determine whether the speaker could use Multiprotocol
   Extensions with a particular peer."

and in Section 8 of RFC4760 the same text appears, but with a
"SHOULD".  I read this as allowing just enough wiggle room to allow
for the support of an RFC2283 peer, for whom the MP-Ext capability
does not exist.  (But it may also be intended to allow for
configuration to override or ignore whatever capabilities are
advertised.)

The last paragraph of the section says (RFC2858):

  "To have a bi-directional exchange of routing information
   for a particular <AFI, SAFI> between a pair of BGP
   speakers, each such speaker must advertise to the other
   (via the Capability Advertisement mechanism) the
   capability to support that particular <AFI, SAFI> routes."

the same text appears in RFC4760, but with a "MUST".  I read this to
say that, if both ends advertise the "capability to support" a given
afi/safi, then "bi-directional exchange" for that afi/safi is enabled.
Further, the "MUST" means that under *any* other circumstances,
exchange of routes is disabled.

Clearly, if one of the two BGP speakers only supports RFC2283 (and
cannot therefore send any MP-Ext Capability), then this requirement
cannot be met.  There is an apparent dissonance between the first
paragraph's SHOULD and the last paragraph's MUST.  However, supporting
the RFC in one BGP speaker cannot magically cause the software in
another BGP speaker to upgrade itself.  So, we might reasonably read
"between a pair of BGP speakers" as "between a pair of BGP speakers
which both support the Multiprotocol Extensions Capability" -- and the
dissonance goes away.  (Or, you might argue that the last paragraph
ought to say SHOULD and not MUST -- to allow for configuration to
override or ignore whatever capabilities are advertised.)

There is no suggestion that IPv4/Unicast is an exception to these
rules.  Nor does the text specify exchange of routeing information
specifically by MP_REACH/MP_UNREACH attribute.  But, hey, nor does it
say otherwise !

The term "capability to support" is arguably a bit of a distraction.
If both ends advertise it, then this nominal "capability to support"
enables bidirectional exchange.  So, "support" in this case doesn't
just mean the peer can (in principle) support the afi/safi, but also
means that it is now ready to receive UPDATEs for that afi/safi and
may send UPDATEs (if both ends "support").  It's not possible for a
peer to advertise that it could handle an afi/safi, but at present
does not care to...  perhaps that is not thought to be of any use !

-----------------
[3] Noting that the possibilities when a peer doesn't send any MP-Ext
Capability at all are:

  a) it does not support Multiprotocol stuff at all...

     ...so, implicitly enabled for IPv4/Unicast, sending
     NLRI the "ordinary" or "old" way[1].

  b) it supports only RFC2283 (now 15 years old).

  c) it supports at least RFC2858 (which introduced the
     MP-Ext Capability, 13 years ago), but does not
     believe it is necessary to send MP-Ext in order
     to exchange IPv4/Unicast the "ordinary" or "old"
     way.

So, what we are agreeing is: by default we assume either (a) or (c),
but not (b); and cover (b) by the "override-capability" configuration
option.  In effect, "in this day and age" we expect any BGP
implementation which supports Multiprotocol BGP to support at least
RFC2858[4].

[IMHO (c) is based on an incorrect interpretation of RFC2858 and/or
RFC4760... but allowing for (a) means allowing for (c), so correctness
of interpretation is moot.]

-----------------
[4] actually, Quagga only supports RFC4760 Multiprotocol BGP peers,
not RFC2283 or RFC2858 ones.  The earlier RFCs both allow for SNPA.
Current Quagga will whimper (WARNING level logging) if it sees a
non-zero count of SNPA, but does not attempt to step over any SNPA...
so will interpret any SNPA detritus as part of the NLRI !!  This is as
required by RFC4760... Go Figure(tm).

-----------------
[5]  It may be perfectly enchanting to learn that 'peer can preserve
forwarding for IPv6/Unicast' (say), but it is of absolutely no
consequence unless 'peer can exchange IPv6/Unicast' as well !

-----------------
[6] I suppose a capability could be invented which means something for
an afi/safi even though no routes for that afi/safi can/will be
exchanged (!).  Hence MP-Ext *may* be a gate for other afi/safi
capabilities -- but not, necessarily, for all such capabilities.

[quagga-dev 10538] Re: bgp and Multiprotocol Extension Capability

'Chris Hall' — 2013-05-21T09:38:00

Pradosh Mohapatra wrote (on Sun 19-May-2013 at 16:09 +0100):
 

Ah.  This is an interpretation I had not considered :-)

So, by this interpretation, the presence of an MP-Ext for a given
afi/safi says that the peer supports the sending/receiving of
MP_REACH/MP_UNREACH attributes for that afi/safi, and nothing more.
Hence:

  * for IPv4/Unicast, an MP-Ext signals only that MP_REACH/
    MP_UNREACH may be used for IPv4/Unicast...

    ...but, says nothing at all about the exchange of
    IPv4/Unicast in the "ordinary" or "old" way[1],
    which is implicitly enabled at all times.

  * however, for other afi/safi: MP_REACH/MP_UNREACH are
    essential for the exchange of routes, so the MP-Ext 
    implicitly enables that exchange.

OK.  If I have understood the interpretation, then now I understand
assertions elsewhere that sending an MP-Ext for IPv4/Unicast is not
"strictly required" by RFC4760.  But that's not to say that I agree
with the interpretation[2] :-)

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

Yup: if no MP-Ext at all are received, treat as if MP-Ext for
IPv4/Unicast has been received [3].

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

I agree that this is the most straightforward approach.

If the peer sends 'peer can preserve forwarding' for (say)
IPv6/Unicast, that does NOT imply 'peer can exchange IPv6/Unicast' --
the capabilities are independent.  And, similarly for all other
afi/safi related capabilities.

I think the horse is now quite dead, but I will flog it one last
time...  the presence of MP-Ext for a given afi/safi may be treated as
a "gate"[5] for other capabilities related to that afi/safi[6]...

...*EXCEPT* when no MP-Ext at all are received.  A capability which
applies to named afi/safi may be applied to IPv4/Unicast, *without*
requiring support for Multiprotocol BGP.  Hence the rule "if no MP-Ext
at all are received, treat as if MP-Ext for IPv4/Unicast has been
received."

Goodness... what a lot of pencil for such a small issue !

Chris

------------------
[1] i.e. using the "Withdawn Routes" and/or "Network Layer
Reachability Information" fields of the UPDATE message -- and not
using MP_REACH and/or MP_UNREACH attributes.

------------------
[2] Amongst the difficulties I have with this interpretation is that
it does not allow a peer to "disable" the exchange of IPv4/Unicast
routes.

Further, I think the interpretation is incompatible with Section 7,
"Use of BGP Capability Advertisement", in RFC2858, and the same
section (Section 8) in RFC4760.

The first paragraph of the RF2858 section says:

  "A BGP speaker that uses Multiprotocol Extensions should 
   use the Capability Advertisement procedures [BGP-CAP] to
   determine whether the speaker could use Multiprotocol
   Extensions with a particular peer."

and in Section 8 of RFC4760 the same text appears, but with a
"SHOULD".  I read this as allowing just enough wiggle room to allow
for the support of an RFC2283 peer, for whom the MP-Ext capability
does not exist.  (But it may also be intended to allow for
configuration to override or ignore whatever capabilities are
advertised.)

The last paragraph of the section says (RFC2858):

  "To have a bi-directional exchange of routing information
   for a particular <AFI, SAFI> between a pair of BGP
   speakers, each such speaker must advertise to the other
   (via the Capability Advertisement mechanism) the
   capability to support that particular <AFI, SAFI> routes."

the same text appears in RFC4760, but with a "MUST".  I read this to
say that, if both ends advertise the "capability to support" a given
afi/safi, then "bi-directional exchange" for that afi/safi is enabled.
Further, the "MUST" means that under *any* other circumstances,
exchange of routes is disabled.

Clearly, if one of the two BGP speakers only supports RFC2283 (and
cannot therefore send any MP-Ext Capability), then this requirement
cannot be met.  There is an apparent dissonance between the first
paragraph's SHOULD and the last paragraph's MUST.  However, supporting
the RFC in one BGP speaker cannot magically cause the software in
another BGP speaker to upgrade itself.  So, we might reasonably read
"between a pair of BGP speakers" as "between a pair of BGP speakers
which both support the Multiprotocol Extensions Capability" -- and the
dissonance goes away.  (Or, you might argue that the last paragraph
ought to say SHOULD and not MUST -- to allow for configuration to
override or ignore whatever capabilities are advertised.)

There is no suggestion that IPv4/Unicast is an exception to these
rules.  Nor does the text specify exchange of routeing information
specifically by MP_REACH/MP_UNREACH attribute.  But, hey, nor does it
say otherwise !

The term "capability to support" is arguably a bit of a distraction.
If both ends advertise it, then this nominal "capability to support"
enables bidirectional exchange.  So, "support" in this case doesn't
just mean the peer can (in principle) support the afi/safi, but also
means that it is now ready to receive UPDATEs for that afi/safi and
may send UPDATEs (if both ends "support").  It's not possible for a
peer to advertise that it could handle an afi/safi, but at present
does not care to...  perhaps that is not thought to be of any use !

-----------------
[3] Noting that the possibilities when a peer doesn't send any MP-Ext
Capability at all are:

  a) it does not support Multiprotocol stuff at all...

     ...so, implicitly enabled for IPv4/Unicast, sending
     NLRI the "ordinary" or "old" way[1].

  b) it supports only RFC2283 (now 15 years old).

  c) it supports at least RFC2858 (which introduced the
     MP-Ext Capability, 13 years ago), but does not
     believe it is necessary to send MP-Ext in order
     to exchange IPv4/Unicast the "ordinary" or "old"
     way.

So, what we are agreeing is: by default we assume either (a) or (c),
but not (b); and cover (b) by the "override-capability" configuration
option.  In effect, "in this day and age" we expect any BGP
implementation which supports Multiprotocol BGP to support at least
RFC2858[4].

[IMHO (c) is based on an incorrect interpretation of RFC2858 and/or
RFC4760... but allowing for (a) means allowing for (c), so correctness
of interpretation is moot.]

-----------------
[4] actually, Quagga only supports RFC4760 Multiprotocol BGP peers,
not RFC2283 or RFC2858 ones.  The earlier RFCs both allow for SNPA.
Current Quagga will whimper (WARNING level logging) if it sees a
non-zero count of SNPA, but does not attempt to step over any SNPA...
so will interpret any SNPA detritus as part of the NLRI !!  This is as
required by RFC4760... Go Figure(tm).

-----------------
[5]  It may be perfectly enchanting to learn that 'peer can preserve
forwarding for IPv6/Unicast' (say), but it is of absolutely no
consequence unless 'peer can exchange IPv6/Unicast' as well !

-----------------
[6] I suppose a capability could be invented which means something for
an afi/safi even though no routes for that afi/safi can/will be
exchanged (!).  Hence MP-Ext *may* be a gate for other afi/safi
capabilities -- but not, necessarily, for all such capabilities.

[quagga-dev 10537] Re: bgp and Multiprotocol Extension Capability

Pradosh Mohapatra — 2013-05-19T15:09:15


I realize this is open to interpretations in this day and age;-) But strictly
speaking, any protocol extension is done in a backward-compatible
way. Use of MP_EXT capability is limited to advertisement of prefixes
in MP_REACH and MP_UNREACH attributes (IOW, they go hand-in-
hand). The speaker is free to send 'ipv4 unicast' prefixes the old way
in the 'network layer reachability information' part of the UPDATE message.




Thanks, saw that. So the discussion is for the case when the peer didn't
send any multi protocol capabilities. I think we agree that this should be
fixed to limit it to ipv4-unicast.




From RFC4724 (and this seems to imply what you are asking for):

      Address Family Identifier (AFI), Subsequent Address Family
         Identifier (SAFI):

         The AFI and SAFI, taken in combination, indicate that Graceful
         Restart is supported for routes that are advertised with the
         same AFI and SAFI.  Routes may be explicitly associated with a
         particular AFI and SAFI using the encoding of [BGP-MP] or
         implicitly associated with <AFI=IPv4, SAFI=Unicast> if using
         the encoding of [BGP-4].



;-)

I think the implementation should identify the meaning of an <afi, safi> pair in the context of
the capability being parsed. For example:

if (GR cap contains <afi1, safi1>), mark 'peer can preserve fwding for <afi1, safi1>'
if (MP_EXT cap contains <afi1, safi1>), mark 'peer can exchange <afi1, safi1> routes (thus start 
                                                                                   accepting those routes'

Now if the peer restarts, the speaker has a way to execute the GR procedure.

- Pradosh

[quagga-dev 10536] Re: bgp and Multiprotocol Extension Capability

Pradosh Mohapatra — 2013-05-18T01:06:25


I agree: 

- if a neighbor has not announced mp_ext capability listing <afi, safi> = <i, j>, Quagga BGP 
   should not be sending any routes for that <afi, safi>
- this rule, however, does not apply to <ipv4 unicast>, as per the original RFC. Quagga BGP
   can thus send <ipv4 unicast> routes to a speaker in the absence of an mp_ext listing
   <ipv4 unicast> (even if the neighbor has announced an mp_ext capability, for other
    <afi, safi> pairs for example).

Strange that I don't see this behavior in Quagga (based on a minimal test). Also, from a
cursory glance at the code, I see that it does the right thing by checking peer->afc_nego[afi][safi]
while announcing the routes.

- Pradosh

[quagga-dev 10535] AUTO: Deepankar Gupta is out of the office from 13/05 to 17/05 (returning Fri 05/17/2013)

Deepankar Gupta — 2013-05-14T16:32:06

I am out of the office from Mon 05/13/2013 until Fri 05/17/2013.

Due to personal reason, I am on leave from 13th/May to 17th/May. I will not
have access to email. In case of need please call me 9582030802.

Thanks & Regards
Deepankar Gupta


Note: This is an automated response to your message  "Quagga-dev Digest,
Vol 118, Issue 14" sent on 05/14/2013 16:30:01.

This is the only notification you will receive while this person is away.

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

[quagga-dev 10534] Re: bgp and Multiprotocol Extension Capability

'Chris Hall' — 2013-05-14T14:36:52

Balaji G wrote (on Tue 14-May-2013 at 04:46 +0100):
....

Not sure :-(

By afi/safi I mean the tuple <AFI, SAFI> (as in RFC4760). Although AFI and SAFI are defined separately, it seems to me that only an afi/safi pair has any real meaning.

Suppose Quagga has a neighbour with IPv4/Unicast, IPv4/Multicast and IPv6/Unicast configured at its end (and will therefore send an MP-Ext for each of those afi/safi). Suppose further that the neighbour only has IPv4/Unicast configured, and does not send any MP-Ext capability at all. Quagga will notice that there are *no* MP-Ext, and proceed as if the neighbour can handle all the afi/safi it is configured for (at the Quagga end) -- and in this case will send updates for all three afi/safi.

Note: if the neighbour sends one or more MP-Ext, then Quagga does what you would expect and only sends updates for the afi/safi which both ends have announced to each other. Also, Quagga always sends an MP-Ext for IPv4 Unicast, even if that is the only afi/safi it is configured for, for that neighbour -- unless the sending of all capabilities is suppressed by "neighbor nn dont-capability-negotiate".

I think I agree with you that "by default" -- that is, if *no* MP-Ext capabilities are received from a neighbour -- the receiver should, "by default", assume the neighbour supports only IPv4 Unicast.

What this is saying is that Quagga's default action should assume that neighbours:

(A) comply with at least RFC2858 "Multiprotocol Extensions for
BGP-4" (Jun-2000), if anything other than IPv4 Unicast is
supported.

(B) and will, if any afi/safi other than IPv4 Unicast is active,
send an MP-Ext capability for every active afi/safi.

Where by "active" we mean that the neighbour wishes to send,
and/or is prepared to receive, updates for the afi/safi.

I think these are reasonable things to assume, ...
---------------------------------------------------------------------
... but it's by no means straightforward.

The history is:

Mar-1995: RFC1771 A Border Gateway Protocol 4 (BGP-4)
Feb-1998: RFC2283 Multiprotocol Extensions for BGP-4
May-2000: RFC2842 Capabilities Advertisement with BGP-4
Jun-2000: RFC2858 Multiprotocol Extensions for BGP-4

which introduced the MP-Ext Capability.

Jan-2007: RFC4760 Multiprotocol Extensions for BGP-4

Quagga's current behaviour is consistent with the RFC2283 world, in which there was no MP-Ext Capability and hence no choice: you had to assume that the neighbour (at the far end) supports the afi/safi it is configured for (at this end).

Clearly it is better to avoid sending updates for afi/safi which the other end is not set up for -- hence the MP-Ext Capability. The more afi/safi there are, the more reason there is to ensure that a given BGP session only carries the afi/safi that both ends agree on.

So, the rationale for assumption (A) is: (i) that 13 years on, there is no good reason for a Multiprotocol BGP speaker to not comply with RFC2858 (at least), and (ii) only sending updates for agreed afi/safi is safer (and increasingly so).

The rationale for assumption (B) is: the obvious thing for any BGP speaker to do is to advertise all the afi/safi it is set up for. All sessions then carry only the afi/safi for which both ends are set up for. Job done.

But, it's not quite that straightforward. Assumption (B) actually has two parts:

(1) if no MP-Ext capability is sent, that that implies
Multiprotocol Extensions are not supported, and hence
IPv4 Unicast *is* supported -- as the status quo ante.

(2) if one or more MP-Ext capabilities are sent, then only
the afi/safi mentioned are active.

However, RFC2858 and RFC4760 say:

(a) "A BGP speaker that uses Multiprotocol Extensions SHOULD use the
Capability Advertisement procedures [BGP-CAP] to determine
whether the speaker could use Multiprotocol Extensions with a
particular peer."

(b) "To have a bi-directional exchange of routing information for a
particular <AFI, SAFI> between a pair of BGP speakers, each
such speaker MUST advertise to the other (via the Capability
Advertisement mechanism) the capability to support that
particular <AFI, SAFI> route."

It seems to me that para (b) is consistent with (2), but is stronger -- all active afi/safi MUST be advertised.

I take the SHOULD in para (a) to mean that in the absence of any good reason to the contrary (i.e. by default) only the afi/safi advertised by a neighbour should be exchanged with that neighbour. There is some wiggle room here to allow other means to decide what afi/safi to exchange -- though that doesn't appear consistent with (b).

The RFC does not suggest an interpretation for no MP-Ext capabilities, and does not appear to support (1) above. But that seems to be a "well known" interpretation. [And is arguably being "liberal in what you accept" -- given the assumption of RFC2858 as a minimum for any Multiprotocol stuff.]

In short, I think there is a case for both assumptions (A) and (B) -- but it takes more pencil than seems at all reasonable !

Chris

[quagga-dev 10533] Re: bgp and Multiprotocol Extension Capability

Balaji G — 2013-05-14T03:45:38

Hi Chris


Do you mean to say if we don't enable the neighbor in the specific SAFI
mode (multicast/mpls-vpn) quagga assumes that the neghbor is enabled for
all SAFIs and gives all the capabilities to the bgp speaker ? Have i
understood your question ?


If the above behavior is what you observe then this is a bug because by
default the unicast SAFI is alone enabled and the other SAFIs are
capabilities which are negotiated in the open message.


AFAI Multiprotocol extensions are optional because IPv6 is also termed as
MultiProtocol and hence you got to enable the neighbor in the ipv6 unicast
mode which by itself is a capability .

Let me know your thoughts.

Thanks,
Cheers,
  - Balaji


On Tue, May 14, 2013 at 1:40 AM, Chris Hall
<chris.hall.list< at >highwayman.com>wrote:

[quagga-dev 10532] bgp and Multiprotocol Extension Capability

'Chris Hall' — 2013-05-13T20:10:34

If a neighbour sends no Multiprotocol Extension Capability (MP-Ext) at
all, Quagga will happily assume that the neighbour supports all the
afi/safi it is configured for.

This strikes me as broken.  RFC4760 says that one or more MP-Ext
capabilities implies that the BGP speaker "uses Multiprotocol
Extensions".  The RFC does not specify what the absence of any MP-Ext
means, but I think it reasonable to assume a BGP speaker that does not
"use Multiprotocol Extensions" is implicitly an unadorned IPv4 Unicast
BGP speaker.

Does anyone think it is unreasonable to treat current behaviour as a
bug ?

I guess most BGP implementations these days send MP-Ext for every
afi/safi supported, even if that is only IPv4 Unicast ?  I note that
BIRD has an option:

  advertise ipv4 switch

  Advertise IPv4 multiprotocol capability. This is not a correct
  behavior according to the strict interpretation of RFC 4760,
  but it is widespread and required by some BGP implementations
  (Cisco and Quagga). This option is relevant to IPv4 mode with
  enabled capability advertisement only.

  Default: on. 

It seems to me that if (say) IPv6 Unicast is announced by MP-Ext, and
if IPv4 Unicast is also required, then it must also be announced by
MP-Ext.  But, if IPv4 Unicast is the only afi/safi required, then I
agree that an MP-Ext is not, strictly, required.

In the long-ago, it seems there was broken-ness in capabilities in
general and (perhaps) MP-Ext in particular.  So, there is "neighbor nn
capability-override" to ignore what the neighbour said (or did not
say) MP-Ext-wise.  So... in the absence of "capability-override", I
don't see why Quagga should make the assumption that no MP-Ext means
all the afi/safi it wants !

Chris

[quagga-dev 10531] Re: RFC-6506(Supporting Authentication Trailer for OSPFv3) implementation in quagga-0.99.21 version

Lokesh Pareta — 2013-05-10T13:21:06

Hi Balaji,
Thank you for your response.
As per your suggestion, I created three patch files related to lib, CLI 
stuff and OSPF implementation,
These patch files can be applied cleanly one by one and also the code 
compiles after each iteration. The applying sequence of the patches should 
be as follows:
lib patch
CLI patch
OSPF implementation patch

The lib part were done in the following files:
Makefile.in
Makefile.am
memtypes.h
memtypes.c
sha256.h
sha256.c

The CLI part were done in the following files:
ospf6_interface.c 
ospf6_interface.h
ospf6_area.c 
ospf6_proto.h


The implementation of CLI functionalities were done in following files:
ospf6_message.c 
ospf6_message.h
ospf6_proto.c 
ospf6_neighbor.c 
ospf6_neighbor.h

Please find the attachments of following files:
Patch file for lib directory
Patch file for CLI part
Patch file for OSPF implementation
Patch file of whole project


           


Thanks & Regards,
Lokesh Pareta

Telecom Technology - NextGen R&D,
Tata Consultancy Services
TCS Towers, 249 D&E Udyog Vihar,
Phase IV, Gurgaon
Haryana, India
Cell:- +91 8506946082
Mailto: lokesh.pareta< at >tcs.com
Website: http://www.tcs.com

___________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Outsourcing
___________________________________________



From:
Balaji G <balajig81< at >gmail.com>
To:
Lokesh Pareta <lokesh.pareta< at >tcs.com>
Cc:
Deepankar Gupta <deepankar.gupta< at >tcs.com>, Saloni Jain 
<saloni.jain< at >tcs.com>, quagga-dev< at >lists.quagga.net, David Lamparter 
<equinox< at >opensourcerouting.org>, Rajeev Agarwal <rajeev.agarwal< at >tcs.com>
Date:
05/09/2013 11:44 AM
Subject:
[quagga-dev 10529] Re: RFC-6506(Supporting Authentication Trailer for 
OSPFv3) implementation in quagga-0.99.21 version



Also make sure the patches after you break it down, applies cleanly when 
applied one by one and also the code compiles after the iteration. You 
could probably break it down into CLI stuff, the actual OSPF 
implementation, libs etc if you wish to.

 - Balaji

On Thu, May 9, 2013 at 11:36 AM, Balaji G <balajig81< at >gmail.com> wrote:
Hi Lokesh 

Is it possible for you to break these into smaller patches and send it as 
i see the changes are done in lib, ospf. Its easier to get it reviewed and 
acknowledge specific patches in specific modules.

Thanks,
Cheers,
   - Balaji


On Thu, May 9, 2013 at 11:11 AM, Lokesh Pareta <lokesh.pareta< at >tcs.com> 
wrote:
Hi All, 

Tata Consultancy Services (TCS) wants to contribute to Quagga development 
by providing the implementation code for RFC-6506, developed and tested on 
quagga-0.99.21 version. 

Abstract of the RFC-6506: 
Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for 
authenticating protocol packets. 
This behavior is different from authentication mechanisms present in other 
routing protocols (OSPFv2, Intermediate System to Intermediate System 
(IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)).   

In some environments, it has been found that IPsec is difficult to 
configure and maintain and thus cannot be used.   
RFC-6506 defines an alternative mechanism to authenticate OSPFv3 protocol 
packets so that OSPFv3 does not only depend upon IPsec for authentication.

Steps to test/run the developed patch file on quagga-0.99.21 : 
As per RFC, implementation is done by TCS in order to provide 
authentication support on both interface and area. 
Commands to be used are as follows: 
For an interface(under interface <i/f name>)-
                ipv6 ospf6 sha-256-authentication                         
       [command to set AT-bit on interface] 
                ipv6 ospf6 sha-256-key <key-id> sha-256 <password>         
         [command to attach key-id and password to the packets] 
For an area (under router ospf6)-
                area <area-id> sha-256-authentication                     
           [command to set AT-bit on area] 
In order to authenticate OSPFv3 packets, please provide combination of 
both AT bit  on an interface/area and key-id with sha-256 password.

Please find following attachment: 
Patch file of RFC-6506 implementation



Kindly revert in case of any queries or doubts and suggestions are also 
welcome. 

Thanks & Regards,
Lokesh Pareta 

Telecom Technology - NextGen R&D,
Tata Consultancy Services
TCS Towers, 249 D&E Udyog Vihar,
Phase IV, Gurgaon
Haryana, India
Cell:- +91 8506946082
Mailto: lokesh.pareta< at >tcs.com
Website: http://www.tcs.com

___________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Outsourcing
___________________________________________
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

_______________________________________________
Quagga-dev mailing list
Quagga-dev< at >lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev


_______________________________________________
Quagga-dev mailing list
Quagga-dev< at >lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 10530] Some GSOC proposals

hervé frantz — 2013-05-10T11:03:26

Hi to everybody,
I have a set of proposition and questions that can be often used for GSOC
and everyone is welcome to give is point of view

*OpenFlow INTEGRATION*

It is planned to join quagga in the SDN moving ? if Openflow should be
integrated should be in the OS or Quagga itself?

*Quagga and other routing protocols implementation*

I have a question about quagga interoperability with other opensource
software implementation (BIRD, XORP, OpenBGPd/OpenOSPFd) and even vendor
implementation address to quagga developer and adminis . Does quagga work
well in a heterogeneous environment? Is it a need to make quagga more
interoperable with other implementation?

*IDRP implementation*

What do you think about some IDRP implementation within quagga *?

*
*NETCONF integration for Quagga

*What do you think about some IDRP integration within quagga *?*



the discussion is open so don't hesitated

have a nice day, Frantz Kengne

[quagga-dev 10529] Re: RFC-6506(Supporting Authentication Trailer for OSPFv3) implementation in quagga-0.99.21 version

Balaji G — 2013-05-09T06:10:02

Also make sure the patches after you break it down, applies cleanly when
applied one by one and also the code compiles after the iteration. You
could probably break it down into CLI stuff, the actual OSPF
implementation, libs etc if you wish to.

 - Balaji

On Thu, May 9, 2013 at 11:36 AM, Balaji G <balajig81< at >gmail.com> wrote:

[quagga-dev 10528] Re: RFC-6506(Supporting Authentication Trailer for OSPFv3) implementation in quagga-0.99.21 version

Balaji G — 2013-05-09T06:06:13

Hi Lokesh

Is it possible for you to break these into smaller patches and send it as i
see the changes are done in lib, ospf. Its easier to get it reviewed and
acknowledge specific patches in specific modules.

Thanks,
Cheers,
   - Balaji


On Thu, May 9, 2013 at 11:11 AM, Lokesh Pareta <lokesh.pareta< at >tcs.com>wrote:

[quagga-dev 10527] RFC-6506(Supporting Authentication Trailer for OSPFv3) implementation in quagga-0.99.21 version

Lokesh Pareta — 2013-05-09T05:41:58

Hi All,

Tata Consultancy Services (TCS) wants to contribute to Quagga development 
by providing the implementation code for RFC-6506, developed and tested on 
quagga-0.99.21 version. 

Abstract of the RFC-6506:
Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for 
authenticating protocol packets.
This behavior is different from authentication mechanisms present in other 
routing protocols (OSPFv2, Intermediate System to Intermediate System 
(IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). 
In some environments, it has been found that IPsec is difficult to 
configure and maintain and thus cannot be used. 
RFC-6506 defines an alternative mechanism to authenticate OSPFv3 protocol 
packets so that OSPFv3 does not only depend upon IPsec for authentication.

Steps to test/run the developed patch file on quagga-0.99.21 :
As per RFC, implementation is done by TCS in order to provide 
authentication support on both interface and area.
Commands to be used are as follows:
For an interface(under interface <i/f name>)-
                ipv6 ospf6 sha-256-authentication [command to set AT-bit 
on interface]
                ipv6 ospf6 sha-256-key <key-id> sha-256 <password> 
[command to attach key-id and password to the packets]
For an area (under router ospf6)-
                area <area-id> sha-256-authentication [command to set 
AT-bit on area]
In order to authenticate OSPFv3 packets, please provide combination of 
both AT bit  on an interface/area and key-id with sha-256 password.

Please find following attachment:
Patch file of RFC-6506 implementation



Kindly revert in case of any queries or doubts and suggestions are also 
welcome.

Thanks & Regards,
Lokesh Pareta

Telecom Technology - NextGen R&D,
Tata Consultancy Services
TCS Towers, 249 D&E Udyog Vihar,
Phase IV, Gurgaon
Haryana, India
Cell:- +91 8506946082
Mailto: lokesh.pareta< at >tcs.com
Website: http://www.tcs.com

___________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Outsourcing
___________________________________________
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

[quagga-dev 10526] Re: Adding "encapsulation dot1q" option to interfaces

Adrian Ban — 2013-05-08T01:33:52

Hi,

Starting from suggestion of David Lamparter (thanks again David) I've 
already created a new daemon with the new commands. Adding/removing 
commands and saving config into the file works flawless.
I've just added 2 MTYPEs: MTYPE_ADDON,  MTYPE_ADDON_IF in lib/memtypes.h 
and small changes in vtysh/vtysh.c and .h (just added the new daemon). 
So no other stuff needed to be changed in the Quagga.

I didn't have any inspiration to give a name to the daemon and I've 
called: addond.

Is fine to start with this name or do you have a better name for it?
The daemon is small right now and is a good moment to rename it if is 
the case.

Thanks in advance,

On 5/3/2013 3:33 PM, David Lamparter wrote:


_______________________________________________
Quagga-dev mailing list
Quagga-dev< at >lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 10525] Re: OSPF: External Prefix Summarization

Ján Janovic — 2013-05-06T18:11:02

Hello again!

It should be done according to your instructions, Joachim :)

Now, there is only one, squashed commit for feature branch 
ospfd/ext_summarization with edited documentation and GNU coding style 
applied. You can access it directly here:

https://bitbucket.org/janovic/quagga/commits/3e4a81207ae87f13d0a8be3ce0145618cd5b19e2

or you can clone whole repository:

git clone https://janovic< at >bitbucket.org/janovic/quagga.git

Please, review it and send your response. Thanks for the big support 
with this feature.

Regards
Jan Janovic


On 05/06/2013 01:18 AM, Joachim Nilsson wrote:

[quagga-dev 10524] Re: Quagga documentation .tex

Joachim Nilsson — 2013-05-06T16:30:07

It's in doc/ospfd.texi in your tree :)

Regards
  /Joachim

[quagga-dev 10523] Quagga documentation .tex

Ján Janovic — 2013-05-06T16:25:29

Hi,

is it possible to get .tex file of Quagga documentation please? I would 
like to add a description of new commands used for OSPF External Prefix 
Summarization (see another thread) there.

Thanks in advance
Ján Janovic

[quagga-dev 10522] Re: OSPF: External Prefix Summarization

Joachim Nilsson — 2013-05-05T23:18:52

Hi again Ján!

Sorry for the delay, like I said in our private conversation, it's been 
quite a busy couple of weeks at work. I've just tested the latest fixes 
tonight, and it works great! :-)

A more click-friendly URL to Ján's OSPF summary-address is here:

     https://bitbucket.org/janovic/quagga/commits/all

Like I mentioned privately, if you:

     1. Squash the commits,
     2. Add texinfo documentation for the summary-address cmd, and
     3. Make some minor GNU coding style fixups

then I'd be more than happy to sign off on your work! :-)

Best regards
  /Joachim

On 04/23/2013 12:06 AM, Ján Janovic wrote:

[quagga-dev 10521] Re: ripd/rip_interface.c memleak from inappropriate strdup() calls

Charlet, Ricky — 2013-05-03T16:51:29

Thanks David,
Yep, it's not a leak. Thanks for pointing out where the free is.

--
Ricky Charlet
Software Dev / Routing Dude: Aries team, Roseville CA
ricky.charlet< at >hp.com
USA: 916.785.2090

-----Original Message-----
From: David Lamparter [mailto:equinox< at >opensourcerouting.org] 
Sent: Friday, May 03, 2013 8:03 AM
To: Charlet, Ricky
Cc: quagga-dev< at >lists.quagga.net
Subject: [quagga-dev 10520] Re: ripd/rip_interface.c memleak from inappropriate strdup() calls

On Wed, May 01, 2013 at 12:09:09AM +0000, Charlet, Ricky wrote:

The vector_* functions perform array manipulation.  The pointer is saved to the rip->rip_enable_interface array and therefore not leaked at that point.  The free() is in the function directly below, rip_enable_if_delete().

Admittedly, there is no error checking for strdup(), which could return NULL if we're out of memory.


Cheers,

-David

_______________________________________________
Quagga-dev mailing list
Quagga-dev< at >lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 10520] Re: ripd/rip_interface.c memleak from inappropriate strdup() calls

David Lamparter — 2013-05-03T15:02:54

The vector_* functions perform array manipulation.  The pointer is saved
to the rip->rip_enable_interface array and therefore not leaked at that
point.  The free() is in the function directly below,
rip_enable_if_delete().

Admittedly, there is no error checking for strdup(), which could return
NULL if we're out of memory.


Cheers,

-David