If the RT is specified using 'draft-ietf-l3vpn-v6-ext-communities' (20
octets), then how would it fit in the RT definition of RFC4684 (8
octets)?
Not sure if this is what Mach is alluding to, but I do see this as an
issue.
Cheers,
Rajiv
-----Original Message-----
From: idr-bounces at ietf.org [mailto:idr-bounces at ietf.org] On Behalf Of
Robert
Raszuk (raszuk)
Sent: Wednesday, November 11, 2009 12:31 AM
To: Mach Chen
Cc: idr at ietf.org
Subject: Re: [Idr] Response to comments on generalized RT constrain
solution
>> > 3. BTW, there is another issue regarding to the length of the RT
>> > filed, the IPv6 address specified RT is covered in rfc4684.
>>
>> Can you clarify what is the issue ?
>
> Here is the RT difinition in RFC4684:
> +-------------------------------+
> | origin as (4 octets) |
> +-------------------------------+
> | route target (8 octets) |
> + +
> | |
> +-------------------------------+
>
> There is only 8 octets left for route target.
Why do you need more ? RFC4360 is quite clear on route target format
and
it is 8 octets.
RFC4684 just talks about IPv4 or IPv6 next hops to be used as part of
MP_REACH_NLRI. That has nothing to do with different RT format.
Cheers,
R.
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr