[j-nsp] question regarding l3vpn

[Robert Raszuk]

Hi Nabarun,

It is very well explained in the latest BGP spec (it's appendix F.3 to 
be exact):

Appendix F.3 Path attribute ordering

    Implementations which combine update messages as described above in
    6.1 may prefer to see all path attributes presented in a known order.
    This permits them to quickly identify sets of attributes from differ-
    ent update messages which are semantically identical.  To facilitate
    this, it is a useful optimization to order the path attributes
    according to type code.  This optimization is entirely optional.

And ethereal is broken ;).

Cheers,
R.

>  Hi Robert,
> 
> Thanks very much !
> 
> Also can you say whether I need to order the BGP Attributes. Currently
> I am sending Extended Community attribute placed after MP_REACH_NLRI
> attribute (as per BGP rule), the router accepts the route but ethereal
> fails to show the extended community attribute and gives a hex dump.
> 
> Also when examining packets from the router I saw that extended
> community attribute is placed before the MP_REACH_NLRI attribute.
> 
> Is there any requirement to place Extended Community attribute before
> MP_REACH_NLRI?
> 
> Any suggestions will be grateful !
> 
> Regards
> Naba
> 
> On 10/18/05, Robert Raszuk <raszuk at cisco.com> wrote:
> 
>>Nabarun,
>>
>>Nope unless you have some use for std communities.
>>
>>Cheers,
>>R.
>>
>>
>>>hi All,
>>>
>>>Can anybody tell me whether we need to send community attribute
>>>containing route targets in the bgp update message when BGP/MPLS VPN is
>>>used.
>>>
>>>We can send extended community attribute and put the route target
>>>extended community. But do we also need to send the community attribute.
>>>
>>>Any help will be grateful
>>>
>>>Regards
>>>naba
>>>_______________________________________________
>>>juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>http://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>
>