Re: comments to Pasi's opinion (draft-ietf-capwap-base-mib)
From: Romascanu, Dan (Dan) (dromascaavaya.com)
Date: Mon, 25 Jan 2010 08:37:16 -0800 (PST)
Comments on two of the points. 

Dan
 

> -----Original Message-----
> From: Pasi.Eronen [at] nokia.com [mailto:Pasi.Eronen [at] nokia.com] 

> >> - A question: Did the WG consider including NAT-related 
> information 
> >> CapwapBaseWtpStateEntry? For example, whether NAT was 
> detected, and 
> >> what the other address (depending on the question above) was?
> >> [Richard]
> >
> > Yes, CAPWAP has NAT Considerations. But other tunnel 
> protocol (suppose 
> > GRE or any other example) may also have such function.  I 
> think there 
> > should have a generic MIB interface (no matter it exists or 
> not) Which 
> > would offer NAT-related information, while such function is 
> not A part 
> > of CAPWAP MIB (or other similar tunnel protocol).
> 
> I disagree. The NAT traversal functionality here is a 
> functionality of the CAPWAP protocol, and probably cannot be 
> managed by any generic MIB. 
> 
> However, the question I asked was whether this was discussed 
> in the WG. Chairs, you do recall?

I do not remember this having been discussed. 

As now written the CapwapBaseWtpStateEntry presents the WTP information
whatever the topology is NAT-ed or not. This seems to me OK as a
starting point. What Pasi asks if I read correctly is to add columnar
object that describes whether the connection is NAT-ed and what is the
IP address visible from the AC. 

> 
> > >- capwapBaseMacAclId: this seems to limit the number of 
> ACL entries 
> > >to
> > >255 -- why? (although RFC 5415 doesn't support sending 
> more than 255 
> > >ACL entries in a single "Add MAC ACL Entry" message 
> element, the AC 
> > >could send more than one of those)
> >
> > [Richard] You are correct, it is not required to give a 
> scope limit to 
> > the capwapBaseMacAclId. The editors misunderstood the value 255 
> > mentioned in the RFC5415.
> 
> OK.
> 
> >> - capwapBaseWtpProfileWtpStaticIpType: How would the 
> "ipv4z" type be 
> >> used by the CAPWAP protocol? (it doesn't seem to use the 
> zone index 
> >> in any way)
> >
> > [Richard] In fact, I am not sure. Dan, Could you confirm whether 
> > CAPWAP support it?
> 
> OK; looking forward to hearing the answer...

I do not think it's supported, but I would suggest that the protocol
experts confirm this. 


> 
> Best regards,
> Pasi 
> 
> 

Results generated by Tiger Technologies using MHonArc.