Hi, Shishio,

Thanks for your reply and clarification.

Best Regards!



Jiang Dong
Tsinghua University
2012-03-27

From: Shishio Tsuchiya
Date: 2012-03-26 22:19
To: jiangdong345
CC: cai.lei3; jacni; softwires; cuiyong
Subject: Re: [Softwires]Comments about 6rd MIB
Jiang
Thanks for comments.
I will do presentation this draft at Friday,and I will ask which idea is better 
to the audience and chairs.
If IP tunnel MIB extended is better than 6rdMIB,so we would update and define 
extension of IP tunnel MIB.

[DJ] I think RFC4087 is designed for common information about tunnels. So extra 
information that can not be included in RFC4087 need to be contained in 
specialized MIB such as 6rd, softwire mesh. 
BTW, since 6rd can perform encapsulation in a stateless way, there is no need 
to maintain an encapsulation table. AFBRs in softwire mesh scenario need to 
perform I-IP encapsulation with E-IP prefix information, a we defined an 
Encapsulation Table in the softwire mesh MIB. Comments are welcome : )

6rd MIB is completely reflecting to 6rd configuration.
http://tools.ietf.org/html/rfc5969#section-7
"sixRdIpv4MaskLen "  is same function as IPv4MaskLen.

IPv4MaskLen         The number of high-order bits that are identical
                       across all CE IPv4 addresses within a given 6rd
                       domain.  For example, if there are no identical
                       bits, IPv4MaskLen is 0 and the entire CE IPv4
                       address is used to create the 6rd delegated
                       prefix.  If there are 8 identical bits (e.g., the
                       Private IPv4 address range 10.0.0.0/8 is being
                       used), IPv4MaskLen is equal to 8 and IPv4MaskLen
                       high-order bits are stripped from the IPv4
                       address before constructing the corresponding 6rd
                       delegated prefix.

Regards,
-Shishio

(2012/03/26 15:59), Jiang Dong wrote:
> Hi,authors of 6rd MIB,
> I get some comments about 6rd MIB draft.
> 1) You mentioned the "tunnelIfXTable" in section 5.2. I think it is a good 
> idea to extend the tunnel MIB, some scenario cannot be included in RFC4087, 
> such as point to multi-point tunnel like softwire mesh.
> 2) It seems you miss the conformance part in the definition.
> 3) I'm not quite sure what's the "sixRdIpv4MaskLen " used for, can you 
> explain it?
> Regards!
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Jiang Dong
> Tsinghua University
> 
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to