Re: [Idr] Response to comments on generalized RT constrain solution

Hi Rajiv,

> 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.

Correctly!

Best regards,
Mach
> 
> Cheers,
> Rajiv
> 
>> -----Original Message-----
>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of
> Robert
>> Raszuk (raszuk)
>> Sent: Wednesday, November 11, 2009 12:31 AM
>> To: Mach Chen
>> Cc: idr@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@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr 